VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
Da gibt es einen semantischen Widerspruch im Skript.
Zeile 14:
// Do not change code below this line!
Zeile 90:
Wozu gehört diese IP Adresse?
%20 ist der Code eines Leerzeichens. ?
Hab's gelesen - Volkszähler.
Vielleicht, aber nicht wahrscheinlich, bringt die Antwort des Zählers das Skript irgendwie "aus dem Takt".
Ich schaue mir das Skript weiter an ...
wir kennen schließlich den Regensensor nicht…
Damit meint Thomas, dass du mehr zum Regensensor mitteilen solltest, wenn du weitere Hilfe haben möchtest.
Davon hängt es ab, ob und wenn ja wie er mit dem AddOn zu verbinden ist.
Tja, das vernundert nicht.
Wenn du mit einem solchen kleinen Relais über 3kW leiten willst, dann solltest du gelegentlich eine Fachkraft hinzuziehen.
Die Werbeangabe von 16A ist totaler Unsinn, also brauchst du zum schalten noch einen Schütz.
Dann gelingt aber das Messen nicht mehr.
Irgendetwas mache ich noch falsch. Aber was?
Die Cloud-Nutzung hierfür ist ein Fehler. 
und scheinbar auch das Ausschalten
Du kannst doch sicher prüfen, ob der Shelly ausschaltet oder nicht. Das wäre zunächst am wichtigsten.
Dann sollte das richtige Erkennen des Schalterzustandes wenigstens zumeist gelingen. Falls dbzgl. gelegentlich Aussetzer festzustellen sind, sind insbesondere die Kenntnisse von thgoebel gefragt.
Meine Fragen:
Yes, of course.
Question: Does it have to be exactly 5 minutes or can it be up to about 6 minutes?
An event handler receives the values and when power is 0 for the first time, it saves the timestamp.
If power > 0, the timestamp is deleted.
If 5 minutes later (current timestamp - saved timestamp) the power is still 0, the output is turned off.
This is the simple algorithm.
The Pro 4PM is afaik scriptable.
Do you use any script on this Shelly?
If you want Node-RED to receive periodically the status of the Shelly, it is usefull using schedule jobs on the Shelly.
Do you do the request for "status_update" in one of your projects and it's working?
Yes I do - via schedule jobs not via requests.
If a request doesn't get a response, it's probably better to let Shelly send it on its own.
Those jobs sends periodically informations, e.g.status.
Via older Node-RED flows I control Shelly 1 (1. Gen.) for heating successfully, also without requests.
Zu einer möglichen Lösung mit Actions fällt mir nichts ein.
Das Problem könnte mit zwei Actions für input toggled on und input toggled off gelöst werden, was aber dem Ziel für kurzes Drücken widerspricht.
Eine Lösung ist aber mit einem Skript möglich.
Liegt die Dauer des Drückens unter einer Zeitschwelle, bspw. 0.5s, wird der Rollladen bis zum Ende gefahren.
Liegt diese Dauer darüber, wird mit dem Loslassen des Tasters sofort gestoppt.
Räusper,
ich habe so etwas nicht, aber Plus 2PM. Und skripten kann ich auch und Node-RED Flows erstellen und ...
Darüber täte ich es lösen.
Btw, es ist auch möglich, einen Shelly per Skript eine (interaktive) Webseite liefern zu lassen, die das Gewünschte anzeigt - ganz alleine und ohne sonstige Dinge, außer (W)LAN selbstverständlich.
Von der App und der Cloud halte ich weniger.
Diese Antwort gebe ich, weil niemand sonst reagierte.
Ich weiß es nicht.
Aber hier gibt es ein fast DAU sicheres Skript dazu: https://github.com/ALLTERCO/shell…ther-devices.js
Du musst nur die Configuration zu jedem Test mit einem Bluetooth Gerät anpassen und testen.
Viel Erfolg!
Äh ... eine Therme schalten per Cloud?
Ich kann nur empfehlen, noch einmal darüber nachzudenken - s.a. meine Signatur.
In aller Freundschaft
In addition to thgoebel note:
Why don't you use a small Node RED flow for this?
Also you should use a locally working MQTT broker.
The hivemq public broker is not reliable enough.
You may use instaed of this the public mosquitto broker. But as seen, you use mosquitto_pub. So you probably have mosquitto installed - or didn't you?
Klar, so geht es auch, ist aber weniger ausbaufähig als die Verwendung eines Schedule Job mit Skript im Shelly selbst.
Was der Shelly per Schedule Job tun soll, kann leicht im Skript implementiert werden. Auch können hierfür mehrere Jobs genutzt werden.
Und warum sollte ein übergeordnetes System etwas zusätzlich tun, was bereits vom betreffenden Gerät erledigt werden kann? Rhetorische Frage
Der Shelly könnte bspw., bei Bedarf zusätzlich zum veröffentlichen einer MQTT-Nachricht, eine HTTP-Request an ein bestimmtes Gerät senden.
Das ginge selbstverständlich auch über eine Node-RED Zentrale, was aber das ganze etwas weniger ausfallsicher machen täte.
Je autarker die Endgeräte arbeiten, desto weniger wahrscheinlich ist ein Funktionsausfall bei Ausfall der Zentrale.
Damit ich nicht ganz falsch verstanden werde. Auch ich nutze Node-RED und das sehr gerne, insbesondere für anwendungsgerechte Dashboards, Datenspeicherung (InfluxDB) und Visualisierung (Grafana).
Da Shelly der zweiten Generation oder höher per zusätzlicher Möglichkeiten(Skripte, Schedule Jobs) zunehmend autark einstellbar sind, halte ich diesen Weg für eindeutig besser.
Dein Hinweis zu Node-RED ist trotz alledem angemessen und evtl. hilfreich.
Zur sauberen Überprüfung, ohne soviel herumzubasteln:
Vergiss temporär die App! Die ist oftmals suboptimal.
Nimm stattdessen einen Browser und gib in der Adresszeile ein: http://<IP Adresse des Shelly>/rpc/shelly.getstatus
Suche in der Antwort nach "input:0" und schaue dir an, was dort hinter "state" steht!
false bedeutet Aus, also keine Verbindung zu L (bzw. N).
true bedeutet Ein, also Verbindung zu L (bzw. N).
Das wiederholst du mit dem anderen Schalterzustand.
Dann werden wir vielleicht weitersehen können.
Das ist mein Ass im Ärmel.
Edit: Wenn möglich, nimm als Browser Edge oder Firefox! Diese zeigen die Antwort vom Shelly übersichtlich an. Das tun andere Browser vielleicht auch ...
Ok, aber hier ginge es ja nicht im ein Routing sondern um die schlichte Netzwerk-Switch-Funktion der FRITZ!Box. Und diese ist oder sollte unabhängig vom externen Bein sein.
Wir wissen, dass das, was üblicherweise Router genannt wird, mehr als das ist. Ein solches Gerät beinhaltet typischerweise noch einen Switch und einen WLAN Access Point. Und letztere sollten ausreichen, um das Anliegen des TE zu erfüllen.
Ich nahm einen Eindruck von der von dir verlinkten Website. Diese beschäftigt sich mit der Arduino IDE und der Programmierung per C++. Dies nutzte ich auch mal. Auch bin ich in C++ bewandert. Der verlinkte Artikel bezieht sich auf eine Bibliothek, die ein WiFi Objekt zur Verfügung stellt. Die dortige Umgebung ist eine andere als die der hier genutzte Firmware, welche auf einem RTOS (Real Time Operating System) basiert. Deshalb ist nicht zu erwarten, dass ein auf Arduino basiertes Programm sich so verhält wie die Shelly Firmware. Dies wäre bei Tasmota32 der Fall, weil dieses System auf C++ und Bibliotheken basiert. (Rui Santos begegnete mir vor Jahren bei Recherchen auf Websites auch bereits.)
Ich bin derzeit selbst mit einem WoMo unterwegs und nutze testweise einen Shelly Plus Plug S und einer FRITZ!Box 4020, die ich an meinem jetzigen Standort in ein MESH eingebunden habe. In den nächsten Tagen wird die FRITZ!Box wegen Weiterfahrt aus diesem Mesh verschwinden. Dann will ich dein Szenario mal testen. Allerdings habe ich ein erheblich weniger ausgestattetes WoMo als du und nutze darin keinen Shelly - die Speicherkapazität von knapp 200Ah (?) ist mir dafür zu schade. Unterwegs nutzen wir gelegentlich einen Hotspot per Smartphone, also ohne FRITZ!Box. Mal sehen, was ich in Kürze noch herausfinden kann. Ich bin dbzgl. sensibilisiert und werde mich ggf. dann hier noch einmal melden. Zumindest interessiert mich, was du noch herausfinden kannst.
Ich wünsche uns dabei viel Erfolg. Bis später vielleicht.
Vermutlich werde ich nicht weiterhelfen können, aber ...
Vermutlich arbeitet der Shelly im Wohnmobil.
habe ich sicherheitshalber mal in den Shell als Zeitserver eingetragen
Das ist nicht erforderlich. Der Shelly holt sich die Zeit (Synchronisation), sobald er kurzzeitig einen Zeitserver erreicht. Solange er nicht rebootet, läuft die interne Uhr auch ohne Zeitserver weiter. Für zeitgesteuerte Aufgaben (schedule jobs) wird mitunter die Uhrzeit benötigt, aber nicht in allen Fällen.
Du kannst die Suchfunktion nutzen - oben rechts.
Suchmuster: Shelly 3EM
Bei Bedarf erweiterten Filter verwenden ...
Viel Erfolg!
