Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[mickym]

@schmetterfliege

[Schmetterfliege]

@mickym
Bzw eine Frage noch:

Ich habe insg. 20 Zigbee Devices mit diesem DP.
Im output sind die auch alle in einem Array gelistet.
Allerdings habe ich den Output der Debug Node "Alles OK" 15 mal.

Wenn ich in der Join Node 20 statt 18 eintrage, habe ich den Output 11 mal.
Füge ich eine Debug Node direkt an die Join node hinzu, bekomme ich von der 32 Outputs.

Wie hängen diese Zahlen zusammen wenn ich 20 Devices habe?

[mickym]

@schmetterfliege - Also den Alles OK Ast im Switch Node kannst ja rausschmeissen später, weil Du ja nur den Alarmzustand überprüfen willst.

Diese Zahl in der JOIN Node sammelt EINMALIG alle Nachrichtenteile bis sie erstmalig eine Nachricht rausschickt - dann wird jede Nachricht rausgeschickt:

Wenn der Haken gesetzt ist.
Wenn Du also 20 Devices hast - musst halt auf 20 stellen.

Wenn Du die JOIN Node zurücksetzten willst, sendest Du mit einer Inject Node einen Reset.

[Schmetterfliege]

@mickym

Okay, mit Haken raus bekomme ich den Output nur 1 mal.
Sollte der Haken drin bleiben, oder kann ich den (für meinen inneren Monk?) draußen lassen?
Ich schätze mal ohne den Haken bekomme ich den Output nur einmalig und danach erst wieder wenn node red startet, richtig?

Zum Zurücksetzen der Join Node:
Was genau bewirkt das? Bzw. wieso "sollte" ich die Node zurücksetzen?

[mickym]

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

@mickym
Bzw eine Frage noch:

Ich habe insg. 20 Zigbee Devices mit diesem DP.
Im output sind die auch alle in einem Array gelistet.
Allerdings habe ich den Output der Debug Node "Alles OK" 15 mal.

Wenn ich in der Join Node 20 statt 18 eintrage, habe ich den Output 11 mal.
Füge ich eine Debug Node direkt an die Join node hinzu, bekomme ich von der 32 Outputs.

Wie hängen diese Zahlen zusammen wenn ich 20 Devices habe?

Wenn Du statt der Switch Node eine Change Node nimmst bekommst nur true oder false raus .

Spoiler

