NEWS
Shellys ("Alt und Plus") über MQTT Adapter
-
@hotspot_2 Ich verstehe die Frage nicht. Laut status werden doch die iobroker-In Nodes eingelesen. Was hast Du in msg.delay - ist Dir klar dass der Wert in ms angegeben wird?
@mickym Ja, das ist mir klar. Vielleicht liegt es auch an meiner Denkweise.
Wird der Wert in Trigger überhaupt aktuell angezogen wenn der eigentliche Trigger für die Schaltung von einem anderen Strang / Zweig kommt? Das ist eigentlich meine Frage. Ich denke mir im Moment das dadurch das der Trigger nicht vom iobroker in kommt beim Schaltvorgang der Werte nicht aktuell eingelesen wird durch den oberen Strang oder unteren im zweiten Flow.
-
@mickym Ja, das ist mir klar. Vielleicht liegt es auch an meiner Denkweise.
Wird der Wert in Trigger überhaupt aktuell angezogen wenn der eigentliche Trigger für die Schaltung von einem anderen Strang / Zweig kommt? Das ist eigentlich meine Frage. Ich denke mir im Moment das dadurch das der Trigger nicht vom iobroker in kommt beim Schaltvorgang der Werte nicht aktuell eingelesen wird durch den oberen Strang oder unteren im zweiten Flow.
@hotspot_2 Wenn Du über die rosa mqtt-Nodes gehst gehst Du nicht über den iobroker, wenn Du über die iobroker Node gehst schon. Ich weiss gerade nicht ob du mosquitto als Broker nutzt oder den mqtt-Adapter.
-
@hotspot_2 Wenn Du über die rosa mqtt-Nodes gehst gehst Du nicht über den iobroker, wenn Du über die iobroker Node gehst schon. Ich weiss gerade nicht ob du mosquitto als Broker nutzt oder den mqtt-Adapter.
-
Wenn jetzt über die rosa Mqtt-Nodes ein Event kommt und der Flow startet. Wird dann zu dem Zeitpunkt auch der dann im iobroker objekt stehende Wert ausgelesen?
@hotspot_2 Nein!! - Dieser Wert wird nur ausgelesen wenn Du den änderst. Wenn Du innerhalb eines Flows einen Wert auslesen willst dann musst Du die GET Node verwenden. Achte aber darauf, dass Du Dir die payload nicht überschreibst. Also müsstest Du die delay Nachrichteneigenschaft bereits in der Get Node setzen:
Also mit einer GetNode die Verzögerung holen und in den Flow einbauen, in dem Du es hiner die mqtt-In Node schaltest:
-
@hotspot_2 Nein!! - Dieser Wert wird nur ausgelesen wenn Du den änderst. Wenn Du innerhalb eines Flows einen Wert auslesen willst dann musst Du die GET Node verwenden. Achte aber darauf, dass Du Dir die payload nicht überschreibst. Also müsstest Du die delay Nachrichteneigenschaft bereits in der Get Node setzen:
Also mit einer GetNode die Verzögerung holen und in den Flow einbauen, in dem Du es hiner die mqtt-In Node schaltest:
@mickym Ich habe mir jetzt ein iobroker get node eingebaut, aber irgendwie klappt das einlesen des Wertes nicht so wie ich mir das vorstelle:
Die Payload sieht nicht so aus wie gedacht. Ich habe mir gedacht ich kann dann danach auf den eingelesen Wert so zugreifen:
Was mache ich denn da falsch?
-
@mickym Ich habe mir jetzt ein iobroker get node eingebaut, aber irgendwie klappt das einlesen des Wertes nicht so wie ich mir das vorstelle:
Die Payload sieht nicht so aus wie gedacht. Ich habe mir gedacht ich kann dann danach auf den eingelesen Wert so zugreifen:
Was mache ich denn da falsch?
@hotspot_2 die Eigenschaft, die du in deiner Switch Node untersuchst ist keine Eigenschaft von payload, sondern direkt des msg Objektes. Die get-node kann auch kein tieferes Level setzen.
Deshalb musst du in deiner Switch Node nicht auf
„msg.payload.meldung_an_weitere_1“ untersuchen, sondern „msg.meldung_an_weitere_1“.Wenn du meine beiden Nodes importiert hättest- dann müsstest du das sehen. Wenn du eine debug-Node hinter die iobroker get-Node hängst und Dir das komplette Nachrichtenobjekt und nicht nur die payload ausgeben läßt, dann siehst du das.
-
@hotspot_2 die Eigenschaft, die du in deiner Switch Node untersuchst ist keine Eigenschaft von payload, sondern direkt des msg Objektes. Die get-node kann auch kein tieferes Level setzen.
Deshalb musst du in deiner Switch Node nicht auf
„msg.payload.meldung_an_weitere_1“ untersuchen, sondern „msg.meldung_an_weitere_1“.Wenn du meine beiden Nodes importiert hättest- dann müsstest du das sehen. Wenn du eine debug-Node hinter die iobroker get-Node hängst und Dir das komplette Nachrichtenobjekt und nicht nur die payload ausgeben läßt, dann siehst du das.
-
@mickym Ok, verstanden. Das teste ich mal aus.
Warum wird mir aber im Debug nicht angezeigt ob der Werte dann true oder false ist?
@hotspot_2 habe ich dir gerade erklärt, weil du dir in der Debug Node nur die Nachrichteneigenschaft payload und nicht das komplette Nachrichtenobjekt ausgeben läßt. Das musst du halt in der debug node umstellen. In der payload stehen ja die Werte aus der mqtt Node.
Steht doch auch im Debugfenster, was Du Dir ausgeben läßt:
msg.payload: numberAlso die Nachrichteneigenschaft payload des Nachrichtenobjektes mit Datentyp:number. Jedenfalls enthält die payload ja einen Datum, woher auch immer.
-
@hotspot_2 habe ich dir gerade erklärt, weil du dir in der Debug Node nur die Nachrichteneigenschaft payload und nicht das komplette Nachrichtenobjekt ausgeben läßt. Das musst du halt in der debug node umstellen. In der payload stehen ja die Werte aus der mqtt Node.
Steht doch auch im Debugfenster, was Du Dir ausgeben läßt:
msg.payload: numberAlso die Nachrichteneigenschaft payload des Nachrichtenobjektes mit Datentyp:number. Jedenfalls enthält die payload ja einen Datum, woher auch immer.
-
Jetzt passt es! Das Debug Node angepasst und schon sehe ich alles ;-).
Super, jetzt kann ich weitermachen.
@hotspot_2 Ich hätte nochmal eine Frage zur Get Node. Das einlesen des Wertes funktioniert einwandfrei aber sie überschreibt mir msg.topic mit dem Namen des ioBroker Objekts. Ich brauche aber msg.topic zur Übergabe an die Pushover Node später.
Kann man das irgendwie lösen?
-
@hotspot_2 Ich hätte nochmal eine Frage zur Get Node. Das einlesen des Wertes funktioniert einwandfrei aber sie überschreibt mir msg.topic mit dem Namen des ioBroker Objekts. Ich brauche aber msg.topic zur Übergabe an die Pushover Node später.
Kann man das irgendwie lösen?
@hotspot_2 dann musst du vor der get Node die msg.topic in eine andere Nachrichteigenschaft wegsichern (verschieben oder setzen) und nach der get node wieder das topic restaurieren. Also Change Node davor und danach.
-
@hotspot_2 dann musst du vor der get Node die msg.topic in eine andere Nachrichteigenschaft wegsichern (verschieben oder setzen) und nach der get node wieder das topic restaurieren. Also Change Node davor und danach.
@mickym Hallo, ich würde gerne checken ob für die Shellys (das Beispiel hier ist der Shelly Plus 1 und dann eine Meldung auslösen.
{ "mac": "A8032ABD5E90", "restart_required": false, "time": "17:29", "unixtime": 1687879763, "uptime": 3888016, "ram_size": 234760, "ram_free": 160548, "fs_size": 458752, "fs_free": 106496, "cfg_rev": 16, "kvs_rev": 2, "schedule_rev": 0, "webhook_rev": 0, "available_updates": { "beta": { "version": "1.0.0-beta5" } } }So so sieht das JSON aus das der Shelyl liefert über MQTT. Kannst Du mir einen Tipp geben wie ich auswerten könnte das in "avalaible_updates" : "beta" oder "stable" da ist und auch die Version dann auslesen kann?
Ich würde dann für jeden Shelly Typ (Plus 1, Smoke, Plug usw.) einfach ein Node anlegen und mir dann z.B. eine Mail schicken wenn es Updates gibt, so der Plan ;-).
-
@mickym Hallo, ich würde gerne checken ob für die Shellys (das Beispiel hier ist der Shelly Plus 1 und dann eine Meldung auslösen.
{ "mac": "A8032ABD5E90", "restart_required": false, "time": "17:29", "unixtime": 1687879763, "uptime": 3888016, "ram_size": 234760, "ram_free": 160548, "fs_size": 458752, "fs_free": 106496, "cfg_rev": 16, "kvs_rev": 2, "schedule_rev": 0, "webhook_rev": 0, "available_updates": { "beta": { "version": "1.0.0-beta5" } } }So so sieht das JSON aus das der Shelyl liefert über MQTT. Kannst Du mir einen Tipp geben wie ich auswerten könnte das in "avalaible_updates" : "beta" oder "stable" da ist und auch die Version dann auslesen kann?
Ich würde dann für jeden Shelly Typ (Plus 1, Smoke, Plug usw.) einfach ein Node anlegen und mir dann z.B. eine Mail schicken wenn es Updates gibt, so der Plan ;-).
@hotspot_2 Meines Erachtens brauchst Du das nicht.
Du solltest eigentlich in jedem Shelly einen INFO Datenpunkt haben. Dort gibts eine Eigenschaft: has_update. Der steht auf true wenn es ein Update gibt.
-
@hotspot_2 Meines Erachtens brauchst Du das nicht.
Du solltest eigentlich in jedem Shelly einen INFO Datenpunkt haben. Dort gibts eine Eigenschaft: has_update. Der steht auf true wenn es ein Update gibt.
@mickym Ja, den gibt es. Aber es sieht für mich so aus das der nur bei den Gen1 Devices vorhanden ist.
{ "wifi_sta": { "connected": true, "ssid": "FFHomeNet24", "ip": "192.168.3.56", "rssi": -54 }, "cloud": { "enabled": false, "connected": false }, "mqtt": { "connected": true }, "time": "19:13", "unixtime": 1687885996, "serial": 1, "has_update": false, "mac": "C8C9A388F8FA", "cfg_changed_cnt": 0, "actions_stats": { "skipped": 0 }, "relays": [ { "ison": false, "has_timer": false, "timer_started": 0, "timer_duration": 0, "timer_remaining": 0, "overpower": false, "source": "mqtt" } ], "meters": [ { "power": 0, "overpower": 0, "is_valid": true, "timestamp": 1687893196, "counters": [ 0, 0, 0 ], "total": 10074 } ], "temperature": 33.46, "overtemperature": false, "tmp": { "tC": 33.46, "tF": 92.23, "is_valid": true }, "update": { "status": "idle", "has_update": false, "new_version": "20230503-101129/v1.13.0-g9aed950", "old_version": "20230503-101129/v1.13.0-g9aed950" }, "ram_total": 52056, "ram_free": 39664, "fs_size": 233681, "fs_free": 166664, "uptime": 1540988 } -
@mickym Ja, den gibt es. Aber es sieht für mich so aus das der nur bei den Gen1 Devices vorhanden ist.
{ "wifi_sta": { "connected": true, "ssid": "FFHomeNet24", "ip": "192.168.3.56", "rssi": -54 }, "cloud": { "enabled": false, "connected": false }, "mqtt": { "connected": true }, "time": "19:13", "unixtime": 1687885996, "serial": 1, "has_update": false, "mac": "C8C9A388F8FA", "cfg_changed_cnt": 0, "actions_stats": { "skipped": 0 }, "relays": [ { "ison": false, "has_timer": false, "timer_started": 0, "timer_duration": 0, "timer_remaining": 0, "overpower": false, "source": "mqtt" } ], "meters": [ { "power": 0, "overpower": 0, "is_valid": true, "timestamp": 1687893196, "counters": [ 0, 0, 0 ], "total": 10074 } ], "temperature": 33.46, "overtemperature": false, "tmp": { "tC": 33.46, "tF": 92.23, "is_valid": true }, "update": { "status": "idle", "has_update": false, "new_version": "20230503-101129/v1.13.0-g9aed950", "old_version": "20230503-101129/v1.13.0-g9aed950" }, "ram_total": 52056, "ram_free": 39664, "fs_size": 233681, "fs_free": 166664, "uptime": 1540988 }@hotspot_2 Ok - ich sehe - na dann frag halt ab, ob es eine stable Version gibt.
{ "ble": {}, "cloud": { "connected": false }, "input:0": { "id": 0, "state": false }, "mqtt": { "connected": true }, "script:1": { "id": 1, "running": false }, "switch:0": { "id": 0, "source": "init", "output": false, "temperature": { "tC": 46.5, "tF": 115.8 } }, "sys": { "mac": "A8032ABE54DC", "restart_required": false, "time": "16:41", "unixtime": 1675262494, "uptime": 571, "ram_size": 234820, "ram_free": 162244, "fs_size": 458752, "fs_free": 110592, "cfg_rev": 7, "kvs_rev": 1, "schedule_rev": 0, "webhook_rev": 0, "available_updates": { "beta": { "version": "0.13.0-beta1" }, "stable": { "version": "0.12.0" } } }, "wifi": { "sta_ip": "192.168.1.101", "status": "got ip", "ssid": "TP-LINK_F862", "rssi": -68 }, "ws": { "connected": false } }Es scheint so zu sein, dass wenn eine stable Version verfügbar ist, dann ist diese unter available Updates gelistet.
Das sollte doch im status topic vorhanden sein, oder?
-
@hotspot_2 Ok - ich sehe - na dann frag halt ab, ob es eine stable Version gibt.
{ "ble": {}, "cloud": { "connected": false }, "input:0": { "id": 0, "state": false }, "mqtt": { "connected": true }, "script:1": { "id": 1, "running": false }, "switch:0": { "id": 0, "source": "init", "output": false, "temperature": { "tC": 46.5, "tF": 115.8 } }, "sys": { "mac": "A8032ABE54DC", "restart_required": false, "time": "16:41", "unixtime": 1675262494, "uptime": 571, "ram_size": 234820, "ram_free": 162244, "fs_size": 458752, "fs_free": 110592, "cfg_rev": 7, "kvs_rev": 1, "schedule_rev": 0, "webhook_rev": 0, "available_updates": { "beta": { "version": "0.13.0-beta1" }, "stable": { "version": "0.12.0" } } }, "wifi": { "sta_ip": "192.168.1.101", "status": "got ip", "ssid": "TP-LINK_F862", "rssi": -68 }, "ws": { "connected": false } }Es scheint so zu sein, dass wenn eine stable Version verfügbar ist, dann ist diese unter available Updates gelistet.
Das sollte doch im status topic vorhanden sein, oder?
@mickym Das oben steht im topic status/sys was ich in das Code Fenster kopiert habe.
Bin im Moment etwas überfordert wie ich jetzt abfrage stable oder beta und dann die Versionsnummer noch in der Message / Mail mit geben könnte.
Geht das auch mit den Punkten?
-
@mickym Das oben steht im topic status/sys was ich in das Code Fenster kopiert habe.
Bin im Moment etwas überfordert wie ich jetzt abfrage stable oder beta und dann die Versionsnummer noch in der Message / Mail mit geben könnte.
Geht das auch mit den Punkten?
Kannst Du zwar machen - aber das brauchst nicht - abonniere einfach diesen Datenpunkt und prüfe ab, obe eine stable Version verfügbar ist:
Wenn Du dann auch noch die Version extrahieren willst - dann schreibst die halt in ein Mail
Von mir aus schreibst was in einen Datenpunkt - aber das analysieren des JSON sollte doch für Dich kein Problem sein und kannst es auch direkt in eine Mail-Node schreiben.
Einfach Pfad kopieren und du kannst doch auf jede Info zugreifen.
Du kannst natürlich auch die Analyse direkt als true oder false in einen DP schreiben - aber in meinen Augen überflüssig.
Kanst ja auch mit Wildcard die status topics abonnieren und dann das topic analysieren.
-
Kannst Du zwar machen - aber das brauchst nicht - abonniere einfach diesen Datenpunkt und prüfe ab, obe eine stable Version verfügbar ist:
Wenn Du dann auch noch die Version extrahieren willst - dann schreibst die halt in ein Mail
Von mir aus schreibst was in einen Datenpunkt - aber das analysieren des JSON sollte doch für Dich kein Problem sein und kannst es auch direkt in eine Mail-Node schreiben.
Einfach Pfad kopieren und du kannst doch auf jede Info zugreifen.
Du kannst natürlich auch die Analyse direkt als true oder false in einen DP schreiben - aber in meinen Augen überflüssig.
Kanst ja auch mit Wildcard die status topics abonnieren und dann das topic analysieren.
@mickym Super! Danke, das hilft.
Das mit den Wildcards klingt interessant. Könnte ich damit alle Status topics z.B. alles was unterhalb vom topic "shelies" bei mir kommt vom MQTT Adapter analysieren und dann jeweils ermitteln von wem die Meldung kommt (IP oder Name)?
-
@mickym Super! Danke, das hilft.
Das mit den Wildcards klingt interessant. Könnte ich damit alle Status topics z.B. alles was unterhalb vom topic "shelies" bei mir kommt vom MQTT Adapter analysieren und dann jeweils ermitteln von wem die Meldung kommt (IP oder Name)?
@hotspot_2 Wie schaut denn Deine Struktur aus? Und dieses Info ist unter status? Du brauchst doch nicht alles - sondern nur das status topic!!! Wichtig ist halt dass Du Deine mqtt Struktur hierarchisch identisch aufgebaut hast.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@hotspot_2 Wie schaut denn Deine Struktur aus? Und dieses Info ist unter status? Du brauchst doch nicht alles - sondern nur das status topic!!! Wichtig ist halt dass Du Deine mqtt Struktur hierarchisch identisch aufgebaut hast.
309
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge