MSG Payload werte auslesen

[mickym]

@frankyboy73 sagte in MSG Payload werte auslesen:

@mickym Ok, das werde ich mir mal abspeichern, ist ja für mich wesentlich übersichtlicher als das mit ner Funktion umzusetzen und einfacher. Danke.
Sehe ich das richtig das du hier den reset von all deinen Shellys ausliest und dir dann ausgibst von welchem Shelly die msg. kommt? Wenn ja, wie kann ich denn über Node Red mit ner Input bzw. Get Node alle Geräte einer Gruppe (bei mir Sonoff) auslesen. Ich überwache z.B. meine Sonoffs auf erreichbarkeit, bis jetzt habe ich ne eigene Input Node für jeden Sonoff, da ich viele habe, kommt da ne ganze Menge zusammen. Wäre schön wenn ich das reduzieren könnte und dann nur noch auswertet, von welchem Sonoff die msg. kommt.

Übrigens in Ergänzung zu den anderen Post - ich habe Sonoff mit Tasmota geflasht und das wird auch analog zu den Shellies über MQTT überwacht:

Hier habe ich übrigens zur Überwachung einfach den Trigger Node zur Überwachung genutzt, ob das Gerät noch lebt. Die Geräte melden sich ja via mqtt - das sollte aber auch mit dem In-Node von iobroker funktionieren, wenn Du immer Nachrichten erzeugst und nicht nur bei Änderung. Sollte sich ein Gerät 6 min nicht gemeldet haben - erzeugt der Trigger Node dann eine "false" Nachricht!

Den Switch brauchst Du aber nur, wenn Du das topic in lesbare Geräte umsetzen willst. So steht ja im Topic immer der komplete Pfad zum Object und Du brauchst nur einen Trigger und eine JOIN Node um das umzusetzen (musst das halt in der Handhabung - statt für alle Nachrichten - auf für jeden Wert unabhängig setzen.

[frankyboy73]

@mickym Hi, vielen Dank für die vielen ausführlichen Antworten.
Ich hatte es bis jetzt so gelöst, das ich mit ner Input Node von jedem Sonoff die Time auf Änderung abfrage. Damit auf nen Trigger, wenn dann nach 30 Minuten keine Änderung kam, ne Nachricht mit dem Topic des Sonoffs per Telegramm Sonoff soundso meldet sich nicht.
Jetzt versuche ich es gerade mit der List Node, damit frage ich den alive Status der Sonoffs ab "sonoff.0.*.alive", alle 5 Minuten, dahinter ne RBE damit ich nur Änderungen mitkriege, dann nen Switch, mit Abrage auf false, damit setzte ich nen Trigger 6 Minuten, den ich zurücksetze falls der Sonoff wieder alive true ist, damit ich nur nen längeren Ausfall gemeldet kriege. Danach lasse ich mir per Funktion Node das Topic des ausgefallenen Sonoffs per Telegramm senden. Die Lösung die Time auf Änderung zu überwachen ist wahrscheinlich die sichere, ich weiß ja nicht ob die Adapter Rückmeldung "Alive" so sicher ist. Aber ich brauche jetzt nur noch einen Trigger und eine Listen Node und nicht mehr über 20 Input Nodes wie sonst.

[mickym]

@frankyboy73 Also nur mal ein paar Anregungen zur Optimierung,

Als 1. weiß ich nicht ob das ein eigener Node ist - aber ansonsten kann man den normalen Inject Node auch nutzen um zyklische Abfragen zu generieren - dafür braucht es meines erachtens keinen CRON.
2. Eventuell kann man den Rest auch super vereinfachen - da bin ich mir aber nicht ganz sicher.

Du konfigurierst den trigger Node wie folgt:

Mit der Handhabung sollte der trigger Node nun ja auf jeden msg.topic die von dem iobroker list node generiert wird unterschiedlich reagieren.

Kommt also von einem speziellen msg.topic 6 Minuten nichts an - sendet der Trigger - "false" und ansonsten einfach gar nichts. Du kannst natürlich für jeden msg.topic zum Beginn auch ein True schicken, um zu überprüfen, dass jedes Gerät auch 1 mal gesendet hat.

[mickym]

@frankyboy73 Ohne Garantie hier mal ein Versuch der Vereinfachung:

[
    {
        "id": "413cec0e.1c8994",
        "type": "inject",
        "z": "dce8fa20.2e93c8",
        "name": "Alle 5 Minuten",
        "props": [
            {
                "p": "payload"
            },
            {
                "p": "topic",
                "vt": "str"
            }
        ],
        "repeat": "300",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "sonoff.0.dummy.alive",
        "payload": "true",
        "payloadType": "bool",
        "x": 120,
        "y": 1380,
        "wires": [
            [
                "7fab1454.5756bc"
            ]
        ]
    },
    {
        "id": "7fab1454.5756bc",
        "type": "ioBroker list",
        "z": "dce8fa20.2e93c8",
        "name": "Sonoffs alive",
        "topic": "sonoff.0.*.alive",
        "objType": "state",
        "regex": "",
        "asArray": "false",
        "onlyIDs": "false",
        "withValues": "true",
        "x": 320,
        "y": 1380,
        "wires": [
            [
                "975325ba.b9aa58"
            ]
        ]
    },
    {
        "id": "dbf63722.beef58",
        "type": "trigger",
        "z": "dce8fa20.2e93c8",
        "name": "",
        "op1": "verbunden",
        "op2": "nicht verbunden",
        "op1type": "str",
        "op2type": "str",
        "duration": "6",
        "extend": true,
        "overrideDelay": false,
        "units": "min",
        "reset": "",
        "bytopic": "topic",
        "topic": "topic",
        "outputs": 1,
        "x": 780,
        "y": 1380,
        "wires": [
            [
                "5fd5c116.79242"
            ]
        ]
    },
    {
        "id": "5fd5c116.79242",
        "type": "change",
        "z": "dce8fa20.2e93c8",
        "name": "Nachricht erstellen",
        "rules": [
            {
                "t": "set",
                "p": "payload",
                "pt": "msg",
                "to": "topic & \" \" & payload ",
                "tot": "jsonata"
            }
        ],
        "action": "",
        "property": "",
        "from": "",
        "to": "",
        "reg": false,
        "x": 990,
        "y": 1380,
        "wires": [
            [
                "846bc903.448268"
            ]
        ]
    },
    {
        "id": "846bc903.448268",
        "type": "debug",
        "z": "dce8fa20.2e93c8",
        "name": "",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 1190,
        "y": 1380,
        "wires": []
    },
    {
        "id": "975325ba.b9aa58",
        "type": "switch",
        "z": "dce8fa20.2e93c8",
        "name": "msg.payload.val = true",
        "property": "payload.val",
        "propertyType": "msg",
        "rules": [
            {
                "t": "true"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 1,
        "x": 560,
        "y": 1380,
        "wires": [
            [
                "dbf63722.beef58"
            ]
        ]
    }
]

Ich habe es gerade getestet - das funktioniert tatsächlich für jedes msg.topic. Die Anzahl der Nachrichten die im trigger zurückgehalten werden, werden sogar angezeigt.

Mich begeistert dieses Programm immer wieder. - Die 1 min hier war nur zum Test -damit ich keine 6 Minuten warten musste.

Korrektur: Ich hatte noch einen Denkfehler drin - Du musst doch eine switch - aber mit true zwischenschalten. Den muss man halt ggf. noch anpassen - je nachdem ob das true als Boolean oder als String kommt.

Alternativ kann man auch im trigger node - den Auslöser zurücksetzen. Indem Du msg.payload.val über eine Change Node in msg.payload setzt -

[frankyboy73]

@mickym Hi, vielen Dank, habe es mal nachgebaut. Sieht bis jetzt gut aus, auch simulierte Ausfälle werden mir gemeldet. Lasse das jetzt erst mal so laufen.
Bei den Injekt Nodes dachte ich immer ich müsste sie einmal anschubsen damit der Intervall läuft, deshalb habe ich nen Cron verwendet. Habe jetzt festgestellt, das es ja nicht so ist und der Intervall auch so läuft.
Jetzt wollte ich das gleiche noch mit meinen Deconz (Zigbee) Sensoren umsetzen, damit habe ich nur leider das Problem das die Objekt Ordner nur Nummern und nicht so wie bei den Sonoffs spezifische Namen haben. Wenn ich jetzt das Topic auslese kriege ich nur Nummern und muss erst mal nachschauen welcher Sensor es ist. Kann man da auch irgendwie die Namen der Objekte auslesen oder müsste ich die Ordner alle umbenennen, wobei ich nicht weiß ob das irgendwelche negativen Auswirkungen hätte.

[mickym]

@frankyboy73 sagte in MSG Payload werte auslesen:

Gibt es denn in den Ordnern (also weiter unten in der Hierachie? ) keinen Wert der mit Klartext das Gerät bezeichnet?

Ansonsten gäbe es noch folgende Alternativen. Du erstellst selbst ein JSON String bzw. Java Objekt als Übersetzungstabelle oder machst Dir eine herstellerunabhängige Alias-Struktur - das ist zwar erst mal eine Menge Aufwand aber dann hast Du immer die gleiche Struktur. Wenn ein Hersteller diese Struktur nicht anbietet bleibt sie halt leer.

Ich mach mal einen Screenshot - wie ich das gelöst habe:

Oben sind das Parameter aus dem Shelly Baum - unten aus dem Tasmota Baum

Hab aber auch nicht alles drin - z. Bsp Zigbees sind aber auch streng genommen keine Schalter und Relais.

[mickym]

@frankyboy73 Ich habe noch was entdeckt - soweit ich sehe enthält doch der Name den Klartext. Wenn Du mit dem iobroker list node arbeitest bekommst Du doch immer die kompletten Objekte. Unter common.name sollte doch der name im Klartext stehen.

Ich habe gerade festgestellt, dass wen der iobroker list topic mit dem * auf einen Ordner verweist, dann werden alle Objekte unter dem Ordner aufgelistet, d.h Du musst ggf. sowieso filtern.

[frankyboy73]

@mickym Hi, die Alias sind schon mal ne gute Idee, mal schauen wenn ich ganz viel Zeit habe, ob ich das umsetzte.
Die List Node kann mir auch den Namen auslesen wenn ich sie richtig einstelle. Danke für den Denkanstoß.
Bei den Zigbee Sensoren ist es so das sie sich in bestimmten Intervallen melden, der Batterienwert wird aktualisiert. Das werte ich mit ner Input Node und nem Trigger aus. Gibt es eine bestimmte Zeit keine Aktualisierung, sage ich Sensor soundso meldet sich nicht. Da hatte ich bis jetzt für jede Node nen eigenen Trigger und ne festen Text verwendet. Durch deine Idee mit der List Node führe ich die Input Nodes jetzt alle durch einen Trigger bei dem ich sage "ürgsprüngliches msg senden", mit ner List Node dahinter, bei der ich das Topic Feld frei lasse. Damit wird jetzt das Topic Feld von der Input Node beschrieben die sich nicht mehr meldet und ich kann den Namen auslesen. Super, ich liebe Node Red. Klappt bis jetzt einwandfrei.
Sorry dafür das ich immer noch ne Funktion Node zum Text erstellen nutze, aber damit kenne ich mich besser aus.

[frankyboy73]

@mickym Zusätzlich kriege ich jetzt noch ne Meldung wenn eine der Batterien unter 10% ist mit dem passenden Namen. Ich musste nur noch die Reihenfolge der Nodes ändern.

[mickym]

@frankyboy73 Genau bei den Zigbees habe ich ein Interval von 2 Std. genutzt und das funktioniert ganz gut.

Ursprünglich war ich etwas verwirrt bei Deinem ersten Flow - weil Du den Trigger vor anstelle hinter die List Node gestellt hast, aber im letzten Flow hast Du es ja dann korrigiert.

Und dafür dass Du Deine Function Node für die Textausgabe nutzt - ist ja OK. Ich mach mal einen Screenshot wie es mit einem Change Node funktionieren würde. Da ich ja jetzt den Inhalt Deiner Function Node kenne.

[frankyboy73]

@mickym Ah, ok, dann werde ich das jetzt mal mit der change Node umsetzen. Danke. Dann werde ich auch mal so nach und nach meine anderen Funktion Nodes (Texterstellung) dadurch ersetzen. Und für die Zukunft habe ich ja jetzt deine Vorlage.

[mickym]

@frankyboy73 sagte in MSG Payload werte auslesen:

@mickym Ah, ok, dann werde ich das jetzt mal mit der change Node umsetzen. Danke. Dann werde ich auch mal so nach und nach meine anderen Funktion Nodes (Texterstellung) dadurch ersetzen. Und für die Zukunft habe ich ja jetzt deine Vorlage.

Musst Du nicht. - Da machst ja auch nicht viel kaputt in Deiner Übersicht. Um was es mir ging habe ich ja am Anfang dieses Threads mit einem Beispiel versucht zu verdeutlichen. Bei komplexen Funktionen nimmt man sich halt die Möglichkeiten der Visualisierung eines Programmflows - das ja eine der Stärken von Node-Red ist. Letztlich ist jedes Programm, ob Blockly oder Javascript oder auch sonstiges Programm ja eine Abfolge von Anweisungen, die abgearbeitet werden und somit auch einen Flow darstellen.

Manchmal geht es ja auch nicht anders und deswegen gibt es ja auch die Function Nodes. Ich kann auch nur aus eigener Erfahrung sagen, dass ich am Anfang auch viele Function Nodes genutzt habe und dann irgendwann festgestellt habe, dass ich immer weniger verwende.

Ich nutze auch manchmal function Nodes die gar nichts machen (also nur "return msg") um einen Flow grafisch besser zu strukturieren.

[BF532]

Hallo Leute,
vielleicht könnt ihr mir ja weiterhelfen. Ich bekomme es nicht zusammen hier einzelne Objekte z.b die Temperatur als Zahl für weitere Verarbeitung raus zu bekommen.

[mickym]

@bf532
müsste sein:

msg.payload.devices[0].modules[2].dashboard_data.Temperature

also change Node mit setze

msg.payload auf

msg.payload.devices[0].modules[2].dashboard_data.Temperature

musst Dich halt ggf. mit debug Nodes durchhangeln. also erst debug Node auf msg.payload.devices[0] usw.

Es gibt ausserdem einen ganz einfachen Trick:

geh neben dem Wert der Dich interessiert und dann taucht rechts ein Icon auf: Pfad kopieren - dann hast Du den Pfad in der Zwischenablage

Hier noch zur Illustration - auch wenn ich mich oben vertan haben sollte. Also einfach neben dem Wert der von Interesse ist, dann den Pfad kopieren:

siehe rechts neben dem Screenshot. Dann in eine Change Node den Pfad setzen:

und schon hast Du den Wert extrahiert.