Verfügbarkeit von Sensoren über Node Red überwachen
-
@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:
-
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
@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^^Na so hart wäre ich jetzt an Deiner Stelle auch nicht mit Dir selbst. Ich habe mir das auch erst nochmal mit dem Video klar gemacht, falls es Dich beruhigt. Auch wenn es im Nachhinein logisch ist, hat man halt trotzdem erst mal ein Brett vor dem Kopf.
Ich glaube Du kommst mit einer Change Node evtl. aus.
Und in diesem Fall kannst du die JOIN Node das Array auch wieder automatisch zusammensetzen lassen.
Kannst Du denn aus den Arrays noch das ursprünlgiche topic ermitteln oder ist das enthalten, sonst müsstest Du es ggf aufnehmen.
Wie ich gerade sehe - wurde das ja alles in flow.sensors gespeichert - also da müsste halt das topic enthalten sein.
Die berechne Differenz Change Node würde dann ausreichen - Du musst halt das topic in den Array Objekten mitschleifen, auch wenn es nicht in der Tabelle angezeigt würde und dann halt einer weiteren Eigenschaft zuordnen.
Dann kannst Du es mittels Change Node einfach so aus der Kontextvariablen auslesen:
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
@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^^Na so hart wäre ich jetzt an Deiner Stelle auch nicht mit Dir selbst. Ich habe mir das auch erst nochmal mit dem Video klar gemacht, falls es Dich beruhigt. Auch wenn es im Nachhinein logisch ist, hat man halt trotzdem erst mal ein Brett vor dem Kopf.
Ich glaube Du kommst mit einer Change Node evtl. aus.
Und in diesem Fall kannst du die JOIN Node das Array auch wieder automatisch zusammensetzen lassen.
Kannst Du denn aus den Arrays noch das ursprünlgiche topic ermitteln oder ist das enthalten, sonst müsstest Du es ggf aufnehmen.
Wie ich gerade sehe - wurde das ja alles in flow.sensors gespeichert - also da müsste halt das topic enthalten sein.
Die berechne Differenz Change Node würde dann ausreichen - Du musst halt das topic in den Array Objekten mitschleifen, auch wenn es nicht in der Tabelle angezeigt würde und dann halt einer weiteren Eigenschaft zuordnen.
Dann kannst Du es mittels Change Node einfach so aus der Kontextvariablen auslesen:
Merci!
Das mit der Change Node hatte ich anfangs probiert, aber wenn ich versuche über die Change Node einen neuen Payload zu "erstellen" (also zb. msg.payload.timedifference) hat der bei mir gemeckert dass das nicht existiert. Aber vermutlich habe ich da dann was anderes falsch gemacht.
Ich mach mal eben das mit den Call Nodes fertig und versuche das mit der Change Node dann nochmal anders zu machen -
@schmetterfliege Das muss nicht existieren - Du musst nur schauen, dass die payload bereits ein Objekt ist - wenn es ein skalarer Wert ist, meckert er, dass die payload kein Objekt ist.
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Das muss nicht existieren - Du musst nur schauen, dass die payload bereits ein Objekt ist - wenn es ein skalarer Wert ist, meckert er, dass die payload kein Objekt ist.
Was ist denn ein "skalarer Wert"?
-
@schmetterfliege Ein Sting, eine Zahl oder ein Boolean - also alles was nicht in irgendwelchen Klammern steht.
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Ein Sting, eine Zahl oder ein Boolean - also alles was nicht in irgendwelchen Klammern steht.
Verstehe ich irgendwie trotzdem nicht^^
Ich trigger einfach nur die Change Node um "payload.test" zu erstellen und den Text auszugeben. Der meckert dann aber dass das ein non-object ist.
Wie mache ich das denn zum Object? -
@schmetterfliege Ja weil die payload kein Objekt ist. Wenn gar nichts drin ist oder war - sagt er Dir er kann kein Wert für ein skalaren Wert oder in node red Sprache auf einen non-Object Type setzen. Wenn Du aber vorher die payload auf ein leeres Objekt setzt - dann funktioniert das.
So würde es gehen.
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Ja weil die payload kein Objekt ist. Wenn gar nichts drin ist oder war - sagt er Dir er kann kein Wert für ein skalaren Wert oder in node red Sprache auf einen non-Object Type setzen. Wenn Du aber vorher die payload auf ein leeres Objekt setzt - dann funktioniert das.
So würde es gehen.
aaaah, jetzt gerafft. Danke!
Ich arbeite sowohl mit dem Payload als Objekt, als auch als non-object, indem ich einfach zb. msg.temperature, msg.timestamp usw nutze.
Gibts irgendein Grund weshalb es besser wäre alles in ein Payload Objekt zu packen, statt wie ich einzelne...keine Ahnung wie man das nennt?... zu machen? -
@schmetterfliege Man kann auch die payload direkt also Objekt mit der Eigenschaft test zu definieren:
Gibts irgendein Grund weshalb es besser wäre alles in ein Payload Objekt zu packen, statt wie ich einzelne...keine Ahnung wie man das nennt?... zu machen?
Kann man nicht allgemein sagen.
msg.temperature, msg.timestamp sind ja auch nur Eigenschaften des Objektes msg. - Wenn Du Dir mal das komplette Nachrichtenobjekt anschaust. Die msg.payload ist genauso eine Eigenschaft, wie msg.topic oder msg.temperature - alles Eigenschaften des msg Objektes. Jede Eigenschaft eines Objektes kann wiederum ein Objekt sein usw.Manche Nodes zum Beispiel die iobroker- get Node kann zum Beispiel die Werte nicht Eigenschaften einer payload zuweisen. Andere Nodes oder transport zu anderen Systemen gehen nur über eine payload bzw. über einen JSON String. Man bildet also ein payload als Objekt - die eine JSON Node dann in einen String verwandelt und so kannst Du dann ein ganzes Objekt zum Beispiel in einen iobroker Datenpunkt schreiben.
Wenn Du den visuellen Editor eines Objektes benutzt, dann kannst Du ja sehen, dass Du sowohl skalare wie auch nicht skalare Datentypen den Eigenschaften eines Objektes zuweisen kannst.
