Verfügbarkeit von Sensoren über Node Red überwachen

[Schmetterfliege]

@mickym

Alter Verwalter, ist das Crazy!
Wenn ich das irgendwann auch nur ansatzweise hinbekomme wie er, mach' ich 3 Kreuze.

Hatte selbst am Anfang VIS genutzt, wollte dann aber mal Node Red probieren weil es irgendwie mächtiger und schöner wirkte (vorallem das Verbinden der Nodes hat mich visuell gecatcht).
Und nu hab ich alles an Skripten und Visualisierung in Node Red umgezogen (außer ein Skript das meine Tado Thermostate ausschalten wenn die Fenster auf gehen, und wieder in den gleichen Zustand versetzt wenn die Fenster zu gehen. Da müsste ich mich vorher mal anständig mit den (Flow)variablen auseinandersetzen^^)

Dein Thread sieht super interessant aus, ich glaube da sitze ich demnächst mal ein paar Stunden dran

[mickym]

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

@mickym

Alter Verwalter, ist das Crazy!
Wenn ich das irgendwann auch nur ansatzweise hinbekomme wie er, mach' ich 3 Kreuze

Na er schrieb ja, dass er da ein paar Monate dran gesessen ist - also das ist dann schon die hohe Kunst.

Aber er nutzt zuviele function Nodes - und da bin ich ja strikter Gegner von, da es den Sinn von Node Red kaputt macht. Du kannst ja Deine ganzen Flows in eine Function Node packen - und gerade im iobroker kannst dann gleich Javascript programmieren.

[mickym]

@schmetterfliege Wie gesagt schau einfach mal in mein Profil - vielleicht findest in den Themen ja was brauchbares. Mein letzter war ja die Datum und Zeitverarbeitung mit der moment Bibliotheken und out of the box Mitteln - also keine Nodes installieren.

Morgen probiere ich mal die FlipFlop Uhr ins Dashboard zu bringen.

[Schmetterfliege]

@mickym

Werde ich definitiv tun!
Die Zeitstempel zu verarbeiten ist sowieso noch auf der Todo Liste, damit ich auch darüber sehen kann von wann die Temperaturen sind und so ggf. auch zu sehen wenn einer nichts mehr meldet etc.

Übrigens: Heureka!

[mickym]

@schmetterfliege Na Glückwunsch - Ich finde es übrigens gut - wenn die Tabelle erst gefüllt ist, wenn alles aktuell gemeldet wurde. Du musst übrigens nicht alle Eigenschaften des Array einbinden. Die ID - könntest Du also nicht anzeigen lassen - brauchst aber intern - und nur übersetzte Namen. Dazu kannst Dir ja einen Datenpunkt mit einem JSON String basteln, der Dir die Gerätekennungen in sprechende Namen übersetzt.

[Schmetterfliege]

@mickym

Wie mache ich das, dass die nur aktualisiert wenn alle Werte da sind?
Ich hab zumindest rausgefunden dass ich die join node von 2 auf 18 Nachrichten setzen musste

Hab aber irgendwie das Gefühl dass wenn ein Humidity Wert der fehlt dazu kommt, ein anderer verschwindet.
Aber das wirkt whsl nur so, weil sich beim aktualisieren die ganze Tabelle kurz ändert^^
EDIT: da verschwinden tatsächlich ab und zu humidity werte!

[mickym]

@schmetterfliege Wie gesagt ich würde es nicht machen - sonst kannst es ja wieder mit list NOde einmalig aktualisieren

[Schmetterfliege]

@mickym

"Ich finde es übrigens gut - wenn die Tabelle erst gefüllt ist, wenn alles aktuell gemeldet wurde"
-> darunter habe ich jetzt verstanden, dass du es so machen würdest^^

[mickym]

@schmetterfliege Wenn vorhandene Werte verschwinden - schau mal ob alle Werte in der Flow variablen drin sind

[Schmetterfliege]

@mickym

Hab das Problem bzw. die Probleme gefunden:

