Verfügbarkeit von Sensoren über Node Red überwachen
-
aaaaaah, habs verstanden.
Nach der Function Node holst du dir alle Werte, splittest die dann und berechnest jeweils.Sorry!
-
@schmetterfliege Der Kandidat hat 100 Punkte.
Wie gesagt, so verbraucht das am wenigsten Ressourcen. Wenn Du unbedingt regelmäßige Updates haben willst. dann siehst Du eine Inject Node als trigger im Flow- die kannst Du natürlich auch periodisch triggern lassen und Du hast zusätzlich in best. Zeitabständen Updates.
-
ich versuche ja gar nicht das periodisch zu machen. Sondern so wie du, dass er die Zeiten updatet wenn irgendein Gerät neue Daten liefert.
Bin aber gerade irgendwie am scheitern an den Timestamps...
Ich möchte die Timestamps nehmen die das System bzw. der Adapter mir sowieso liefert.
Aber aus irgendeinem Grund kommt da bei sau vielen Geräten "vor 3 Tagen" raus.. bin grade noch am probieren -
@schmetterfliege Wie gesagt - ich finde das mit Timestamps auslesen überflüssig - ich fange halt von vorne an - wenn der NR Adapter startet. Wenn Du es wirklich so genau haben willst, dann musst Du die Timestamps ja nur zum Initialisieren der Objekte auslesen. Dann musst halt sehen, ob die richtigen Moments gebildet werden - wenn Du ein debug Node anhängst - dann siehst Du ja was für ein Datum rauskommt. Ich halte das wie gesagt für überflüssigen Aufwand, da sich alle Geräte innerhalb von 2 Stunden sowieso melden. Ansonsten schau Dir mal meinen Thread an - wo ich die moments Bibliothek ausgiebig getestet und erläutert habe. Was interessieren mich Timestamps vom Adapter, wenn ich selbst direkt ermittle, wann sich ein Gerät meldet.
https://forum.iobroker.net/topic/50086/datum-und-zeitverarbeitung-mit-nodered
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Wie gesagt - ich finde das mit Timestamps auslesen überflüssig - ich fange halt von vorne an - wenn der NR Adapter startet. Wenn Du es wirklich so genau haben willst, dann musst Du die Timestamps ja nur zum Initialisieren der Objekte auslesen. Dann musst halt sehen, ob die richtigen Moments gebildet werden - wenn Du ein debug Node anhängst - dann siehst Du ja was für ein Datum rauskommt. Ich halte das wie gesagt für überflüssigen Aufwand, da sich alle Geräte innerhalb von 2 Stunden sowieso melden. Ansonsten schau Dir mal meinen Thread an - wo ich die moments Bibliothek ausgiebig getestet und erläutert habe. Was interessieren mich Timestamps vom Adapter, wenn ich selbst direkt ermittle, wann sich ein Gerät meldet.
https://forum.iobroker.net/topic/50086/datum-und-zeitverarbeitung-mit-nodered
Wäre dann der nächste Step, sobald meine Geräte zuverlässig funktionieren. Da sind durchaus Geräte dabei die eben nicht alle 2 Stunden schreien. Teilweise sind auch Geräte dabei die noch in Kartons verpackt sind und noch nicht wieder eingesetzt wurden.
Solange ich nicht sicher sein kann dass alle Geräte zuverlässig sind, möchte ich ungern Timestamps nehmen die beim Absturz von NR weg sind.Hänge aber gerade ein wenig fest und verstehe nicht wieso.
Meinen Fehler wegen den 3 Tagen habe ich gefunden, ich hatte an einer vorherigen Stelle im Flow das abspeichern der Timestamps verhauen, weshalb diese nicht mehr geupdated wurden und deshalb 3 Tage rauskamen.
Das hab ich jetzt soweit gefixt, aber:Der Teil berechnet mir die Differenzen. Ich hole alle gespeicherten Werte vom Flow (in der Change Node vor split -> Join relativ am Ende) und berechne dann pro Topic die Differenz und speicher sie wieder ab. Das funktioniert soweit auch. Aber ich check nicht an welche Stelle vom gesamten Flow ich das packen muss.
Mache ich das direkt vor die Funktion die meine Tabelle zusammenbaut, bleibt die Tabelle leer. Obwohl die Funktion ja keine Daten von irgendwelchen Payloads übernimmt, sondern sich alles aus dem Flow holt.So sieht der Flow aus ohne die Berechnung der Differenz:
ja, is hässlich - aber funktioniert
-
Nevermind, die letzte Function Node holt sich das Zeug gar nicht aus dem Flow, sondern aus jener change Node...
Habs, muss vor dem Zusammenbau der Tabelle nochmal den gesamten Flow holen, splitten und wieder joinen.
Wenn ich das nicht mache, updatet die Tabelle nicht.
D.h. Payload direkt übergeben geht nicht, Payload splitten und wieder zusammenfügen aber schon? Übersteigt gerade meinen Horizont^^ -
@schmetterfliege Ich kann mich so noch dunkel daran erinnern. In dem Fall - wenn Du es unbedingt in Deiner Tabelle haben willst, dann müsste man die Daten einbauen, bevor das Array gebildet wird - also vor der letzten JOIN Node. Wahrscheinlich würde ich keinen extra Flow machen - sondern über eine Call Node - den Zeitermittlungsflow einzubauen. Dadurch dass wir aber über die Kontextvariable die Eigenschaft des topics zu verwenden, dann musst halt die Zeitdifferenz nach der split Node einzeln ermitteln.
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Ich kann mich so noch dunkel daran erinnern. In dem Fall - wenn Du es unbedingt in Deiner Tabelle haben willst, dann müsste man die Daten einbauen, bevor das Array gebildet wird - also vor der letzten JOIN Node. Wahrscheinlich würde ich keinen extra Flow machen - sondern über eine Call Node - den Zeitermittlungsflow einzubauen.
Ordnung reinbringen wäre dann einer der nächsten Steps, solange das noch nicht sauber läuft komme ich mit dem Chaos besser klar haha. Aber dürfte jetzt soweit eigentlich einen ordentlichen Stand haben bei dem ich jetzt anfangen kann Ordnung zu schaffen
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Ich kann mich so noch dunkel daran erinnern. In dem Fall - wenn Du es unbedingt in Deiner Tabelle haben willst, dann müsste man die Daten einbauen, bevor das Array gebildet wird - also vor der letzten JOIN Node. Wahrscheinlich würde ich keinen extra Flow machen - sondern über eine Call Node - den Zeitermittlungsflow einzubauen. Dadurch dass wir aber über die Kontextvariable die Eigenschaft des topics zu verwenden, dann musst halt die Zeitdifferenz nach der split Node einzeln ermitteln.
Auf einer Skala von 1-10, wie mies ist der Teil hier?
Das wäre jetzt meine Lösung. Flowvariable holen, für jedes Gerät anhand des Timestamps die Zeitdifferenz berechnen und wieder im Flow speichern, dann nochmal die Flowvariablen holen, splitten und zusammenfüge (checke echt nicht why) und dann die Tabelle aufbauen.
EDIT: Glaube kann mir die Frage selbst beantworten.
Wenn ich nicht ganz doof bin, würde der für jedes Abspeichern (18 Geräte) nochmal die Flowvariable holen + splitten und dann zusammenfügen und die Tabelle erstellen.
Also für jedes Update mache ich dann doch 18 mal die Tabelle neu, oder?
Bräuchte eher eine Skala mit Minusbereich...Wäre die Lösung nach dem Abspeichern noch ein JOIN dazwischen zu packen und eine Sekunde zu warten? Dann dürfte der danach doch nur 1 mal weitermachen statt 18 mal, oder?
-
@schmetterfliege Im Übrigen schau Dir halt die moments Bibliothek an und was ich in dem Thread geschrieben habe. Es gibt ja nicht nur fromNow(), sondern auch from - damit kann man dann auch die Differenz zwischen zwei beliebigen moment Objekte berechnen.
-
@schmetterfliege Ehrlich gesagt - ist mein Geist zu müde - das Nachzuvollziehen. Wenn es funktioniert - dann machs.
- Ich hab in der Kürze auch kein Idee. Die Tabelle war schon eine Herausforderung und nun auch die Timestamps in die Tabelle aufzunehmen - habe ich ehrlich gesagt momentan keinen Plan und bin wie gesagt auch zu faul einen Plan zu machen. -
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Ehrlich gesagt - ist mein Geist zu müde - das Nachzuvollziehen. Wenn es funktioniert - dann machs.
- Ich hab in der Kürze auch kein Idee. Die Tabelle war schon eine Herausforderung und nun auch die Timestamps in die Tabelle aufzunehmen - habe ich ehrlich gesagt momentan keinen Plan und bin wie gesagt auch zu faul einen Plan zu machen.Okidoki
Dann wünsche ich dir mal eine wunderbare Nacht und einen entspannten und erholenden Schlaf
-
@schmetterfliege Nee in die Heia gehe ich noch nicht - ich bin schon noch da - aber keine Lust Flows zu machen - das heißt ja nicht, dass Du nicht kreativ sein kannst. Du kannst gerne einzelne Fragen stellen - aber nicht einen Flow, den ich beurteilen soll.
-
Für mich war's aber Zeit
Mein Schlafrythmus ist seit 2 Jahren eher... "ungesund" und nicht grade optimal für mein Arbeitsleben - den muss ich langsam mal in die richtige Richtung drücken hehe.Ich stelle die Frage(n) nochmal und versuche keine komplette Flow-Analyse daraus zu machen
In meinem Flow wird alles möglich in die Kontextvariablen gepackt, zum Ende dann alle Variablen geladen und damit die Tabelle gebastelt. Soweit so gut.
Um die Berechnung der Differenz zu machen muss ich ja auch den Kontext laden, die Berechnung machen und das dann wieder im Kontext speichern. Soweit auch so gut.Im Flow muss das ja passieren nachdem ich alle anderen Daten gesammelt habe und bevor ich die Tabelle erstelle.
Deshalb mache ich die Berechnung direkt vor dem Erstellen der Tabelle.
Meine Fragen:- Um die Tabelle zu basteln muss ich vorher den Kontext in den Payload packen. Das alleine funktioniert aber nicht, sondern ich muss diesen Payload erst splitten und dann wieder joinen. -> Warum? Was für einen Unterschied macht es den Kontext zu übergeben vs. Kontext splitten dann wieder joinen und dann übergeben?
- Das Berechnen der Differenzen triggert ja jedes mal die nächste Node, was dann den Kontext lädt (splittet und joint) und dann die Tabelle erstellt. Ich berechne 18 Differenzen, d.h. long story short: die Tabelle wird jedes mal 18 mal aufgebaut.
Um das zu verhindern wäre meine Idee nach dem Abspeichern ein JOIN zu machen und eine Sekunde zu warten. Dann geht es (hoffentlich) nur 1 mal weiter statt 18 mal.
Frage: fällt dir da eine elegantere Lösung ein?
Bei so viel Text sieht das wieder aus als hätte ich gern eine komplette Analyse - ist aber nicht die Intention, versprochen
-
Mal was ganz anderes:
Ich spiele grade mit den Link in/out/call Nodes rum.
Wofür ist denn die Link Call Node gut? Die hat leider keinerlei Eintrag im Handbuch -
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Das alleine funktioniert aber nicht, sondern ich muss diesen Payload erst splitten und dann wieder joinen. -> Warum? Was für einen Unterschied macht es den Kontext zu übergeben vs. Kontext splitten dann wieder joinen und dann übergeben?
Nun das ist einfach die Methode einzelne Objekte zu verändern - in der klassischen Programmierung würdest Du es über eine Schleife machen, die auch jedes einzelne Objekt anfasst. Du kannst auch function Nodes schreiben indem Du über Objekte oder Arrays iterierst. Das Ausplitten und joinen ist also dafür nötig, um letztlich ein Array von Objekten zu erzeugen, dass die table Node benötigt.
Um das zu verhindern wäre meine Idee nach dem Abspeichern ein JOIN zu machen und eine Sekunde zu warten. Dann geht es (hoffentlich) nur 1 mal weiter statt 18 mal.
Bei Arrays bleibt Dir sowieso nur die Zeit übrig - ich es ehrlich gesagt in Deinem Fall so machen würde, dass ich im Prinzip diese ganze Zeitstempel nach der letzten JOIN Node des ursprünglichen Flows einbauen würde. Da dann bereits die Anzahl der Elemente im Array unverändert bleibt, würde ich das Array aufsplitten und automatisch wieder zusammensetzen lassen. Dann würde ich nur für jede einzelne Nachricht die Zeitdifferenz berechnen lassen und in das Objekt mit aufzunehmen. Im Prinzip also von dem zentralen Flow Abschied nehmen. Über das initiale Einlesen hast Du ja alle Timestamps in Deiner Flow variable. Ich würde also einen anderen Ansatz nehmen.
-
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Mal was ganz anderes:
Ich spiele grade mit den Link in/out/call Nodes rum.
Wofür ist denn die Link Call Node gut? Die hat leider keinerlei Eintrag im HandbuchJa die wäre für Dich geeignet. Ist - wie eine Art Unterprogramm aufzurufen. Wie gesagt fang mal an mit der ersten Initialisierung in Deinem Flow Kontext die Zeitstempel der Geräte mit den Topics als Objekteigenschaften zu sammeln . Die Zeitdifferenzen berechnest Du dann nach einem split hinter der letzten JOIN Node für jedes einzelne Objekt.
Bei der CALL Node musst Du nur unbedingt darauf achten, dass die auf jeden Fall wieder zu aufrufenden Node zurück kehrt.
Du machst also eine Call Node hinter die split Node und kannst dann über eine Link-In Node die Zeitdifferenzen berechnen .- die link-out Node musst dann so konfigurieren, dass diese wieder an die aufrufende Node zurückkehrt.
Hier wieder das Video von meinem amerikansichen NodeRed Guru: https://www.youtube.com/watch?v=qryeuduhsoo
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Das alleine funktioniert aber nicht, sondern ich muss diesen Payload erst splitten und dann wieder joinen. -> Warum? Was für einen Unterschied macht es den Kontext zu übergeben vs. Kontext splitten dann wieder joinen und dann übergeben?
Nun das ist einfach die Methode einzelne Objekte zu verändern - in der klassischen Programmierung würdest Du es über eine Schleife machen, die auch jedes einzelne Objekt anfasst. Du kannst auch function Nodes schreiben indem Du über Objekte oder Arrays iterierst. Das Ausplitten und joinen ist also dafür nötig, um letztlich ein Array von Objekten zu erzeugen, dass die table Node benötigt.
Wow, ich schäme mich gerade echt überhaupt die Frage gestellt zu haben.
In der Node ist doch klar ersichtlich dass er ein Array erstellt und nicht wieder einen einzigen Payload... I'm sorry
Die Function Node baut die Tabelle dann für jeden Eintrag im Array, also jede Zeile.
Ganz ehrlich, dass mir jetzt erst klar wird bzw ich realisiere wie das was ich da mache funktioniert (oder wieder?) bringt mich grade echt so ein bisschen an den Rand der Verzweiflung...
Wirklich, ganz herzlichen Dank dass du dich trotzdem mit mir außeinandersetzt!Um das zu verhindern wäre meine Idee nach dem Abspeichern ein JOIN zu machen und eine Sekunde zu warten. Dann geht es (hoffentlich) nur 1 mal weiter statt 18 mal.
Bei Arrays bleibt Dir sowieso nur die Zeit übrig - ich es ehrlich gesagt in Deinem Fall so machen würde, dass ich im Prinzip diese ganze Zeitstempel nach der letzten JOIN Node des ursprünglichen Flows einbauen würde. Da dann bereits die Anzahl der Elemente im Array unverändert bleibt, würde ich das Array aufsplitten und automatisch wieder zusammensetzen lassen. Dann würde ich nur für jede einzelne Nachricht die Zeitdifferenz berechnen lassen und in das Objekt mit aufzunehmen. Im Prinzip also von dem zentralen Flow Abschied nehmen. Über das initiale Einlesen hast Du ja alle Timestamps in Deiner Flow variable. Ich würde also einen anderen Ansatz nehmen.
Guter Ansatz, ich werde das versuchen so umzusetzen wenn ich das mit den Link Nodes verstanden und umgesetzt habe um aufzuräumen
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Mal was ganz anderes:
Ich spiele grade mit den Link in/out/call Nodes rum.
Wofür ist denn die Link Call Node gut? Die hat leider keinerlei Eintrag im HandbuchJa die wäre für Dich geeignet. Ist - wie eine Art Unterprogramm aufzurufen. Wie gesagt fang mal an mit der ersten Initialisierung in Deinem Flow Kontext die Zeitstempel der Geräte mit den Topics als Objekteigenschaften zu sammeln . Die Zeitdifferenzen berechnest Du dann nach einem split hinter der letzten JOIN Node für jedes einzelne Objekt.
Bei der CALL Node musst Du nur unbedingt darauf achten, dass die auf jeden Fall wieder zu aufrufenden Node zurück kehrt.
Du machst also eine Call Node hinter die split Node und kannst dann über eine Link-In Node die Zeitdifferenzen berechnen .- die link-out Node musst dann so konfigurieren, dass diese wieder an die aufrufende Node zurückkehrt.
Hier wieder das Video von meinem amerikansichen NodeRed Guru: https://www.youtube.com/watch?v=qryeuduhsoo
Danke dir für den Link und den Input!
Die Funktion der Nodes ist absolut selbsterklärend, keine Ahnung warum ich mit "return to calling node" nicht gecheckt habe dass damit literally die "Link Call" Node gemeint ist.
Entweder ich bin wirklich so stupide, oder ich sollte aufhören mich erst nach Mitternacht mit NR zu beschäftigen..ich geh mich gleich vergraben^^ -
Ich habe noch rundimentäre Teile unserer Nodes gefunden - aber ich werde Deinen Flow nicht mehr importieren - da ich auch den Zigbee Adapter nicht mehr verwende.
Also wie gesagt, wenn Du bei der Initialisierung die Timestamps in einem Flow Objekt gespeichert hast, dann kannst Du eine link call Node verwenden, aber eigentlich rentiert es sich nicht weil wahrscheinlich eine einfache Change Node ausreichnen würde:
