Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[mickym]

@schmetterfliege Kannst ja testen - Du kannst ja 2 Inject Nodew davor plazieren mit einem msg.topic und einer bekannten und unbekannten ID. Es sollte nur die mit der bekannten ID durchgelassen werden. Mach am Besten einfach eine Kopie der Switch Node damit kannst testen.

[Schmetterfliege]

@mickym

Dass es funktioniert glaube ich ja, ich möchte nur verstehen nach was genau wir da Filtern^^
Also was dieses "topic" ist.

[mickym]

@schmetterfliege

Also die Flow variable ist ein Objekt. Dieses Objekt besteht aus Eigenschaften die wiederum ein Objekte sind.

Das Objekt der Flow variable heißt zigbee.

Das Objekt der nun Eigenschaften die ich so benennen wie das msg.topic. Das ist das A und O - die id - spielt nur für die Tabelle eine Rolle für uns nicht.

Im Prinzip interessiert uns wie das Objekt aussieht überhaupt nicht - wir benennen die Eigenschaften des Objektes immer nach dem msg.topic - und somit bleibt auch die Zuordnung immer korrekt:

Auch beim Setzen der Namen interessiert mich der Inhalt - der Wert der Eigenschaft überhaupt nicht, sondern es wird nur die Zuordnung über das msg.topic gesetzt

Die Eigenschaften im zigbee Objekt stammen also alle aus der msg.topic und nur die ist interessant für die Zuordung und Identifikation:

Nun liest Du mit der JSONATA das Objekt aus - wichtig ist hier die lookup Funktion:

Sprich da ich ja vorher die Eigenschaften alle mit msg.topic festgelegt habe, kann ich natürlich auch mit lookup suchen, ob das Wert existiert.

Die Switch Node prüft also ob es im Objekt zigbee eine Eigenschaft "00158d0003f13adf" gibt - falls ja wird das Objekt zurückgeliefert - also am Anfang nur : { "name" : " Gerät Büro"}. Das interessiert uns aber nicht. Deswegen rufe ich mit Exists nur auf - ob lookup ein Objekt zurückliefert oder nicht. Falls true - lässt er die Originalnachricht durch. Ansonsten wird undefined anstelle eines Objektes zurückgegeben und exists liefert false und die Nachricht wird blockiert.

Fertig - viel genauer kann ich es eingentlich nicht mehr erklären.

[Schmetterfliege]

@mickym
Lass dich nicht unterbrechen - ich werfe nur die Zwischenfrage ein weil die Bilder nur im Zwischenspeicher sind^^

Wenn ich die Variable nun nicht über Topic, sondern "bla" setze - weil das was ich will nicht über msg.topic rein kommt sondern über msg.bla:

Würde die switch Node dann so aussehen:

Oder würde ich in der Switch Node trotzdem topic benutzen?

Oder kann ich in der Funktion die Variable gar nicht erst basteln wenn ich statt "msg.topic" einfach "msg.bla" nehme?

[mickym]

@schmetterfliege richtig - in den function Nodes musst Du immer msg. angeben - in JSONATA braucht es nur die Eigenschaft im msg.Objekt.

Du müsstest halt in Deinem Beispiel beides Mal in msg.bla den Wert haben. Im Prinzip ist das ja egal. Im Prinzip ist der Vergleich im JSONATA

$exists($lookup($flowContext('zigbee'), '00158d0003f13adf'))

durch was der Wert nachdem geschaut hat verglichen wird ist also wurscht.

Ich kann das also mit msg.bla setzen und mit msg.topic, msg.xxx oder was auch immer abfragen - das sind doch alles nur Variablen, die zur Laufzeit gesetzt werden. Die Switch Node interessiert doch nicht durch was der Eigenschaftsname gesetzt wurde - ich gebe nur an mit was verglichen werden soll. Es bietet sich halt nur an die gleiche msg.Eigenschaft zu nehmen da ich diese ja sowohl zum Schreiben und Lesen genutzt habe. Wie gesagt es wird zur Laufzeit ja mit den Inhalten verglichen und das sind ja alles einzelne Nachrichten.

[Schmetterfliege]

@mickym

Okay, ich glaube ich habe gerade den großes Durchbruch^^

In der Switch Node bezieht sich das "topic" NICHT auf das was im Flow steht, sondern das, was von der vorherigen Switch Node übergeben wird!
Also wenn die "change: 2 Regeln" Node statt msg.topic ein msg.blubb weitergeben würde, würde ich im JSONATA auch nach "blubb" statt "topic" suchen.

Ich bin die ganze Zeit davon ausgegangen dass sich "topic" auf das was im Flow steht bezieht, und nicht auf das was die Switchnode als Input bekommt - ich schäme mich grade ernsthaft

[mickym]

@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:

@mickym

Okay, ich glaube ich habe gerade den großes Durchbruch^^

In der Switch Node bezieht sich das "topic" NICHT auf das was im Flow steht, sondern das, was von der vorherigen Switch Node übergeben wird!

Der Kandidat hat 100 Punkte.

Also wenn die "change: 2 Regeln" Node statt msg.topic ein msg.blubb weitergeben würde, würde ich im JSONATA auch nach "blubb" statt "topic" suchen.

Genau kannst ja einfach testen - in dem Du in der Change Node nochmal msg.blubb auf msg.topic setzt und dann in der switch node blubb schreibst!!!!

Ich bin die ganze Zeit davon ausgegangen dass sich "topic" auf das was im Flow steht bezieht, und nicht auf das was die Switchnode als Input bekommt - ich schäme mich grade ernsthaft

Node Red ist so schön logisch - stell Dir vor Du bist eine Nachricht und wanderst von Node zu Node - bis zur Function Node bzw. Switch NOde - ist alles was im Flow Kontext steht völlig unbekannt. ;) Erst in der Switch Node - im JSONATA referenziere ich ja mit dem flowContext("zigbee") auf den entsprechenden Flow Kontext. Das was Du duchgestrichen hast ist nicht das topic - aber das was das lookup macht. Also insofern wird schon nachgeschaut ob das topic aus der vorangegangenen Change Node mit einer Eigenschaft des Zigbee Objektes übereinstimmt (sprich macht $lookup)

[Schmetterfliege]

@mickym

Jap, da war wieder genau das Problem was ich schon die ganze Zeit habe:
Das Grundprinzip verstehe und kenne ich, sobald aber was neues kommt verkompliziere ich es für mich und denke überhaupt gar nicht mehr über die Basics nach - die mir sofort hätten sagen müssen dass sich das topic auf den Input der anderen Change Node bezieht.

War eine lange Woche^^

[mickym]

@schmetterfliege Na Hauptsache es funktioniert nun so, wie Du willst - Es ist ja wichtig, dass Du lernst selbst Lösungen zu entwickeln. ;) Im Prinzip war Dein Ansatz ja nicht verkehrt alle bekannten IDs zu durchsuchen, wobei da gibts auch einen einfacheren Trick mit RegEx. Sobald man sich bisschen mit den Werkzeugen vertraut macht - stellt man halt fest, dass es viel einfacher Lösungen gibt.

[mickym]

@mickym Wenn Du zum Beispiel nur bestimmte Textwerte (also nicht nur EINEN durchlassen willst) - kannst Du eine Switch Node mit RegEx wie folgt nutzen:

Damit wird ein payload nur durchgelassen wenn sie Schnee oder Regen ist.

In Deinem Fall hättest Du nun auch alles zigbee IDs so erfassen können.

Ich habe sowas auch immer in einem eigenen Testflow - weil ich es auch oft vergesse, wie was möglich ist:

Eine weitere Möglichkeit ist ein Array mit gültigen Werten und eine Überprüfung in einer Change Node:

Spoiler

