Verfügbarkeit von Sensoren über Node Red überwachen
-
@mickym
Das war nur zur Veranschaulichung. Die eigentlichen Flows sehen so aus:
Die iobroker nodes sind alles list nodes.
Aber ja, die durch "in" nodes zu tauschen macht wahrscheinlich Sinn.
Zur Sicherheit, wäre dieser Tausch richtig?:
Ersetzen durch:
-
@schmetterfliege Im Prinzip ja - ich frag mich nur, warum Du immer die Objekte ausliest - bei den List Nodes geht es nicht anders - aber ansonsten ist das doch ebenfalls totaler Overhead - ich lese nur die Werte - bei den list Nodes gehts nicht anders aber in der Regel braucht man wie gesagt nur in Nodes und Wert. Ok aber in Deinem Subflow wirst wahrscheinlich dann auf payload.val auswerten.
-
@mickym
Naja, bei den Multisensoren lese ich aktuell zb am meisten aus:
Verfügbarkeit, Hum, Temp und Volt.
So brauche ich nur eine Node und jage den Output durch 1 Subflow.Wenn ich nur die Werte auslese, müsste ich für jeden Multisensor 4 eigene "flows" (keine Ahnung wie ein "Prozess" in einem Flow heißt^^) machen, oder?
Ich bastel mal die Alternative mit den Werten statt Objekten, dann kannst du mir ja sagen ob das richtig wäre
-
@schmetterfliege Nein - wenn Du
enthält die payload direkt den Wert. Allerdings geht dann der Auslesen zu Beginn nicht. Aber das triggern geht so.
Du musst halt wenn Du den Status einmal auslesen willst, nach Deiner List die payload.val in payload wandeln und dann kannst Du in Deinem subflow die payload direkt verarbeiten.
-
Das umwandeln von .val in payload mache ich ja im Subflow. Das Bild mit den ganzen Functions und dem Switch und split war der Inhalt vom Subflow.
Hab das jetzt mal mit IN nodes gemacht, das würde dann so aussehen im Vergleich:
Das Ergebnis wäre das gleiche, soweit ich das Beurteilen kann:
Was wäre denn für mein Raspi leistungstechnisch besser?
Die Subflows wäre ich dann alle los, finde das aber wenn man pro Flow 4 Sensoren hat irgendwie unübersichtlich, weil dann in jedem Flow 16+ IN nodes wären, statt 4 List Nodes
-
@schmetterfliege trotzdem ist das aber die beste Lösung - wenn Du nämlich ohne Wildcards in den in Nodes arbeitest, kannst Du auch zu Beginn auslesen und damit Dein Dashboard initialisieren. Und sind wir mal ehrlich, wenn Du für jede Ausgabe eine Node hast, dann kann man auch jeder Eingabe eine Node spendieren und dies 1:1 zuordnen.
Und bezgl. Übersichtlichkeit - da gibt es die tolle Gruppenfunktion im Node Red
-
Wegen dir schmeiße ich noch sämtliche Flows um
Aber geschuldet der Tatsache dass dein Knowhow mein KnowHow um das 10.000-fache Übersteigt, mache ich das jetzt einfach mal für alle Sensoren in allen Flows!Meine Subflows sind eh ein bisschen eskaliert...
-
@schmetterfliege Na dann bleiben ja trotzdem noch einige übrig.
-
ist mir auch grade aufgefallen - im Prinzip fällt ja nur der raus der alle Zigbee Datenpunkte verarbeiten kann
-
@mickym
Doofe Frage:
Ich wills mir einfach machen und per notepad die ganzen Nodes erstellen, statt alle einzeln zu setzen und konfigurieren.
Das hier ist der Export von einer IN node:[ { "id": "ea926d2c.f64e5", "type": "ioBroker in", "z": "9e290e9e.6c0fb", "name": "", "topic": "zigbee.0.00158d0005221c37.available", "payloadType": "value", "onlyack": "", "func": "all", "gap": "", "fireOnStart": "true", "x": 490, "y": 700, "wires": [ [] ] } ]Reicht es wenn ich da einfach "topic" entsprechend setze, oder sind ID und Z auch relevant?
-
@schmetterfliege Die sind auch relevant - jede Node hat eine eigene ID.
Du kannst aber statt jedes Mal das Topic über das Fenster zu selektieren den Pfad aus dem iobroker kopieren und in die Node kopieren. -
@schmetterfliege Du kannst aber auch gleich alle x Nodes kopieren und dann das topic im Editor editieren. Du musst halt nur die entsprechende Zahl an Nodes haben.
Also 4 InNode (occupancy, battery, available, ..) - die dann x Mal kopieren und dann im Editor die zigbee ID editieren. Generell würde ich aber dann lieber nodepad++ nehmen - du weisst ja dass Windows zu jedem LF noch ein CR oder umgekehrt anhängt.
-
Das mit aus Iobroker in die Node kopieren ist ja genau das was ich umgehen möchte, dann sitze ich ja noch morgen dran^^
Habe zumindest mal alle Pfade in eine Excel Liste gepackt und kann da easy für alle Geräte die entsprechenden Topics generieren.
Aber der copy-paste part.... uff.Aber das mit Nodes erstellen, exportieren, in Notepad ändern und importieren ist auf jeden Fall eine gute Idee.
Notepad++ nutze ich auf jeden Fall dafür!
Aber was ist LF und CR? -
@schmetterfliege LF = Line Feed, CR = Carriage Return
https://stackoverflow.com/questions/6521685/why-does-windows-use-cr-lf
-
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Das mit aus Iobroker in die Node kopieren ist ja genau das was ich umgehen möchte, dann sitze ich ja noch morgen dran^^
Habe zumindest mal alle Pfade in eine Excel Liste gepackt und kann da easy für alle Geräte die entsprechenden Topics generieren.
Aber der copy-paste part.... uff.Aber das mit Nodes erstellen, exportieren, in Notepad ändern und importieren ist auf jeden Fall eine gute Idee.
Notepad++ nutze ich auf jeden Fall dafür!
Aber was ist LF und CR?Das war nicht meine Absicht, dass Du nun alle Flows umschmeisst. Gibt ja oft viele Wege. die zum Ziel führen. Meine Flows die ich am Anfang gemacht habe, würde ich heute auch anders machen - aber solange es funktioniert bin ich zu faul.
-
Ist das oben genannte etwas dass du heute anders machen würdest? Wenn ja: wie?
-
@schmetterfliege Na das mit der 1:1 Zuordnung ist, wenn ich es in den Ausgaben so haben möchte genauso.
Mein Batterieüberwachung - oder auch Verfügbarkeit - würde ich halt von der Funktion total getrennt machen.
Meine Bewegungsmelder würde ich mit Wildcards machen, weil mich das nicht stört, wenn diese Werte zu Anfang nicht initialisiert sind - da das eh keine Aussagekraft hat bzw. könnte man einfach auch alles mit false initialisieren könnte. Wenn die erste Bewegung dann auftritt wird das aktualisiert.
Ich finde einen uninitialisierten Wert im Dashboard weniger tragisch - damit sieht man dann auch eher ob die Geräte alle melden. OK - wenn Du Dir natürlich jeden Status über telegram etc ausgeben lässt, dann ist es lästig - aber das muss man halt entscheiden, ob das für den jeweiligen Anwendungsfall wichtig ist.
Es gibt nicht immer ein richtig oder falsch - sondern es kommen auch immer persönliche Präferenzen mit ins Spiel und das ist ja das Schöne, dass sich das jeder so macht, wie es ihm am Besten gefällt.
-
Inwiefern würdest du die Verfügbarkeit getrennt machen? Hast du da ein Beispiel für mich?
Oder meinst du damit die 1:1 Zuordnung statt meinem Subflow?Nur für mein Verständnis, damit es sich irgendwann hoffentlich wirklich einbrennt:
List Node = keine initialisierung zu Anfang, sondern erst wenn ein Wert sich aktualisiert.
List Node kann aber getriggert werden und liefert dann auf jeden Fall einen Wert.
IN Node = initialisierung zu Anfang, aber nur wenn keine Wildcard benutzt wird?
Hab da grade mal rumgetestet:
Wenn ich eine IN node setze + Debug und dann den Flow deploye, bekomme ich sofort einen Output.
Wenn ich dann die Node verschiebe und damit nochmal deployen kann, bekomme ich keinen "initialen" Output.
Wenn ich die Node kopiere und neu setze, bekomme ich wieder einen initialen Output.
Für mich heißt das: Initialisierung nur bei tatsächlicher Änderung der Node (Erstellen, Config ändern, aber nicht nur verschieben).Wann ist denn dann die List Node der IN Node zu bevorzugen, wenn diese auch mit Wildcards genutzt werden kann? Was ist da dann der Unterschied?
Für Telegram habe ich einen ganz eigenen Flow.
Da hab ich nur die Türsensoren und einen Feuchtigkeitssensor die mir aktiv was senden. Alles andere passiert über Commands die ich über Telegram sende und dann eben eine Rückmeldung bekomme. -
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Inwiefern würdest du die Verfügbarkeit getrennt machen? Hast du da ein Beispiel für mich?
Oder meinst du damit die 1:1 Zuordnung statt meinem Subflow?Genau - den Flow den wir zu Anfang gemacht haben. In Deinem Subflow hast Du aber "Produktivwerte" mit "Überwachungswerten" (Batterie, Verfügbarkeit) gemischt - das würde ich eben nicht machen.
Nur für mein Verständnis, damit es sich irgendwann hoffentlich wirklich einbrennt:
List Node = keine initialisierung zu Anfang, sondern erst wenn ein Wert sich aktualisiert.Nein die List Node aktualisiert nie - und muss immer extern getriggert werden. Sie eignet sich eine Liste von Objekten mit Values auf Bedarf auszulesen. Bei einzelnen Werten nicht man bei manueller Triggerung die iobroker get Node
List Node kann aber getriggert werden und liefert dann auf jeden Fall einen Wert.
Muss immer extern getriggert werden, ist die richtige Ausdrucksweise
IN Node = initialisierung zu Anfang, aber nur wenn keine Wildcard benutzt wird?
Genau! - Ansonsten ist diese Node aber immer die erste Wahl, wenn der Flow durch eine Aktualisierung eines Datenpunktes angestoßen werden soll
Hab da grade mal rumgetestet:
Wenn ich eine IN node setze + Debug und dann den Flow deploye, bekomme ich sofort einen Output.
Wenn ich dann die Node verschiebe und damit nochmal deployen kann, bekomme ich keinen "initialen" Output.
Wenn ich die Node kopiere und neu setze, bekomme ich wieder einen initialen Output.
Für mich heißt das: Initialisierung nur bei tatsächlicher Änderung der Node (Erstellen, Config ändern, aber nicht nur verschieben).Wann ist denn dann die List Node der IN Node zu bevorzugen, wenn diese auch mit Wildcards genutzt werden kann? Was ist da dann der Unterschied?
Die List Node wird NIE von selbst einen Flow triggern, die IN Node dagegen immer sobald ein Datenpunkt aktualisiert wird. Das kann man ggf. noch einschränken - nur bei Wertänderung oder Wertänderungen um einen bestimmten Betrag
Für Telegram habe ich einen ganz eigenen Flow.
Da hab ich nur die Türsensoren und einen Feuchtigkeitssensor die mir aktiv was senden. Alles andere passiert über Commands die ich über Telegram sende und dann eben eine Rückmeldung bekomme.Ok da kann ich nicht viel sagen, da ich Telegram nicht nutze - weiss aber das man damit einiges machen kann - aber man schickt ja alles in einen Datenpunkt - entweder als Text oder eben mit den ganzen Möglichkeiten als JSON String
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Inwiefern würdest du die Verfügbarkeit getrennt machen? Hast du da ein Beispiel für mich?
Oder meinst du damit die 1:1 Zuordnung statt meinem Subflow?Genau - den Flow den wir zu Anfang gemacht haben. In Deinem Subflow hast Du aber "Produktivwerte" mit "Überwachungswerten" (Batterie, Verfügbarkeit) gemischt - das würde ich eben nicht machen.
Den Flow den wir zu Anfang gemacht haben (den du mir komplett zusammengebaut hast, mit dem Alarm) nutze ich hier gar nicht, sondern nur für Tasmota. Die Flows hier sind rein für das Dashboard. Ich würde jetzt (für das Dashboard) einfach alles mit IN Nodes machen und da die Values ausgeben, keinerlei Objekte. Das wäre das sinnvollste, oder?
Nur für mein Verständnis, damit es sich irgendwann hoffentlich wirklich einbrennt:
List Node = keine initialisierung zu Anfang, sondern erst wenn ein Wert sich aktualisiert.Nein die List Node aktualisiert nie - und muss immer extern getriggert werden. Sie eignet sich eine Liste von Objekten mit Values auf Bedarf auszulesen. Bei einzelnen Werten nicht man bei manueller Triggerung die iobroker get Node
Got it!
List Node kann aber getriggert werden und liefert dann auf jeden Fall einen Wert.
Muss immer extern getriggert werden, ist die richtige Ausdrucksweise
Würde ja bedeuten dass bei mir im Dashboard für diese Flows wirklich nur alle 10 Min die aktuellen Werte gezeigt werden.
Wenn ich so drüber nachdenke, glaube ich das stimmt sogar haha.
Ist mir aber tatsächlich nie aktiv aufgefallen oO Man bin ich doof... hab deswegen ja sogar den Refresh Button gemacht -.-IN Node = initialisierung zu Anfang, aber nur wenn keine Wildcard benutzt wird?
Genau! - Ansonsten ist diese Node aber immer die erste Wahl, wenn der Flow durch eine Aktualisierung eines Datenpunktes angestoßen werden soll
Got it! Damit hast du eine Frage/Unsicherheit - die ich seit ich mit NR angefangen habe - hab, geklärt - tausend Dank!!
Hab da grade mal rumgetestet:
Wenn ich eine IN node setze + Debug und dann den Flow deploye, bekomme ich sofort einen Output.
Wenn ich dann die Node verschiebe und damit nochmal deployen kann, bekomme ich keinen "initialen" Output.
Wenn ich die Node kopiere und neu setze, bekomme ich wieder einen initialen Output.
Für mich heißt das: Initialisierung nur bei tatsächlicher Änderung der Node (Erstellen, Config ändern, aber nicht nur verschieben).Wann ist denn dann die List Node der IN Node zu bevorzugen, wenn diese auch mit Wildcards genutzt werden kann? Was ist da dann der Unterschied?
Die List Node wird NIE von selbst einen Flow triggern, die IN Node dagegen immer sobald ein Datenpunkt aktualisiert wird. Das kann man ggf. noch einschränken - nur bei Wertänderung oder Wertänderungen um einen bestimmten Betrag
Got it!
Für Telegram habe ich einen ganz eigenen Flow.
Da hab ich nur die Türsensoren und einen Feuchtigkeitssensor die mir aktiv was senden. Alles andere passiert über Commands die ich über Telegram sende und dann eben eine Rückmeldung bekomme.Ok da kann ich nicht viel sagen, da ich Telegram nicht nutze - weiss aber das man damit einiges machen kann - aber man schickt ja alles in einen Datenpunkt - entweder als Text oder eben mit den ganzen Möglichkeiten als JSON String
Wie nutzt du dann deine Alarme? Nur als Debug Output in NR oder im Dashboard?