1. ich habe 20 Temperatur Sensoren - 2 haben nur noch keinen Platz in der Wohnung gefunden und sind damit obsolet.
   Muss also von 18 auf 20 ändern.
2. Ich habe 2 Motion Sensoren von Aqara - die Dinger haben scheinbar auch einen Temperatur Sensor oO (finde dazu nix auf Google).
   Allerdings keinen Humidty Wert.

Aktuelle Lösung: Join Node von18 auf 22 ändern, dann haben ich halt 2 Einträge ohne Humidity

[mickym]

@schmetterfliege FlipFlop Uhr funzt auch.

FlipFlopUhr in NR Dashboard.mp4

Funktioniert aber nicht richtig - da das Script anscheinend angehalten wird, wenn die SEite im Hintergrund ist.

[Schmetterfliege]

@mickym

Macht die auch diesen typischen Sound wenn man so eine Zahl flippt? Das wäre cool haha

Nochmal eine ganz kurze Verständnisfrage zu der ui-table:

Die change node setzt ja den Payload auf die flow-variablen.
Wieso wird das Array erst aufgesplittet und dann wieder gesammelt?
So müssen ja quasi immer 22 Variablen da sein, bevor er die Tabelle aufbaut (wenn man Join auf 22 Nachrichten setzt).
Wenn also die Flow Variablen mal weg waren, dauert es je nachdem über eine Stunde bis alle Sensoren mal einen Wert geliefert haben und ich 22 Flow Variablen habe.
Sind Split+Join wirklich nötig? Wenn ja, wieso?

[frankyboy73]

@schmetterfliege Hi, du hast in der Flow Variable kein Array sondern Objekte, die werden dann gesplittet und in der Join zu einem Array zusammengefasst, da die table Node ein Array braucht.
Wann sollen die Flow Variablen denn mal weg sein? Das passiert doch eigentlich nur wenn du Node Red neu startest. Ok, dann müsstest du allerdings auf alle Nachrichten warten. Du könntest die Nachrichtenanzahl für die erste Ausgabe in der Join Node auch runtersetzen und die Tabelle würde sich dann nach und nach füllen, aber ich glaube dann kriegst du das Problem das sich die Reihenfolge in der Tabelle ständig ändert, ist auf jeden Fall bei der Template Node so, die ich zur Tabellenausgabe nutze.
Edit: Probier doch einfach mal etwas rum, kaputt machen kann man da nichts. Eventuell ne Kopie vom Flow machen, dann hast du immer noch den originalen zur Verfügung.
Da kennt @mickym sich aber besser aus.
Wen du nicht auf alle Nachrichten warten willst,per Push über die Iobroker In Node, sondern sofort ne Ausgabe haben willst, müsstest du pollen, per Injekt und Listen Node. Da ist aber wieder das Problem das du die Werte nur zu einem bestimmten Zeitintervall abfragst und sie dann nicht so aktuell sind. Wobei das wohl bei Temperaturen und Luftfeuchtigkeit nicht so schlimm wäre, die ändern sich ja eigentlich nicht so schnell.

[Schmetterfliege]

@frankyboy73

Vielen Dank für deine Rückmeldung!

Ah okay, dachte da wäre ein Array drin, weil ich das Objekt ja aufklappen kann:

Aber wenn das kein Array ist, ist die Sache ja klar!

Das Problem wenn ich die JOIN Node zb auf 2 setze statt 22 ist, dass ich dann immer nur 2 Zeilen in der Tabelle habe. Und immer wenn ein Sensor einen Wert aktualisiert, wird eine der Zeilen durch diesen getauscht.
Um also 22 Zeilen in der Tabelle haben zu können, muss ich in der Join Node 22 eintragen.
Außer ich bin doof und verstehe da etwas nicht haha

Idee:
Könnte ich nicht mit einer INIT Node schon mal alle Flow Variablen anlegen, sodass falls NR neu startet, ich auf jeden Fall direkt 22 Variablen habe, die dann eben nach und nach aktualisiert werden? Oder ist das Quatsch?

[mickym]

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

Macht die auch diesen typischen Sound wenn man so eine Zahl flippt? Das wäre cool haha