[
   {
       "id": "fd359057.be015",
       "type": "change",
       "z": "6e170384.60c96c",
       "name": "",
       "rules": [
           {
               "t": "set",
               "p": "valid",
               "pt": "msg",
               "to": "[\"00158d00032c8aa8\",\"00158d0003f4bf3e\",\"00158d0004221522\"]",
               "tot": "json"
           },
           {
               "t": "set",
               "p": "payload",
               "pt": "msg",
               "to": "$exists($filter(valid, function($v){$v = payload}))\t\t",
               "tot": "jsonata"
           },
           {
               "t": "delete",
               "p": "valid",
               "pt": "msg"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 890,
       "y": 4420,
       "wires": [
           [
               "b77b076c.2aac58"
           ]
       ]
   },
   {
       "id": "df1ee592.280998",
       "type": "inject",
       "z": "6e170384.60c96c",
       "name": "",
       "props": [
           {
               "p": "payload"
           }
       ],
       "repeat": "",
       "crontab": "",
       "once": false,
       "onceDelay": 0.1,
       "topic": "",
       "payload": "00158d00032c8aa8",
       "payloadType": "str",
       "x": 650,
       "y": 4400,
       "wires": [
           [
               "fd359057.be015"
           ]
       ]
   },
   {
       "id": "b77b076c.2aac58",
       "type": "debug",
       "z": "6e170384.60c96c",
       "name": "",
       "active": true,
       "tosidebar": true,
       "console": false,
       "tostatus": false,
       "complete": "false",
       "statusVal": "",
       "statusType": "auto",
       "x": 1110,
       "y": 4420,
       "wires": []
   },
   {
       "id": "9c97fee3.cc44e",
       "type": "inject",
       "z": "6e170384.60c96c",
       "name": "",
       "props": [
           {
               "p": "payload"
           }
       ],
       "repeat": "",
       "crontab": "",
       "once": false,
       "onceDelay": 0.1,
       "topic": "",
       "payload": "00158d00032c8aa9",
       "payloadType": "str",
       "x": 650,
       "y": 4440,
       "wires": [
           [
               "fd359057.be015"
           ]
       ]
   }
]

Oben definiert man also ein Array mit gültigen Werten, die man unten wieder löscht. In der Mitte wird überprüft, ob die payload in den gültigen Werten enthalten ist. Du siehst die Möglichkeiten sind mannigfaltig.

[Schmetterfliege]

@mickym

JSON/JSONATA/RegEx sind definitv ein Thema, bei dem ich mich wirklich mal hinsetzen muss und mir das dann ins Gedächtnis einspeichern muss. Denn dass sind echt mächtige Werkzeuge, die (nicht nur hier) wirklich unzählige Möglichkeiten bieten!

[Schmetterfliege]

Ich habe übrigens meine Tabelle mal um die Timestamps für die Temp und Hum erweitert (inkl. Formatieren):

Einer der nächsten Steps wäre dann demnächst diese Timestamps zur "Fehleranalyse" zu nutzen.
Beispiel: wenn ein Sensor für längere Zeit keine Aktualisierung liefert, soll das Feld dann zb. rot markiert sein.
Dazu werde ich mich dann auch mit dem Godfather der ui-table beschäftigen müssen :D.

Ohne dass du mir jetzt eine Lösung nennen sollst oder ich dich wieder dazu bewege für mich Flows zu erstellen:
Ist das überhaupt möglich ohne das System zu belasten?
In meinem Kopf sieht das dann nämlich so aus, dass für 18 Werte permanent der Timestamp mit der aktuellen Uhrzeit abgeglichen wird, und wenn eine bestimmte Differenz ermittelt wird, verändere ich die Tabelle und mache ein Feld rot.
Abgesehen davon dass das nach sau viel Arbeit und Einlesen klingt, kann ich mir gut vorstellen dass das voll aufs System geht, oder?
Allgemein kann ich mir adhoc keine Möglichkeit erdenken die prüft ob seit zb. 10 Minuten eine Variable nicht aktualisiert wurde - zumindest nicht ohne dass ich 18x durchgehend eine Überprüfung mache und damit womöglich NR kille^^

EDIT: theoretisch kann ich diese Überprüfung ja aber auch nur alle 10 Minuten triggern. Im schlimmsten Fall wäre das Feld dann erst rot wenn der Wert schon 19 Minuten alt ist, aber das wäre ja zumindest mal ein Anfang!

EDIT2: für die Formatierung der Timestamps habe ich eine Node aus dem Netz geklaut (contrib-moments)

[mickym]

@schmetterfliege ich habe dir ja schon mal gesagt, dass ich von der Überprüfung der Zeitstempel nichts halte und dass ich das easy über eine Trigger Node machen würde, aber das scheint wohl nicht so angekommen zu sein.

Ich finde solche Zeitstempel in einer Tabelle eher störend und würde Überwachung eher trennen. Außerdem hast du mir doch erzählt, dass der availabilty Datenpunkt zuverlässig ist. Wie gesagt was ich von solchen Pollerei Ansätzen halte, hab ich glaub schon mehrfach gesagt, aber es ist Dein System. Man kann auch jede Minute zum Fenster rausschauen, um zu überprüfen, ob es noch Tag oder Nacht ist oder man verlässt sich halt darauf, dass die Astrozeiten einen triggers, dass es jetzt hell wird.

[Schmetterfliege]

@mickym

Naja, ich kontrolliere leider lieber viel zu viel, als mich nur auf etwas "passives" zu verlassen - zumindest zu Anfang :D.
Aber ja, das mit der Trigger Node zu machen, macht wahrscheinlich deeeeutlich mehr Sinn.
Ich müsste da dann vermutlich 18 Trigger Nodes nutzen, oder kann man mit einem Trick über einen Trigger alle 18 prüfen (denke nicht, da der Trigger ja dann 18 Verzögerungen bräuchte)?

[mickym]

@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:

@mickym

Naja, ich kontrolliere leider lieber viel zu viel, als mich nur auf etwas "passives" zu verlassen - zumindest zu Anfang :D.
Aber ja, das mit der Trigger Node zu machen, macht wahrscheinlich deeeeutlich mehr Sinn.
Ich müsste da dann vermutlich 18 Trigger Nodes nutzen, oder kann man mit einem Trick über einen Trigger alle 18 prüfen (denke nicht, da der Trigger ja dann 18 Verzögerungen bräuchte)?

Du solltest Dich lieber mal mit der Genialität dieser Node befassen:

Alleine mal was diese Option bedeutet

sollte Dich zum Überlegen bringen, was das bedeutet.

Alleine Deine Aussage:

In meinem Kopf sieht das dann nämlich so aus, dass für 18 Werte permanent der Timestamp mit der aktuellen Uhrzeit abgeglichen wird, und wenn eine bestimmte Differenz ermittelt wird, verändere ich die Tabelle und mache ein Feld rot.

müssten eigentlich für Dich zu Recht ein Hinweis darauf sein, dass das Unsinn ist. Am Besten machst Du dann solche ein Prüfung noch sekündlich, für eine Ereignis, was vielleicht alle 1-2 Jahre mal auftritt :face_with_rolling_eyes:

[Schmetterfliege]

@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:

@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:

@mickym

Naja, ich kontrolliere leider lieber viel zu viel, als mich nur auf etwas "passives" zu verlassen - zumindest zu Anfang :D.
Aber ja, das mit der Trigger Node zu machen, macht wahrscheinlich deeeeutlich mehr Sinn.
Ich müsste da dann vermutlich 18 Trigger Nodes nutzen, oder kann man mit einem Trick über einen Trigger alle 18 prüfen (denke nicht, da der Trigger ja dann 18 Verzögerungen bräuchte)?

Du solltest Dich lieber mal mit der Genialität dieser Node befassen:

Alleine mal was diese Option bedeutet

sollte Dich zum Überlegen bringen, was das bedeutet.

Da hab ich mir die Node tatsächlich nicht ordentlich angeschaut - da ist ja der "Trick" :)

Alleine Deine Aussage:

In meinem Kopf sieht das dann nämlich so aus, dass für 18 Werte permanent der Timestamp mit der aktuellen Uhrzeit abgeglichen wird, und wenn eine bestimmte Differenz ermittelt wird, verändere ich die Tabelle und mache ein Feld rot.

müssten eigentlich für Dich zu Recht ein Hinweis darauf sein, dass das Unsinn ist. Am Besten machst Du dann solche ein Prüfung noch sekündlich, für eine Ereignis, was vielleicht alle 1-2 Jahre mal auftritt :face_with_rolling_eyes:

Dass das eine schlechte Idee ist, darauf kam ich ja auch selbst. Sind ja alles erst mal nur Gedanken.
Alles was ich in NR mache direkt zu perfektionieren ist natürlich sinnvoll, aber nicht mein Primärziel.
Im April bin ich aus der Wohnung hier raus, bis dahin sehe ich NR und allgemein mein aktuelles SmartHome als kleine Spielwiese um zu experimentieren und zu sehen, was alles geht. Je nachdem was nach April mein neues Zuhause wird, muss ich sowieso ggfs. die Hälfte rausschmeißen weil Räume wegfallen, sich ändern usw.
Und dass die Sensoren nur alle 1-2 Jahre mal keinen Wert liefern wäre schön - ist aber falsch^^
Die Wohnung ist ziemlich weitläufig, mein Raspi mit dem Conbee Stick etwa in der Mitte der Wohnung. Es kommt schon ab und zu vor, dass mal ein Sensor keine Werte mehr liefert. Ende Dezember kommen meine Zigbee Plugs, die dann hoffentlich mein Zigbee Netzwerk deutlich boosten (weil Repeater).
Abgesehen davon wird bei 9 Sensoren irgendwann demnächst die Batterie aussteigen :)

