Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[mickym]

@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.

[Schmetterfliege]

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.

[mickym]

@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

:rolling_on_the_floor_laughing: :rolling_on_the_floor_laughing: - 1970 sind ja schon 53 Jahre - wird ja aufgerundet - sind ja schon in der 2. Jahreshälfte. ;)

[Schmetterfliege]

@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

:rolling_on_the_floor_laughing: :rolling_on_the_floor_laughing: - 1970 sind ja schon 53 Jahre - wird ja aufgerundet - sind ja schon in der 2. Jahreshälfte. ;)

Exakt :grin:

[Schmetterfliege]

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.

[Schmetterfliege]

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

[mickym]

@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.

[mickym]

@schmetterfliege Hier mal der Core Flow von mir - ist ja kein Geheimnis:

Spoiler

[
   {
       "id": "753c1b7eb6df5805",
       "type": "function",
       "z": "c297780ec96fcd08",
       "name": "Zeitstempel in fState",
       "func": "flow.set ('fState.' + msg.topic, msg.payload);\nreturn msg;",
       "outputs": 1,
       "noerr": 0,
       "initialize": "",
       "finalize": "",
       "libs": [],
       "x": 700,
       "y": 520,
       "wires": [
           [
               "2a3f9c0bbc0ea013"
           ]
       ]
   },
   {
       "id": "abee507e5c1eb5bf",
       "type": "change",
       "z": "c297780ec96fcd08",
       "name": "",
       "rules": [
           {
               "t": "set",
               "p": "payload",
               "pt": "msg",
               "to": "$moment()\t",
               "tot": "jsonata"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 470,
       "y": 520,
       "wires": [
           [
               "753c1b7eb6df5805"
           ]
       ]
   },
   {
       "id": "2a3f9c0bbc0ea013",
       "type": "change",
       "z": "c297780ec96fcd08",
       "name": "",
       "rules": [
           {
               "t": "set",
               "p": "payload",
               "pt": "msg",
               "to": "fState",
               "tot": "flow"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 930,
       "y": 520,
       "wires": [
           [
               "c1c76a5e7c06c5d8"
           ]
       ]
   },
   {
       "id": "c1c76a5e7c06c5d8",
       "type": "split",
       "z": "c297780ec96fcd08",
       "name": "",
       "splt": "\\n",
       "spltType": "str",
       "arraySplt": 1,
       "arraySpltType": "len",
       "stream": false,
       "addname": "topic",
       "x": 1110,
       "y": 520,
       "wires": [
           [
               "cf60e787307a4d6f"
           ]
       ]
   },
   {
       "id": "cf60e787307a4d6f",
       "type": "change",
       "z": "c297780ec96fcd08",
       "name": "",
       "rules": [
           {
               "t": "set",
               "p": "payload",
               "pt": "msg",
               "to": "$moment(payload).locale('de').fromNow()",
               "tot": "jsonata"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 1280,
       "y": 520,
       "wires": [
           [
               "8d22e1665c558f9b"
           ]
       ]
   }
]

Die Zeitstempel werden in diesem Flow in fState gespeichert.

[Schmetterfliege]

@mickym

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 kommt :grin:

Oder habe ich da jetzt einen Denkfehler?

[mickym]

@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.

[Schmetterfliege]

@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"?

[mickym]

@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.

[Schmetterfliege]

@mickym

Okay, das heißt in deinem Flow setzt du für das aktuelle Gerät "manuell" den Zeitstempel auf JETZT.
Aber an welcher Stelle berechnest du dann für alle Geräte die aktuelle Differenz? Würde das in dem Flow nicht auch nur den Wert für das aktuelle Gerät berechnen?

[mickym]

@schmetterfliege Ja die function Node - setzt für das aktuelle Gerät den jetzigen Zeitstempel. In der nächsten Change Node - wird die ganze Flowvariable fState in die payload geladen - in einzelne Nachrichten via split aufgeteilt und für jedes Gerät mit der letzten Change Node und .fromNow() die Differenz des gespeicherten Zeitstempels zum Zeitpunkt JETZT berechnet und ausgegeben.

[Schmetterfliege]

aaaaaah, habs verstanden.
Nach der Function Node holst du dir alle Werte, splittest die dann und berechnest jeweils.

Sorry!

[mickym]

@schmetterfliege Der Kandidat hat 100 Punkte. :+1:

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.

[Schmetterfliege]

@mickym

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

[mickym]

@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

[Schmetterfliege]

@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:

Spoiler

[
    {
        "id": "7fe74e1c4f96ebec",
        "type": "change",
        "z": "1090acf7.2d6813",
        "name": "",
        "rules": [
            {
                "t": "set",
                "p": "payload",
                "pt": "msg",
                "to": "$moment(payload.timestamp).locale('de').fromNow()",
                "tot": "jsonata"
            }
        ],
        "action": "",
        "property": "",
        "from": "",
        "to": "",
        "reg": false,
        "x": 1450,
        "y": 1980,
        "wires": [
            [
                "a06c0fd115f037d5"
            ]
        ]
    },
    {
        "id": "a06c0fd115f037d5",
        "type": "function",
        "z": "1090acf7.2d6813",
        "name": "Zeitstempel in fState",
        "func": "flow.set ('zigbee.' + msg.topic + '.lastupdate', msg.payload);\nreturn msg;",
        "outputs": 1,
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 1660,
        "y": 1980,
        "wires": [
            []
        ]
    }
]

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 :grin:

[Schmetterfliege]

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^^