Na das Thema ist gegessen - Nutzen und Aufwand stehen in keinem Verhältnis.

Nun zu Deiner Verständnisfrage:

Erst mal vorweg - optimal wäre es die Tabelle einmal aufzubauen und dann nur noch Änderungen zu übermitteln - das ist aber wesentlich komplizierter.

Dass die 2 Variablen erst da sein müssen bis die Tabelle aufgebaut ist, ist richtig hat aber mit der splitterei nichts zu, Du kannst den Wert auch auf 1 statt auf 22 runtersetzen, dann wird die Tabelle nacheinander aufgebaut, wie die Werte reinkommen. Sinnvoll wäre es dann auch noch eine Initialisierung mit einer List Node zu beginnen und dann über die iobroker-IN Nodes nur noch zu aktualisieren. Es wird jedoch immer die ganze Tabelle in die ui_table geschickt und nie die zu aktualisierenden Werte. Wie gesagt sonst müsste man das mit dem command UpdateorAdd machen - da muss ich aber selbst noch dran arbeiten.
Also das Aufbauen bis die 22 Variablen da sind hat wieder mal gar nichts mit dem Array und dem split zu tun - es ist einfach wieder eine Frage - wartet man bis die Werte eintreffen oder will man alles mit einem Schlag initialisierne. Ist also im Prinzip das Gleiche wie bei der Initialisierung Deiner Switch oder Text-Nodes.

Eine andere Alternative wäre es die Flow Variable sensors in einen Datenpunkt zu sichern und dann die Flow Variable einmal zu initialisieren. (@frankyboy73 hat das ja schon soweit auch erklärt) Dann musst Du nicht warten bis die 22 Sensoren sich gemeldet haben, sondern es wird einfach der Zustand von vorher hergestellt und jedes Update über die In-Nodes schreibt die Tabelle sofort.

Nun zu Deinem Frage:

Wieso wird das Array erst aufgesplittet und dann wieder gesammelt?

Die Flow Variable enthält kein Array, sondern ein verschachteltes Objekt.

Ich hoffe Du verstehst den Unterschied zwischen einem Objekt und einem Array.

Das ist das verschachtelte Objekt:

{"sensor1":{"humidity":65,"temperature":19,"id":"sensor1"},"sensor2":{"humidity":80,"temperature":22,"id":"sensor2"}}

Die ui_table verlangt aber unbedingt ein Objekt-Array, das ist was anderes:

[{"humidity":65,"temperature":19,"id":"sensor1"},{"humidity":80,"temperature":22,"id":"sensor2"}]

Wenn ich in unserem Beispiel ein Array aktualisieren muss, dann wär das ziemlich umständlich. Ich muss quasi jedes Array-Element in einer Schleife prüfen, ob die id - dieselbe ist und dann gezielt dieses Objekt mit genau dieser ID an genau dieser Index-Stelle austauschen musst. Also wenn Du den 16. Sensor updaten willst, musst Du das Array erst durchsuchen an welcher Stelle im Array das Objekt des 16. Sensors steht.

Bei einem verschachtelten Objekt spare ich mir das - da ich jeder Sensor eine Eigenschaft des Objektes Sensors ist und somit genau angesprochen werden kann.

in der Funktion Node steht deshalb:

flow.set('sensors.' + msg.topic + '.temperature',msg.payload);

das heisst ich kann die richtige Objekteigenschaft im Objekt senors direkt über das topic ansprechen und muss nicht ein Array durchsuchen. Ansonsten haben die Leute gerade das Problem, dass die Tabelle immer weiter wächst, weil einfach jeder Datensatz an ein Array angehängt wird, selbst wenn es vom gleichen Sensor stammt.

Die split Node kann nun ein Objekt in seine einzelnen Eigenschaften zerlegen.

Das Objekt

{"sensor1":{"humidity":65,"temperature":19,"id":"sensor1"},"sensor2":{"humidity":80,"temperature":22,"id":"sensor2"}}

wird also in 2 Nachrichten aufgesplittet:

{"humidity":65,"temperature":19,"id":"sensor1"}

und

{"humidity":80,"temperature":22,"id":"sensor2"}

und dann zu dem obigen Array wieder zusammengesetzt.

In dem Fall ist es nicht schwer immer von 22 auszugehen, da das Array ja immer das komplette Objekt zerlegt, das ja wiederum 22 Objekteigenschaften - nämlich die topics der Sensoren (mit den Objekten als Wert) hat.

[mickym]

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

Idee:
Könnte ich nicht mit einer INIT Node schon mal alle Flow Variablen anlegen, sodass falls NR neu startet, ich auf jeden Fall direkt 22 Variablen habe, die dann eben nach und nach aktualisiert werden? Oder ist das Quatsch?

Das habe ich ja vorgeschlagen:

Eine andere Alternative wäre es die Flow Variable sensors in einen Datenpunkt zu sichern und dann die Flow Variable einmal zu initialisieren. (@frankyboy73 hat das ja schon soweit auch erklärt) Dann musst Du nicht warten bis die 22 Sensoren sich gemeldet haben, sondern es wird einfach der Zustand von vorher hergestellt und jedes Update über die In-Nodes schreibt die Tabelle sofort.

Also die Flow Variable als JSON Objekt in einem Datenpunkt wegschreiben und dann bei Neustart die Flowvariable initialisieren.

Hier einfach die iobroker Nodes mit dem von Dir gewählten DP zur Speicherung der Flowvariablen eintragen:

Spoiler