[
   {
       "id": "623f7e39.62612",
       "type": "change",
       "z": "54b226bc.0793e8",
       "name": "AND ?",
       "rules": [
           {
               "t": "set",
               "p": "payload",
               "pt": "msg",
               "to": "$reduce(payload.*,function($i, $j){$i and $j})",
               "tot": "jsonata"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 770,
       "y": 1000,
       "wires": [
           []
       ],
       "info": "# All Property of an object must be true.\n\nAll properties of an object must be true.\n\n`{\n    \"Office\": true,\n    \"Bedroom\": true,\n    \"Living Room Balcony\": true,\n    \"Living Room Right Window\": true,\n    \"Living Room Left Window\": true\n}`\n\nis true,\n\n`{\n    \"Office\": true,\n    \"Bedroom\": false,\n    \"Living Room Balcony\": true,\n    \"Living Room Right Window\": true,\n    \"Living Room Left Window\": true\n}`\n\nis false.\n\n# Alle Eigenschaften eines Objektes müssen wahr sein\n\nAlle Eigenschaften eines Objektes müssen wahr sein.\n\n`{\n    \"Büro Balkon\": true,\n    \"Schlafzimmer Balkon\": true,\n    \"Wohnzimmer Balkon\": true,\n    \"Wohnzimmer rechtes Fenster\": true,\n    \"Wohnzimmer linkes Fenster\": true\n}`\n\nergibt true,\n\n`{\n    \"Büro Balkon\": true,\n    \"Schlafzimmer Balkon\": true,\n    \"Wohnzimmer Balkon\": true,\n    \"Wohnzimmer rechtes Fenster\": false,\n    \"Wohnzimmer linkes Fenster\": true\n}`\n\nergibt false."
   }
]

Mit der switch node hast halt die Möglichkeit das Objekt zu analysieren - welcher SEnsor betroffen ist.

[mickym]

@schmetterfliege Den Haken lässt Du bitte drin. Denn wenn die JOIN Node einmal mit allen 20 topics gefüttert ist möchtest Du ja jedes Update der Datenpunkte sehen. Das Zurücksetzen ist nur dazu gedacht - damit Du testen kannst - dass genau eine Nachricht kommt, wenn Du einmal mit der list Node triggerst. Dafür muss die JOIN Node ja leer sein. Durch das Deploy wird sie nicht geleert - sondern nur wenn NR neu gestartet wird. Insofern setzt Du die JOIN Node damit so zurück, wie sie ist wenn NR neu gestartet wurde.

[mickym]

@schmetterfliege ICh mach Dir mal den Flow fertig - so dass Du nur noch den Alarm bekommst und wie Du das Gerät dann ermittelst.

das ganze steht und fällt halt mit dem availablity Datenpunkt - der ist aber bei batteriebetriebenen Devices nicht sehr zuverlässig. Ich überwache die Devices deshalb einfach immer - indem ich weiß, dass eine Nachricht in der Regel innerhalb einer bestimmten Zeit kommen muss. Bei Türen ist das ggf. schwierig.

Spoiler

[
   {
       "id": "9367f9f7.8f5708",
       "type": "switch",
       "z": "54b226bc.0793e8",
       "name": "AND?",
       "property": "$reduce(payload.*,function($i, $j){$i and $j})",
       "propertyType": "jsonata",
       "rules": [
           {
               "t": "false"
           }
       ],
       "checkall": "true",
       "repair": false,
       "outputs": 1,
       "x": 1050,
       "y": 800,
       "wires": [
           [
               "c2bd838b.5c92b"
           ]
       ],
       "info": "# All properties of an object must be true.\n\nAll properties of an object must be true.\n\n`{\n    \"Office\": true,\n    \"Bedroom\": true,\n    \"Living Room Balcony\": true,\n    \"Living Room Right Window\": true,\n    \"Living Room Left Window\": true\n}`\n\nis true,\n\n`{\n    \"Office\": true,\n    \"Bedroom\": false,\n    \"Living Room Balcony\": true,\n    \"Living Room Right Window\": true,\n    \"Living Room Left Window\": true\n}`\n\nis false.\n\n# Alle Eigenschaften eines Objektes müssen wahr sein\n\nAlle Eigenschaften eines Objektes müssen wahr sein.\n\n`{\n    \"Büro Balkon\": true,\n    \"Schlafzimmer Balkon\": true,\n    \"Wohnzimmer Balkon\": true,\n    \"Wohnzimmer rechtes Fenster\": true,\n    \"Wohnzimmer linkes Fenster\": true\n}`\n\nergibt true,\n\n`{\n    \"Büro Balkon\": true,\n    \"Schlafzimmer Balkon\": true,\n    \"Wohnzimmer Balkon\": true,\n    \"Wohnzimmer rechtes Fenster\": false,\n    \"Wohnzimmer linkes Fenster\": true\n}`\n\nergibt false."
   },
   {
       "id": "c2bd838b.5c92b",
       "type": "split",
       "z": "54b226bc.0793e8",
       "name": "",
       "splt": "\\n",
       "spltType": "str",
       "arraySplt": 1,
       "arraySpltType": "len",
       "stream": false,
       "addname": "",
       "x": 1210,
       "y": 800,
       "wires": [
           [
               "d67d1030.000cf"
           ]
       ]
   },
   {
       "id": "d67d1030.000cf",
       "type": "switch",
       "z": "54b226bc.0793e8",
       "name": "",
       "property": "payload",
       "propertyType": "msg",
       "rules": [
           {
               "t": "false"
           }
       ],
       "checkall": "true",
       "repair": false,
       "outputs": 1,
       "x": 1360,
       "y": 800,
       "wires": [
           [
               "b1689835.049888"
           ]
       ]
   },
   {
       "id": "b1689835.049888",
       "type": "template",
       "z": "54b226bc.0793e8",
       "name": "",
       "field": "payload",
       "fieldType": "msg",
       "format": "handlebars",
       "syntax": "mustache",
       "template": "Sensor {{topic}} ist nicht verfügbar!",
       "output": "str",
       "x": 1500,
       "y": 800,
       "wires": [
           [
               "ad8355c1.f51bc8"
           ]
       ]
   },
   {
       "id": "ad8355c1.f51bc8",
       "type": "debug",
       "z": "54b226bc.0793e8",
       "name": "alarm",
       "active": true,
       "tosidebar": true,
       "console": false,
       "tostatus": false,
       "complete": "payload",
       "targetType": "msg",
       "statusVal": "",
       "statusType": "auto",
       "x": 1650,
       "y": 800,
       "wires": []
   }
]

[Schmetterfliege]

@mickym
Danke dir vielmals!!

Der availability Datenpunkt hatte bei mir bisher eigentlich recht zuverlässig funktioniert.
Alle sind - soweit ich das beurteilen kann - immer available, außer einer verliert mal wirklich die Verbindung oder die Batterie ist leer.
Die Batterie zu überwachen ist eher sinnlos. Die Voltage wird nicht immer aktuell gehalten, und die Battery% ist bei 56% wenn eine leer ist.
Daher die Idee mit Availability.

Wie machst du das denn mit den Nachrichten innerhalb einer bestimmten Zeit? Hast du da einen Timer eingebaut?
Ggfs. kann ich ja einfach einbauen dass wenn einer einen Alarm werfen würde, ich einen Delay von 10 Minuten einbaue, und dann nochmal diesen Sensor prüfe und wenn er immer noch nicht verfügbar ist -> dann Alarm.

Hab mal zum Test bei einem die Batterie raus. Mal schauen wann die Debug Node mir das mitteilt.
Ich kann ja in IoBroker prüfen ab wann der nicht mehr verfügbar ist.

[mickym]

@schmetterfliege Nein trigger Node verwenden. Kein Delay oder so was - die trigger Node ist die tollste Node in dem ganzen System

Wenn Du die so einstellst - gibst Du eine Zeit an in der eine Nachricht zu einem Topic normalerweise immer kommt.
Die trigger Node wird getriggert. Wenn eine weitere Nachricht innerhalb der zu erwartenden Zeit kommt passiert nichts, wenn die Nachricht ausbleibt gibt die trigger Node einen Alarm.

[Schmetterfliege]

@mickym

Die Trigger Node habe ich bisher immer gekonnt übersehen.
Die scheint ja wirklich klasse zu sein!

Im Prinzip füttere ich die also mit einer IoBroker In node, und wenn dann nach zb. 2 Stunden keine Nachricht mehr kommt, übergebe ich über die Trigger Node das Topic, weiß welcher Sensor es ist und haue einen Alarm raus mit dem entsprechenden Sensor? Hammer!

[mickym]

@schmetterfliege Genau - die steht dann in dem Topic.

Ausserdem verwende ich die trigger Node zum Entprellen - wenn die rbe Node nicht passt - oder um zu warten bis ein Schieberegler zum Stillstand kommt, um einen Timer zu simulieren, um einen Taster zu simulieren, sogar um im NR Dashboard was blinken zu lassen, wenn man kein CSS beherrscht usw. - also diese Node ist so vielseitig und das in ihrer Einfachheit.

Die Delay Node - ist im Vergleich zur trigger Node überflüssig - das einzige was die Delay Node der Trigger Node voraus hat, ist die Begrenzung der Nachrichtenrate - also nicht die Verzögerung, sondern die Rate.

[mickym]

@schmetterfliege Ach übrigens ich hoffe Du hast Deinen NodeRed Adapter die Konvertierung in Strings abgewöhnt - sonst funktionieren die Flows nicht ohne dass Du alles in Boolsche Variablen umwandelst.
Ich weiß nicht wieviele Flows Du schon hast, aber sonst kann ich Dir nur empfehlen das schleunigst auszuschalten, sonst musst Du alle Datenpunkte wieder in andere Datentypen konvertieren.

[Schmetterfliege]

@mickym

wie gewöhne ich dem das denn ab? Und gehen dann alle Flows sofort kaputt? :S
Hatte in der Tat teilweise schon das Problem dass manche bool werte als String wiedergegeben wurden, aber das dann zu verwurschteln war bisher eigentlich keine Schwierigkeit

[mickym]

@schmetterfliege Nein nicht kaputt - aber Du musst halt jeden Flow überprüfen, also alle iobroker IN Nodes. Wie gesagt - wenn Du die Konvertierung schon drin. Du musst also mal entscheiden ob Du das jedesmal wieder konvertieren willst.

Damit der Flow funktioniert wenn Du mit Strings arbeitest, dann musst halt mit einer Change Node alle Nachrichten umwandeln. Das sparst Dir halt wenn man mit den originalen Datentypen arbeitet. Du hast halt dann jetzt selbst immer umgewandelt.

Ich rate halt jedem - diese unsinnig - aber leider standardmässig angehakte Option auszuschalten:

Wie gesagt sonst musst halt übersetzen

Mit der Option kommen halt auch Zahlen im NR als Strings an usw. und musst auch wieder umwandeln um rechnen zu können usw.

[Schmetterfliege]

@mickym

Hab das mal ausgeschalten.
Dann wird das jetzt ein langer Abend, alles zu überprüfen hahahha

Allerdings meine ich zu wissen dass ich bisher nur in einem Flow den Datentyp in "Number" in der Function Node konvertieren musste.
Und bei bool Werten... keine Ahnung mehr. Hab das immer in Function nodes gemacht, also die alle abklappern.

Die Option hat aber nicht die Datenpunkte in iobroker in Strings umgewandelt, oder?
Also muss ich jetzt nur meine Konvertierungen in den NR Flows ändern?

[mickym]

@schmetterfliege Nein die Option hat nur die Datenpunkte in Strings beim Einlesen in NR gewandelt - hat aber die originalen Datenpunkte im iobroker nicht angefasst.

[Schmetterfliege]

@mickym

okay, danke! :)

[Schmetterfliege]

@mickym

Irgendwie scheint die Option alles in Strings zu verwandeln keine Wirkung gehabt zu haben.
Hier mal ein Beispiel, bei dem ich aus einer iobroker get node den Wert vom DP "occupancy" auslese.
In iobroker ist das definitiv ein Bool.
Mein Flow sieht so aus:

Ich lese alles aus, splitte es und je nach Datenpunkt dann in eine andere Funktion.
Die Funktionen sehen alle so aus:

Bei der Occupancy prüft der Switch dann Bool werte:

Und der Output wird dann an ein Template übergeben, das so aussieht:

Das funktioniert auch definitiv.
Wäre in dem Flow mein Bool Wert in einen String verwandelt worden, wäre das dann nicht an dem Switch der auf Bool prüft gescheitert? Oder ist es dem Switch egal ob das ein String oder Bool ist?

[mickym]

@schmetterfliege Das Problem ist leider bei dem Boolwerten immer, dass die implizit gewandelt werden. Sprich alle Strings werden als wahr interpretiert - lediglich 0 ist dann false. Wie gesagt überprüfe halt mit einer Debug Node was rauskommt.

Die sagt Dir auf jeden Fall immer welcher Datentyp rauskommt, so dass man sich darauf im weiteren verlassen kann:

[mickym]

@schmetterfliege Und wenn ich Deinen Flow so anschaue - also das Pollen ist unsinnig und belastet nur Dein System. Benutze iobroker -In Nodes die Triggern wenn sich was ändert - Du musst doch nicht alle 10 min fragen - und ausserdem bekommst ja dann gar nichts mit, innerhalb der 10 Minuten? Warum machst Du so was? Du nimmst ja die Vorteile, dass iobroker Dich aktiv über Zustandsänderungen informiert gar nicht wahr. Gerade bei Bewegungsmeldern ist ja der letzte Status überhaupt nicht wichtig.