Verfügbarkeit von Sensoren über Node Red überwachen
-
@schmetterfliege Grundsätzlich habe ich Dir schon mal gesagt, dass mir die Uhrzeiten egal sind, sondern dass ich einfach eine Trigger Node verwende, die Alarm schlägt, wenn sich ein Gerät eine bestimmte Zeit lang nicht gemeldet hat.
Es macht keinen Sinn - sowas zu pollen oder aktiv abzufragen, das belastet das System in meinen Augen nur unnötigerweise.
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Die Datenpunkte hole ich mir im IoBroker über den Zigbee Adapter. Der zeigt ja erfreulicherweiße bei jedem Gerät an wann zuletzt ein Update von einem Device kam. (Erstes Icon neben den Namen). Der Adapter berechnet das vermutlich in Hintergrund und speichert den Wert nicht ab (zumindest finde ich ihn nicht).
Genau so mache ich das inzwischen auch. Auch diese Zeiträume in den Kacheln sind kein aktives pollen, sondern geben nur die Zeiträume wieder, wann sich ein Gerät das letzte Mal gemeldet hat. Ich mache das inzwischen auch - wobei ich das mit jedem Start des NodeRed Adapter neu starte - das ist aber auch OK. Sprich ich merke mir nur, wann sich ein Gerät gemeldet hatte. Meldet sich ein anderes Gerät wird automatisch für jedes Gerät ermittelt, wann es sich zuletzt gemeldet hatte. Das ist für mich hinreichend genau.
So habe ich quasi auch kein Datum - sondern wie bei den Kacheln immer eine Zeitangabe, wie alt ein Status ist:
Das Speichern der Zeit und das Ausrechnen findet quasi in einem zentralen Flow statt:
Das Vergleichen mit irgendwelchen Zeitstempeln ist nur aufwendig und bringt keinen Mehrwert in meinen Augen. Zudem sowohl in zigbee2mqtt als auch wahrscheinlich im Adapter es völlig ausreichend ist, die Zeitdifferenz für alle Geräte neu zu berechnen, wenn sowieso irgendein Ereignis stattgefunden hat. Von diesem minütlichen Pollen kann ich nur abraten - belasten ein System ohne wirklichen Mehrwert. Allerdings habe ich ja auch Bewegungsmelder - so dass jede Bewegung die Zeitstempel aktualisiert. - Wenn keiner in der Wohnung ist, dann halt seltener.
-
Danke für deinen Input!
Kannst du mir die Node mal zeigen mit der du die Berechnung machst?
Minütlich brauche ich das nicht für alle Geräte, ich kam nur nicht gedanklich auf die Idee dass ich die Berechnung für die Geräte triggere, wenn irgendein Update für meine Tabelle kommt. Das macht es definitiv deutlich einfacher!
-
@schmetterfliege Na das ist keine Node. Wie gesagt - ausser der Alarm - das ist aber andere Sache - mache ich in einem extra Post.
Alle Geräte melden - egal was sie tun - an einen zentralen Flow:
Das Gerät aktualisiert nur im Flow-Kontext seinen eigenen Zeitstempel (links vom lila Strich)
Das Gerät aktualisiert also nur seinen eigenen Zeitstempel:
Dieses Array wird dann in die payload eingelesen in einzelne Nachrichten aufgeteilt und mit einer einfachen Change Node (das ist die vor der switch Node) ermittelt wie alt der Zeitstempel von jetzigen Augenblick ist und das wird dann ggf. ausgegeben:
Also ganz simpel.
-
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Danke für deinen Input!
Kannst du mir die Node mal zeigen mit der du die Berechnung machst?
Minütlich brauche ich das nicht für alle Geräte, ich kam nur nicht gedanklich auf die Idee dass ich die Berechnung für die Geräte triggere, wenn irgendein Update für meine Tabelle kommt. Das macht es definitiv deutlich einfacher!Noch einfacher ist die Überwachung, wobei das heute mit einer trigger Node geht, da diese intern nach verschiedenen topics selbst unterscheiden kann. Ich bin nur zu faul, alte funktionierende Flows zu ändern.
Hier mal die Zigbees:
Die trigger Nodes melden also zum Start ein true und nur false , wenn ein Gerät innerhalb von 2 Stunden sich nicht gemeldet hat.
Über eine JOIN Node - wird ein JSON String abgespeichert.{ "Präsenz Wohnzimmer": true, "Würfel Büro": true, "Schlafzimmer Schrank Links": true, "Präsenz Flur": true, "Präsenz Diele": true, "Präsenz Büro": true, "Präsenz Bad": true, "Präsenz Küche": true, "Schlafzimmer Schrank Mitte": true, "Thermometer Gefrierfach": true, "Thermometer Kühlschrank": true, "Schlafzimmer Schrank Rechts": true, "Würfel Schlafzimmer": true, "Würfel Wohnzimmer": true, "Thermometer Bad": true, "Thermometer Küche": true, "Präsenz Schlafzimmer2": true, "Präsenz Schlafzimmer": true, "Präsenz Wohnzimmer Essbereich": true }Sobald der JSON aktualisiert wird - wird ein kleiner Flow angestoßen.
Alarm-Flow:
Dieser meldet Alarm, sobald ein Gerät false ist:
Also alles sehr simple - funktioniert für mich aber bestens.
-
Wow, das ist ausführlich! Danke!
Die change node, bzw. der Teil mit ".fromNow()" ist genau das was ich gesucht hatte
In meiner Lösung hätte ich per Function Node die Differenz berechnet und dann mit ganz vielen Abhängigkeiten entsprechend formatiert (Minute, Minuten, Stunden, Tage, usw). Aber das macht es ja unendlich viel einfacher hehe.Jetzt sind die Geräte die seit dem ersten Auszug noch nicht verbunden waren nicht mehr seit 17k Minuten ohne Update
-
@schmetterfliege Ja das kommt aber nur in der "human" readable Form raus. Also wenn länger als 1 Tag -siehst Du auch nur - hat sich einen Tag nicht gemeldet und nicht 1 Tag 4 Stunden und 44 Minuten.
So wie bei der Kachel halt auch. -
Die Idee mit deinem zentralen Flow und dem Alarm-Flow baue ich mir die Tage mal nach, das macht das Ganze deutlich organisierter und übersichtlicher
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Ja das kommt aber nur in der "human" readable Form raus. Also wenn länger als 1 Tag -siehst Du auch nur - hat sich einen Tag nicht gemeldet und nicht 1 Tag 4 Stunden und 44 Minuten.
So wie bei der Kachel halt auch. solange der bei 2 Tagen dann 2 Tage draus macht, passt das
-
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Ja das kommt aber nur in der "human" readable Form raus. Also wenn länger als 1 Tag -siehst Du auch nur - hat sich einen Tag nicht gemeldet und nicht 1 Tag 4 Stunden und 44 Minuten.
So wie bei der Kachel halt auch. solange der bei 2 Tagen dann 2 Tage draus macht, passt das
Ist exakt definiert:
und die Moments Bibliothek - übersetzt diese Strings mit locale('de') - sogar noch auf deutsch.
Also ab 22 Stunden wird dann schon mal vor einem Tag ausgegeben. - Es wird also durchaus aufgerundet, also 36 Stunden sind bereits 2 Tage usw. - das heißt - es geht nie um die exakte Zeit - sondern eine Zeitangabe die es halt am nächsten trifft. -
Das ist ja sogar gesichert vor Noobs wie mir!
Hab in der Tabelle versehentlich die Werte für Temperatur statt dem Zeitstempel mitgegeben und da kommen dann 53 Jahre bei raus.
Gibt man dem also ein Datum vor 1970 (zb. 22.38) geht also nix kaputt, gut zu wissen haha. -
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Hab in der Tabelle versehentlich die Werte für Temperatur statt dem Zeitstempel mitgegeben und da kommen dann 53 Jahre bei raus
- 1970 sind ja schon 53 Jahre - wird ja aufgerundet - sind ja schon in der 2. Jahreshälfte. -
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Hab in der Tabelle versehentlich die Werte für Temperatur statt dem Zeitstempel mitgegeben und da kommen dann 53 Jahre bei raus
- 1970 sind ja schon 53 Jahre - wird ja aufgerundet - sind ja schon in der 2. Jahreshälfte. Exakt
-
Abend Micky,
könntest du mir kurz erläutern was das "$moment(timestamp)" genau macht?
Prinzipiell funktioniert das, allerdings zeigt er für alle sensoren die Updates liefern "vor einigen Sekunden", obwohl da teilweise Stunden zwischen den letzten Updates liegen.
-
Ich glaube ich weiß was das Problem ist...
Ich berechne den Wert nur für jedes Gerät einzeln wenn dieses ein Update liefert, und nicht für alle wenn irgendeins ein Update liefert. Entsprechend updated das für ein Gerät nur, wenn dieses Gerät neue Werte liefert.
Muss da also nochmal dran basteln -
@schmetterfliege Das ist auch logisch bzw. überflüssig. Wenn Du den aktuellen Timestamp nimmst - kannst es auch gleich weglassen. Das heißt Du erstellst ein moment Objekt mit Zeitstempel von JETZT. Wenn Du dann das Ganze in fromNow() pipst - dann heißt das - wieviel Zeit ist vom Zeitpunkt jetzt vergangen - und das sind nun mal immer wenige Sekunden. Für das Gerät, dass gerade aktualisiert wurde, ist ja die vor wenigen Sekunden ok. Für alle anderen Geräte wird aber per $moment(payload) auf den letzten Zeitstempel der in der Kontextvariablen gespeichert ist verwendet.
-
@schmetterfliege Hier mal der Core Flow von mir - ist ja kein Geheimnis:
Die Zeitstempel werden in diesem Flow in fState gespeichert.
-
Jein, den Timestamp speicher ich für jedes Gerät damit ich weiß zu welchem Zeitpunkt es Daten geliefert hat.
Und dann berechne ich ja dummerweiße nur für das Gerät, das in dem Moment neue Daten liefert, statt für alle.
Also auf die Timestamps muss ich mich schon beziehen, aber eben für alle berechnen wenn ein Update kommtOder habe ich da jetzt einen Denkfehler?
-
@schmetterfliege Ich hab Dir gerade den CoreFlow gepostet.
Ja Du hast ja recht - brauchst aber den Timestamp nicht. In der ersten Change Node -
wird wenn nichts angegeben wird immer JETZT verwendet.
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Ich hab Dir gerade den CoreFlow gepostet.
Ja Du hast ja recht - brauchst aber den Timestamp nicht. In der ersten Change Node -
wird wenn nichts angegeben wird immer JETZT verwendet.
Und wo kommen dann die "timestamps" her gegen die du rechnest?
So würde bei dir doch auch immer "vor einigen Sekunden" auftauchen, also wie kommt dein Flow dann bei den Geräten auf zb. "vor 30 Minuten"? -
@schmetterfliege Na wenn Du die jetzigen Zeitstempel immer speicherst - liegen die der anderen Geräte ja dann in der Vergangenheit
Du siehst doch, dass die unterschiedliche Zeitstempel haben - und die Diiferenz zu fromNow wird dann ausgegeben:
Schau Dir doch den Kontextspeicher an. In meinem Flow fState. Über das topic wird ja immer das richtige Gerät aktualisiert - du musst natürlich aufpassen, dass jedes Gerät ein unterschiedliches topic hat.
