Alles klar. Danke. Jetzt geht es bei mir auch.
Hatte das zu dem Zeitpunkt ausschließlich mit timer_duration getestet - und diesen Schlüssel gab es logischerweise nicht in jedem Schaltzustand. Daher gab es dann ein Undefined. Außerdem hatte ich verschiedene Formatierungen mit {}, "" und auch msg.payload.timer_duration versucht. Mal wieder viel zu kompliziert gedacht.
Ja, danke. Ist tatsächlich ein hilfreicher Node, der die Übergaben der Werte deutlich erleichtert. 
Sorry für die späte Reaktion. Nach den langen Nächten ist die Arbeit etwas zu kurz gekommen. :-/
Okay. Dieser Node ist also quasi eine Kombination aus einem mqtt in + dem JSON.parser? Habe ich das so richtig verstanden?
Wie ist der Wert Payload property zu behandeln? Bekomme hier stets ein undefined ausgegeben oder eben ein unverändertes Object, wenn ich das Feld leer lasse.
Ich vermute mal, dass der Payload property einen gewünschten Wert filtern kann - ähnlich wie der switch, korrekt?
VG Dennis
Hi.
Heißt der Node wirklich mGtt json oder mQtt-json-rpc oder evtl. den node-red-contrib-mqtt-json? Zu dem ersten finde ich irgendwie keine Treffer, auch nicht im www.
Um das hier noch einmal komplett abzuschließen:
Die Ausgabe des .../status/switch:0 ist anders formatiert als die des .../events/rpc. Damit mit den Inhalten der Status-Ausgabe auch gearbeitet werden kann, muss noch ein json-Parser dahintergesetzt werden:
pasted-from-clipboard.png
Nun wird der Status des relays in eine globale Variable geschrieben und kann somit für weitere Routinen verwendet werden!
Die Erkenntnis des "Parsens" hat mich dann heute noch einmal 3 Stunden gekostet. Ich hoffe, dass andere Anfänger (so wie ich) sich mit dieser Info die Zeit der Fehlersuche sparen können.
111/events/rpc:
111/status/switch:0 vor dem json-Parser
111/status/switch:0 nach dem Parsen
Wirklich ein sehr schönes Forum. Vielen Dank für den hilfsbereiten, kompetenten und freundlichen Support.
VG Dennis
Aaaaah, wie geil!
That's it!
MQTT Explorer:
NodeRED-Flow:
NodeRED-Debug:
Und da ist wieder mein output-state.
Der String stellt glaube ich noch mehr Infos zur Verfügung, vielleicht ist das dann ausreichend. Musst dann natürlich das Topic entsprechend anpassen.
Hier hast Du es ja auch schon indirekt geschrieben (sorry). War so im Eifer unterwegs auf die UI des Shellys, dass ich Deinen Post gar nicht bis zum Ende gelesen habe.
Wie wäre denn das Status-Topic, auf welchen ich den Debug-Node mal legen könnte?
Könnte es evtl. sein, dass ich auf dem falschen Topic lausche?
Eigentlich ist die Statusabfrage ja gar kein Event. Daher wäre es ja auch logisch, dass in den periodischen Meldungen unter */events/rpc gar keine Informationen mehr über den aktuellen Status vorhanden sind, da dieser sich ja nicht geändert hat. Gibt es noch andere Topics, auf welchen die Shellys periodisch publishen?
Hallo Schubbie
Danke für Deine rasche Antwort.
In dem periodischen Update (bei mir alle 30 Sekunden) ist die Information zum Schaltzustand leider nicht enthalten:
pasted-from-clipboard.png
In der API-Dokumentation steht etwas zu einem GetStatus über MQTT, jedoch verstehe ich nicht, wie ich das in NodeRED im Payload/Topic einfügen kann. Oder ist das vielleicht etwas Anderes, was ich hier gefunden habe?
Danke auch für den Hinweis mit dem HTTP-Request. Das befriedigt allerdings nicht meinen inneren Monk 
Die Challenge ist eigentlich die, ausschließlich mit MQTT zu arbeiten. Aber ok - wenn es wirklich nicht darüber geht, dann bleibt mir ja nur diese Option. Fühlt sich aber irgendwie geschummelt an. 
Hallo Shelly-Forum.
Seit 2 Tagen spiele ich mit MQTT und NodeRED herum. Trotz täglicher Erfolgserlebnisse stehe ich natürlich immer noch sehr sehr weit am Anfang.
Schalten aus NodeRED heraus funktioniert bereits. Auch wenn ich über den Taster direkt am Shelly 1PM Mini 2.Gen schalte (single_push, double_push, usw.) kommen diese Infos in NodeRED an und lassen dann andere Aktionen auslösen. Auch die periodischen MQTT-Meldungen eines jeden Gerätes sehe ich in einem Debug-Node.
Hierbei ist mir aufgefallen, dass der Schaltzustand eines Relais jedoch nur unmittelbar nach Änderung eines Schaltvorgangs einmalig mitgeteilt wird ("output":true/false). Danach nicht erneut. Diesen Schaltzustand hinterlege ich mir aktuell zwar in einer Variable, aber wenn der NodeRED nun mal neugestartet werden muss oder eben erst später hinzukommt, dann sind die Informationen über die aktuellen IST-Zustände aller Shellys ja nicht mehr vorhanden.
Ich würde daher gerne beim Start von NodeRED einmalig von allen Shellys den Zustand des relays abrufen, was ich bislang leider nicht hinbekommen habe.
Daher meine Frage:
Wie muss der Payload und das Topic im MQTTout aussehen, damit das Senden eines Gesamtstatus getriggert wird, welches ich dann am MQTTin erhalte?
VG Dennis
PS: ich freue mich auch auf Hinweise, ob ich überhaupt in die richtige Richtung laufe. Eventuell bin ich mit meiner Vorgehensweise (Variablen und Boolean Logic in NodeRED und MQTT) ja auch in einem falschen bzw. nicht-idealen Denkmuster gefangen. Tipps und Ideen hierzu nehme ich daher dankend an.
Ok. Also dafür ist der Bereich Scripts, den ich schon in der GUI des Gerätes gesehen habe. Also das mit Shelly.addEventHandler usw.?
Wenn jedoch 4 Vorgänge das Maximum sind, dann sind komplexere Szenarien scheinbar nur mit der Cloud realisierbar - aber das ist auch ok. Für mich ist eben nur wichtig, dass die Grundfunktionen Licht an / Licht aus nicht über das Internet laufen. Mit den Zigbee-Geräten und der Alexa ist es nämlich auch so gewesen. Ich hatte alle Schalter entfernt und überall Aktoren verbaut - und als das Internet dann mal weg gewesen ist, hab ich morgens sogar im Dunkeln frühstücken müssen. Das war wirklich nervig - mit der Taschenlampe durch die eigene Bude zu robben, weil das SmartHome kein Internet hat.
Vielen Dank nochmal für Eure Geduld und die klaren Auskünfte. Ein sehr schönes Forum hier.
Euch allen einen schönen 2. Advent - und bleibt gesund.
Gruß aus Schleswig-Holstein
Dennis
Ach wie geil
Funktioniert. Licht an - Licht aus. Riesig! Danke Dir!
Nochmal zum Verständnis für eine zukünftige Nutzung mit Geräten, die ausschließlich aus dem Shelly-Universum kommen (also ohne Alexa, Zigbee und Co.):
Der Szeneninhalt liegt hier nun in der Cloud. D.h., dass ohne eine bestehende Internetverbindung der Schaltvorgang nicht funktionieren würde. Habe ich das so richtig verstanden?
Gibt es auch eine Möglichkeit die Szene im I4 direkt zu hinterlegen, damit bei einem eventuellen Ausfall des Internets trotzdem lokal geschaltet werden kann und ggf. auch über einen lokalen Aufruf im eigenen LAN unter 192......./ das Ganze funktioniert? Wäre hier dann nicht auch eine geringere Latenz zwischen Aktion und Reaktion vorhanden, da der Umweg über die Cloud gespart wird?
VG Dennis
Hi.
Vielen Dank für Eure raschen Antworten.
Vermutlich habe ich hier einen Denkfehler in meiner provisorischen Schaltung. Wie beschrieben, bin ich gerade rerst dabei auf Shelly zu wechseln und habe derzeit lediglich einen Plus I4, einen Pro 3EM und zwei Plus PM Mini im Einsatz. Da die ganzen bestellten Aktoren Plus 1PM Mini noch in der Post sind und erst am Mittwoch kommen sollen, wollte ich nun schonmal mit dem Taster loslegen und habe daher in der Shelly Cloud Alexa-Benachrichtigungen für die Tastvorgänge gesetzt. Diese Benachrichtigungen lösen aktuell in meiner Alexa entsprechende Routinen aus, welche die noch vorhandenen Zigbee Plugs und RGBW-Controller steuern.
Demnach habe ich derzeit gar keine Auslöse-URLs. Wahrscheinlich erklärt es sich von selbst, wenn ich kommende Woche dann die Aktoren im Einsatz habe und die Konfiguration dann auch direkt in den Geräten, statt in der Cloud vornehme, korrekt?
horkatz Vielen Dank für Dein freundliches Angebot, Dir Zeit für mein Anliegen zu nehmen. Ich bin heute ganztägig unter https://rtc.s71.de/shelly zu erreichen.
Hallo.
Ich wechsele gerade von Zigbee auf Shelly und arbeite mich langsam ein. Aktuell nutze ich einen Shelly Plus i4 im Wohnzimmer, an welchem bislang zwei Taster unterschiedliche Szenen auslösen und/oder Geräte schalten können. Jetzt versuche ich gerade den korrekten Webhook herauszufinden, mit welchem ich über einen URL-Aufruf ebenfalls einen Tasterdruck aus der Ferne emulieren kann:
http://[lokale-IPv4-vom-ShellyPlusI4]/rpc/single_push?id=0
http://[lokale-IPv4-vom-ShellyPlusI4]/rpc/input.button_push?id=0
http://[lokale-IPv4-vom-ShellyPlusI4]/rpc/Switch.Set?id=0,on=trueFunktioniert nur leider alles nicht. Hat jemand die korrekte Syntax für mich?
Danke+Gruß
Dennis