[
   {
       "id": "3753aa96.538f06",
       "type": "ioBroker get",
       "z": "54b226bc.0793e8",
       "name": "",
       "topic": "",
       "attrname": "payload",
       "payloadType": "value",
       "x": 1120,
       "y": 1320,
       "wires": [
           [
               "59b672af.9b248c"
           ]
       ]
   },
   {
       "id": "f0f365a4.3aab28",
       "type": "inject",
       "z": "54b226bc.0793e8",
       "name": "Init sensors",
       "props": [
           {
               "p": "payload"
           }
       ],
       "repeat": "",
       "crontab": "",
       "once": true,
       "onceDelay": 0.1,
       "topic": "",
       "payload": "true",
       "payloadType": "bool",
       "x": 930,
       "y": 1320,
       "wires": [
           [
               "3753aa96.538f06"
           ]
       ]
   },
   {
       "id": "c6ba225c.b8298",
       "type": "change",
       "z": "54b226bc.0793e8",
       "name": "",
       "rules": [
           {
               "t": "set",
               "p": "sensors",
               "pt": "flow",
               "to": "payload",
               "tot": "msg"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 1470,
       "y": 1320,
       "wires": [
           []
       ]
   },
   {
       "id": "59b672af.9b248c",
       "type": "json",
       "z": "54b226bc.0793e8",
       "name": "",
       "property": "payload",
       "action": "",
       "pretty": false,
       "x": 1290,
       "y": 1320,
       "wires": [
           [
               "c6ba225c.b8298"
           ]
       ]
   },
   {
       "id": "fe0c10f6.af6d8",
       "type": "json",
       "z": "54b226bc.0793e8",
       "name": "",
       "property": "payload",
       "action": "",
       "pretty": false,
       "x": 1250,
       "y": 1140,
       "wires": [
           [
               "fc2153a3.81aef"
           ]
       ]
   },
   {
       "id": "fc2153a3.81aef",
       "type": "ioBroker out",
       "z": "54b226bc.0793e8",
       "name": "",
       "topic": "",
       "ack": "false",
       "autoCreate": "false",
       "stateName": "",
       "role": "",
       "payloadType": "",
       "readonly": "",
       "stateUnit": "",
       "stateMin": "",
       "stateMax": "",
       "x": 1430,
       "y": 1140,
       "wires": []
   }
]

[Schmetterfliege]

@mickym

Hatte meine Nachricht abgeschickt während deine Nachricht kam und das dann nicht gesehen :S
Danke für die Bestätigung! Dann werde ich das bei Gelegenheit mal ausprobieren.

Das mit dem Objekt habe ich in der Tat nun verstanden

Wenn ich nun zb. nicht die ID in der Tabelle haben möchte, sondern lieber den Namen, kann ich doch in der Funktion die die Flow Variable setzt das hier machen:

flow.set('sensors.' + msg.topic + '.name',"Multisensor Büro");

Und dann in der Tabelle aus der "Id" Spalte eine "Name" Spalte machen.
Die Namen würde ich dann über die Init der Variablen über ein Json Objekt machen, oder?

[mickym]

@schmetterfliege Nein das musst Du additiv machen. Also zusätzlich - Du musst aber id nicht in der Tabelle anzeigen, so dass diese dort nur die Namen auftauchen.

id muss vorhanden sein, damit die ui_table Array Objekte den zugehörigen Zeilen zuordnen kann.

Hier mal was aus der Original Doku zum Lesen: http://tabulator.info/docs/5.0/data

PS: Du kannst froh sein, dass ich mich mit der ui_table schon mal beschäftigt habe. Werde irgendwann dann auch mal einen Erklärungsthread aufmachen - das wird aber ein längeres Projekt. Vor 2 Wochen hätte ich Dir das alles noch nicht erklären können.

[frankyboy73]

Hi, zum Thema Push oder Poll, hätte ich auch noch ne Anmerkung.
Ja, wenn ich viel polle, den Intvall der Abfrage sehr klein setze, belastet das bestimmt das System, vor allem wenn ich das an vielen Stellen einsetze.
Da muss man abwägen wo man was einsetzt. Ich habe z.B. ne Tabelle der IpAdressen meiner Tasmotageräte über die ich auch per Klick auf die Webobfläche der jeweiligen Geräte komme.(Danke an mickym) Die Ip ändert sich eigentlich nie, da polle ich per Injekt einmal bei Start bzw. ne Minute danach und dann täglich (bräuchte ich eigentlich nicht täglich machen) aber das belastet mein System nicht wirklich. Der Vorteil daran ist, die Geräte werden mir Alphabetisch in meiner Tabelle angezeigt, mache ich das per Push also per Iobroker In Node habe ich die Geräte in der Reihenfolge der eingegangenen Nachrichten, also sehr durcheinander. Das ist auf jeden Fall bei der template Node so, ich weiß nicht ob das bei der table Node besser ist.

[mickym]

@frankyboy73 Was Du machen kannst ist, das Pollen über die ui-control Node übernehmen zu lassen. Sprich wenn die Seite angezeigt wird, werden die Infos abgefragt. Damit muss man das System nicht mit zeitlichen Pollen belasten, sondern die Infos werden auf Bedarf abgerufen.

Darüber trigger ich zum Beispiel den Neuaufbau meiner Wetterseite:

Spoiler

[
   {
       "id": "d6b412e7.53ece",
       "type": "ui_ui_control",
       "z": "c36e56fc.dc8418",
       "name": "",
       "events": "change",
       "x": 120,
       "y": 2340,
       "wires": [
           [
               "6df57f3f.ad2e"
           ]
       ]
   },
   {
       "id": "6df57f3f.ad2e",
       "type": "switch",
       "z": "c36e56fc.dc8418",
       "name": "nur Wetter Tab",
       "property": "name",
       "propertyType": "msg",
       "rules": [
           {
               "t": "eq",
               "v": "Wetter",
               "vt": "str"
           }
       ],
       "checkall": "true",
       "repair": false,
       "outputs": 1,
       "x": 140,
       "y": 2420,
       "wires": [
           [
               "3703a69f.7fd61a"
           ]
       ]
   }
]

Das heißt über den Namen Deines Tabs - der Deine Tabelle enthält triggerst Du den Neuaufbau - zum Beispiel das Abfragen der Tabelle für Deine template Node.

Damit ersparst Dir dann den manuellen Refresh über den Button. Ausser natürlich wenn die Seite immer offen ist, dann macht ein Refresh Button natürlich Sinn (wobei das auch der Refresh Button im Browser sein kann - der funzt nämlich auch