Shellys ("Alt und Plus") über MQTT Adapter
-
@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 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 ;-).
-
@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 } -
@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?
-
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)?
-
@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.
-
@mickym Ja, das stimmt. Es würde ja völlig genügen einen von jedem Typ in Node RED abzufragen und dann Singal zu geben das was Neues da ist.
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@mickym Ja, das stimmt. Es würde ja völlig genügen einen von jedem Typ in Node RED abzufragen und dann Singal zu geben das was Neues da ist.
Normaler weise ist der status topic doch direkt unter dem topic des Gerätes - die Frage ist nur - ob alle Geräte auf gleicher Ebene sind und wie die mqtt Struktur aussieht.
Wie schaut es denn deine mqtt Struktur aus
-
@mickym Nein die sind aktuell nicht auf gleicher Ebene. Sondern aufgeteilt nach Art (Licht, Schalter, usw.) und dann nach den Bereichen (Keller, Garten, Dachgeschoss, EG, usw.).
-
@hotspot_2 Àuch das macht ja nichts wenn die Hierarchie die gleich ist. mqtt kannst du für jede Ebene einen Wildcard verwenden. Mach halt mal einen Screenshot und klapp die Dinger mal auf.
Ich hab das auch so:
bei mir sieht die Struktur so aus:
shellies/Art/Raum/Gerät
-
@mickym Sieht so aus:
-
dann schau mal ob das so passt auf gleicher Ebene.
shellies/+/+/+/status/sysDie + stehen für beliebigen Wert. Also wenn die Ebenen gleich sind bekommst Du damit alle topic in dem die Info steht. Das topic kannst dann auch noch über einen regulären Ausdruck ausfiltern. Keine Ahnung ob es in sys ist - musst Du wissen. Ich hab keine Gen2 Geräte.
Ansonsten kannst ja mehrer mqtt-In Nodes mit unterschiedlichen Ebenen in einen Flow laufen lassen. Du kannst ja auch das ganze topic verwenden.
Unspezifischen alles subscriben würde ich auf KEINEN Fall.
-
@mickym Wie kann ich den nochmal testen was für ein output das mqtt in node produzieren würde mit den wildcards oben? Einfach ein Debug dahintersetzen geht ja nicht.
-
@hotspot_2 Freilich einfach ein debug dahinter setzen - dann siehst du ja was rauskommt. Du solltest außerdem ein
command Datenpunkt direkt unter shellies haben. Dort das Kommando announce reinschreiben, dann werden alle Shellies ihren Status aktualisieren.
Anhand der topics der einzelnen Nachrichten siehst Du im debug doch, von welchem Shelly die Nachricht stammt.
das sollte auch für Gen2 Geräte funktionieren:
entweder für alle oder einzelne Geräte
