Verfügbarkeit von Sensoren über Node Red überwachen
-
@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?
-
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Wie nutzt du dann deine Alarme? Nur als Debug Output in NR oder im Dashboard?
Momentan nur im Dashboard bzw. lasse mir E-Mail schicken.
-
Das ist natürlich auch eine Möglichkeit!
Nochmals vielen herzlichen Dank für deine ganze Unterstützung!
Ich habe vieles gelernt!Bezüglich der Umstellung dass nicht alles stringyfiziert wird: bisher ist mir nur eine Sache aufgefallen die nicht mehr geht:
Ich muss das Licht im Bad selbst ein und ausschalten hahaha -
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Nochmals vielen herzlichen Dank für deine ganze Unterstützung!
Immer gerne - ich mach das auch, weil ich oft ja selbst was lerne.
-
Hätte doch nochmal eine Frage :S
Ich habe 6 Türen/Fenster die ich über solche IN Nodes tracke:
Den Output schicke ich mir dann per Telegram - ist aber irrelevant für das Problem.
Die einzelnen Nodes spucken ab und an den Value aus - obwohl dieser sich nicht ändert.
Ich vermute dass der Triggert, wenn der Wert aktualisiert wird.
Aber beim Aktualisieren ändert der sich nicht, also wenn der Wert false war, ist er beim aktualisieren auch false.
Eigentlich würde ich erwarten, dass er das dann ignoriert - tut er aber nicht.
Kann sein dass das jetzt nur 1 mal passiert weil ich bei allen das "send message at start" deaktiviert habe und die dadurch neu geladen wurden.
Ist aber leicht nervig wenn ich Nachts um halb 2 eine Benachrichtung bekomme dass die Eingangstür geschlossen wurde - obwohl die gar nicht geöffnet wurde^^Weißt du, wie ich das unterbinden kann?
-
@schmetterfliege Den Modus der IN_Node einstellen:
Wenn Du nicht zum Start einliest - dann ist die erste Nachricht natürlich geändert (auch wenn sie nur aktualisiert wurde) - da die Node ja nicht initialisiert wurde und somit noch gar kein Wert gespeichert war.
Ansonsten lässt Du alle Nachrichten durch auch nicht geänderte und machst eine rbe Node dazwischen - da kann man einstellen, dass die erste Nachricht ignoriert wird.
-
Beim Start einlesen hatte ich deaktiviert weil ich dann für alle 6 eine Nachricht bekam wenn NR oder der Flow neu startet.
Ich probiere es mal mit der Message beim Start in Kombination mit der rbe Node und beobachte es
-
Und noch etwas anderes :S
(sorry!)Ich habe im Dashboard eine Tabelle die mir die Temp und Humidity für die 18 Sensoren anzeigt:
Aktuell baue ich die so auf:
Ich triggere alle 5 Minuten Get Nodes für jeden Adapter, füge alles zu einem zusammen und schiebe es in die Tabelle.Würdest du das - damit immer die aktuellen Werte drin stehen - mit IN Nodes lösen?
Das wären dann sage und schreibe 36 Nodes^^
Hab das mal mit einer zweiten Tabelle probieren wollen, das endete aber mit diesem Fehler wenn ich etwas in die Tabelle schreiben wollte:
Dementsprechend habe ich gerade ein wenig Angst da weiterzumachen^^Kurzum: würdest du die Tabelle so lassen wie sie ist, oder hättest du eine sichere und effektivere Alternative das zu lösen?
-
@schmetterfliege Wenn Du die ui_table nimmst - dann kannst Du die IN-Node nehmen. Mit der ui-Table beschäftige ich mich gerade selbst etwas - habe aber das Prinzip verstanden. Die Zuordnung als auch als Update müsste entweder direkt über die id funktionieren, ansonsten würde man das mit dem update Kommando machen.
Dazu muss man dann in die table folgendes Objekt schicken:
msg.payload={ command:"updateOrAddData", arguments: [ [ { "id":id, "temperature":msg.payload, } ] ], returnPromise: true }Hinter der ui_table steckt die zienlich mächtige Tabulator Bibliothek. Also das ist nichts was mal so aus der Hand zu schütteln ist. Letztlich sind die Möglichkeiten immens: http://tabulator.info/docs/5.0/reactivity
Grundsätzlich würde ich das jedoch immer mit der IN-Nodes Triggern.
Da ich erst mit der ui_table mich beschäftigt habe - habe ich bislang selbst mit einer template Node gemacht - daber im Prinzip ist das egal.
Ich würde vom Ansatz es aber so machen, dass ich alles in einer Flowvariable sammle, und dann bei einem Update die Tabelle neu aufbaue. - Also Deine Pollerei solltest Du Dir eher abgewöhnen.
Um es einfach zu sagen:
Bau Dein Objekt Array in einer Flow Variable auf und wenn Du ein Update über die In Node bekommst schreibst Du die Tabelle neu, indem Du das Array neu schickst. -
@mickym
Nutze in der Tat die ui_table!
Ich möchte dich nicht nerven, aber hättest du ein Beispiel für mich, wie ich diese Flow Variable nutze?
Einfach mit 2 beliebigen IN Nodes, damit ich das Prinzip sehe und dann entsprechend übernehmen könnte -
@schmetterfliege dauert bissi - leg mal ein paar DP unter userdata an - um es zu demonstrieren
-
@mickym
sowas hier? -
@schmetterfliege Das hier kannst importieren - damit wir die gleiche Voraussetzungen haben:
Halt nochmal:
War verkehrt oder der letzte Wert war String und keine Zahl
Müsste dann so aussehen:
-
@mickym
erledigt!