Nur mal als Beispiel: Mein PC steht im Büro direkt an der Wand zum Gästezimmer.
Wenn ich mit dem Bluetooth Headset ins Gästezimmer gehe, und mich am anderen Ende des Gästezimmers runterbeuge, verliert das Headset die Verbindung. Das sind keine 2 Meter Luftlinie und nur eine Wand (und nein, es liegt nicht am Headset oder BT Dongle, sondern an den Wänden)^^

[mickym]

@schmetterfliege Na ja - ich habe Dir ja nun oft genug gesagt, was ich von Zeitstempeln und deren Überprüfung halte - aber ich denke DU beschäftigst Du nun schon lange genug mit dem System, dass Du ja solche Dinge nun selbst überprüfen kannst. Vielleicht hilft Dir ja mein neuester Thread: https://forum.iobroker.net/topic/50086/datum-und-zeitverarbeitung-mit-nodered
wenn Du Dich so gerne mit Zeitstempeln beschäftigen willst. ;)

[Schmetterfliege]

@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:

@schmetterfliege Na ja - ich habe Dir ja nun oft genug gesagt, was ich von Zeitstempeln und deren Überprüfung halte - aber ich denke DU beschäftigst Du nun schon lange genug mit dem System, dass Du ja solche Dinge nun selbst überprüfen kannst. Vielleicht hilft Dir ja mein neuester Thread: https://forum.iobroker.net/topic/50086/datum-und-zeitverarbeitung-mit-nodered
wenn Du Dich so gerne mit Zeitstempeln beschäftigen willst. ;)

Genau über den Thread kam ich ja darauf zu schauen was ich mit den Timestamps bei mir so anstellen kann :D.
U.a. eben sie mir in der Tabelle anzuzeigen, damit ich schonmal etwas habe mit dem ich nachvollziehen kann, von wann die Werte in der Tabelle sind.
Sinn oder Unsinn ist da bei mir wie gesagt erstmal Wurst. Das Einzige was ich nicht möchte, ist NR wieder ständig zu crashen weil ich zb. meine Hue Steuerung in NR in dutzende endless loops verwandelt habe die erst NR crashen und beim Neustart instant sämtliche Lichter in allen Räumen einschalten - Nachts um halb 4...
Sachen wieder rauszunehmen wenn ich damit gespielt habe ist ja nicht die Schwierigkeit :P

[Schmetterfliege]

Hi @mickym
sorry dass ich nochmal störe :(

Ich überarbeite nach und nach meine Tabelle und möchte nun den tatsächlichen Raumnamen mit anzeigen.
Das Problem ist folgendes:

Der Raumname wird bei jedem Device unter "enums" gespeichert, allerdings nicht direkt als Wert sondern nochmal als Datenpunkt in dem auch der Raumname drin steht.
Kennst du eine Möglichkeit wie ich direkt an den Wert (in dem Fall "Flur 1") rankomme, ohne explizit zb. "enum.rooms.flur_1" angeben zu müssen? (sonst brauche ich ja 18 Funktionen die jeweils den entsprechenden Datenpunkt auslesen, da der ja bei jedem einzelnen Device anders aussieht)
Die Flow Objekte sehen wenn ich nur "enums" zuweise logischerweiße so aus:

Ich hoffe es ist einigermaßen verständlich was ich meine^^

[mickym]

@schmetterfliege
Nun es ist kein Datenpunkt, sondern ein Objekt unter enums. Das Problem ist durch eine split Node sehr einfach zu lösen. Das Problem ist eher, dass Du theoretisch ja einem Objekt mehrere Räume zuweisen kannst. Ich habs nun wie im admin5 gelöst und die Räume mal dann in einem kombinierten Strings aufzulisten.
Ein weiteres Problem ist, dass das enums Projekt ja nicht nur Räume als Aufzählungen enthält, sondern auch Funktionen oder selbst definierte Aufzählungen. Ich habe deshalb mal alle enum.rooms mit einer switch Node rausgefiltert:

Damit kannst Du dann im Flow Kontext Deine Tabelle neben den Namen auch noch mit den Räumen initialisieren. Muss man halt noch mal eine Function Node bemühen und ggf. die bereits vorhandene Variable nochmal auslesen:

Also einfach nochmal diese 4 Nodes dazwischen (also zwischen die function Node, die die Namen schreibt und der Trigger Node) klemmen:

Spoiler

[
   {
       "id": "1f8eb11.1a70a4f",
       "type": "change",
       "z": "54b226bc.0793e8",
       "name": "",
       "rules": [
           {
               "t": "set",
               "p": "payload",
               "pt": "msg",
               "to": "payload.enums",
               "tot": "msg"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 1200,
       "y": 1400,
       "wires": [
           [
               "59681b14.d1c474"
           ]
       ]
   },
   {
       "id": "59681b14.d1c474",
       "type": "split",
       "z": "54b226bc.0793e8",
       "name": "",
       "splt": "\\n",
       "spltType": "str",
       "arraySplt": 1,
       "arraySpltType": "len",
       "stream": false,
       "addname": "",
       "x": 1370,
       "y": 1400,
       "wires": [
           [
               "82b2a834.355758"
           ]
       ]
   },
   {
       "id": "82b2a834.355758",
       "type": "switch",
       "z": "54b226bc.0793e8",
       "name": "",
       "property": "parts.key",
       "propertyType": "msg",
       "rules": [
           {
               "t": "cont",
               "v": "enum.rooms",
               "vt": "str"
           }
       ],
       "checkall": "true",
       "repair": false,
       "outputs": 1,
       "x": 1510,
       "y": 1400,
       "wires": [
           [
               "6407946c.27cc1c"
           ]
       ]
   },
   {
       "id": "6407946c.27cc1c",
       "type": "function",
       "z": "54b226bc.0793e8",
       "name": "Räume auslesen",
       "func": "var rooms = flow.get('zigbee.' + msg.topic + '.rooms');\nif (rooms === undefined) rooms = msg.payload; else rooms = rooms + ', '+ msg.payload; \n\nflow.set('zigbee.' + msg.topic + '.rooms',rooms);\n\nreturn msg; \n",
       "outputs": 1,
       "noerr": 0,
       "initialize": "",
       "finalize": "",
       "libs": [],
       "x": 1690,
       "y": 1400,
       "wires": [
           [
               "32ace99d.216626"
           ]
       ]
   }
]

wichtig ist, dass das Topic erhalten bleibt also in der split Node nicht das Topic überschreiben. Ansonsten bekommst Du die Raumnamen nun direkt in der payload und musst wie gesagt nur prüfen, ob ggf. schon ein Raum gesetzt wurde. Die function Node ist deshalb leicht modifiziert, aber nicht kompliziert:

var rooms = flow.get('zigbee.' + msg.topic + '.rooms');
if (rooms === undefined) rooms = msg.payload; else rooms = rooms + ', '+ msg.payload; 
flow.set('zigbee.' + msg.topic + '.rooms',rooms);

return msg;