Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[mickym]

@schmetterfliege Also ist noch die Version die ich geschickt habe - bei mir funktioniert das ohne Probleme -

So hier die optimierte Version:

Spoiler

[
   {
       "id": "7b5bb841bf8e240c",
       "type": "change",
       "z": "0b2773fbdc77eea3",
       "name": "",
       "rules": [
           {
               "t": "set",
               "p": "payload.timestamp",
               "pt": "msg",
               "to": "$lookup($flowContext(\"timestamps\"), payload.id).timestamp",
               "tot": "jsonata"
           },
           {
               "t": "set",
               "p": "payload.lastupdate",
               "pt": "msg",
               "to": "$moment(payload.timestamp).fromNow()",
               "tot": "jsonata"
           },
           {
               "t": "set",
               "p": "payload.timestamp",
               "pt": "msg",
               "to": "$moment(payload.timestamp).format(\"DD.MM.YYYY HH:mm:ss\")\t",
               "tot": "jsonata"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 710,
       "y": 620,
       "wires": [
           [
               "584c0e94d5c2de86"
           ]
       ]
   }
]

Anstelle mehrfach den Kontext einzulesen - wird der timestamp nur einmal eingelesen und dann entweder formatiert oder die Differenz berechnet:

Das locale("de") habe ich in der Change Node vergessen - musst halt noch nachtragen.

Finde es nachwievor zwar überflüssig ts und die Zeitdifferenz zu berechnen.

[Schmetterfliege]

hmm.

An welcher Stelle wird denn bei dir das LastUpdate dann in das Zigbee Objekt geladen? In der Change Node sehe ich das jedenfalls nicht

[mickym]

@schmetterfliege doch in der 2. Regel.

[mickym]

@schmetterfliege Das steht auch nicht in der zigbee Kontext variable - schau doch ins Debug fenster - was da rauskommt. Mach mal hinter die JOIN Node eine Debug Node und poste die.Die zigbee Flow- Kontext wird nicht modifiziert.

[Schmetterfliege]

@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:

@schmetterfliege Das steht auch nicht in der zigbee Kontext variable - schau doch ins Debug fenster - was da rauskommt. Mach mal hinter die JOIN Node eine Debug Node und poste die.Die zigbee Flow- Kontext wird nicht modifiziert.

Okay, ich bin davon ausgegangen dass das da drin landet weil du das vorher selbst geschrieben hast :grinning:
In der Tabelle sehe ich in der Tat die Zeitdifferenzen. Funktioniert also! :)

[mickym]

@schmetterfliege Ok mit den Zigbee Objekten habe ich die gemeint, die in die Table Node kommen. ;)

[Schmetterfliege]

Also ja, du übergibst das in das Objekt das im Flow übergeben wird.
Ich dachte aber mit Objekt meinst du das Zigbee Objekt in den Kontextvariablen :grin:
Sorry!

[mickym]

@schmetterfliege Na egal - somit sollte Dein Problem jedenfalls gelöst sein.

[Schmetterfliege]

Vielen Dank für die Lösung meines Problems! :)

Was meinst du btw. damit dass du es für überflüssig hältst ts und die Zeitdifferenz zu berechnen?
Die TS habe ich ja nur damit ich die Differenzen berechnen kann.
Und die Differenzen möchte ich um innerhalb der Tabelle direkt sehen zu können ob alle Sensoren regelmäßig Daten liefern, oder ob da einer nicht mehr funktioniert - ohne im IoB im Zigbee Adapter nachschauen zu müssen

[mickym]

@schmetterfliege Ja in der Tabelle die Differenzen - aber dann brauchst den Timestamp nicht mehr.

Ein Zeitstempel in der Tabelle

und dann ist 27 Minuten her - finde ich halt redundant.

Im Prinzip im Objekt ist es egal - aber ich würde es halt in der Tabelle nicht mehr anzeigen.

[Schmetterfliege]

@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:

@schmetterfliege Ja in der Tabelle die Differenzen - aber dann brauchst den Timestamp nicht mehr.

Ein Zeitstempel in der Tabelle

und dann ist 27 Minuten her - finde ich halt redundant.

achsooooo!

Die Timestamps zeige ich da ja nicht mehr an :D

[mickym]

@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:

Die Timestamps zeige ich da ja nicht mehr an

Ah OK - :) - Dann macht das Sinn. :+1:

[mickym]

@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:

Die Timestamps zeige ich da ja nicht mehr an

Dann kannst auch die letzte Regel rausschmeissen, die den Unix Timestamp formatiert:

[Schmetterfliege]

stimmt :)

[mickym]

@schmetterfliege bzw. die Change NOde ganz vereinfachen und den timestamp aus dem Objekt entfernen. ;)

Spoiler

[
   {
       "id": "7b5bb841bf8e240c",
       "type": "change",
       "z": "0b2773fbdc77eea3",
       "name": "",
       "rules": [
           {
               "t": "set",
               "p": "payload.lastupdate",
               "pt": "msg",
               "to": "$moment($lookup($flowContext(\"timestamps\"), payload.id).timestamp).locale(\"de\").fromNow()",
               "tot": "jsonata"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 750,
       "y": 620,
       "wires": [
           [
               "584c0e94d5c2de86"
           ]
       ]
   }
]

[Schmetterfliege]

@mickym
Funktioniert :)
Sorry dass ich dir durch meine Undeutlichkeit die ganze Arbeit mit dem Optimieren gemacht habe, und jetzt alles wieder rausfällt :S

[mickym]

@schmetterfliege Na ja - im Prinzip hätte ich halt in der Timestamps variable - den ts nicht in ein Objekt sondern direkt gespeichert - das hat es dann halt noch bissi komplexer gemacht als nötig. Aber nun funktioniert es ja auch so. ;)

In diesem Fall siehst ist es aber alles halb so kompliziert und es wird über eine Regel in einer Change Node das erreicht, was Du vorher mit dem ganzen Flow machen wolltest.

Ich würde mir allerdings schon Sorgen machen, wenn sich die Geräte 4 Monate nicht mehr gemeldet haben.

[Schmetterfliege]

@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:

@schmetterfliege Na ja - im Prinzip hätte ich halt in der Timestamps variable - den ts nicht in ein Objekt sondern direkt gespeichert - das hat es dann halt noch bissi komplexer gemacht als nötig. Aber nun funktioniert es ja auch so. ;)

In diesem Fall siehst ist es aber alles halb so kompliziert und es wird über eine Regel in einer Change Node das erreicht, was Du vorher mit dem ganzen Flow machen wolltest.

Ich würde mir allerdings schon Sorgen machen, wenn sich die Geräte 4 Monate nicht mehr gemeldet haben.

Die Geräte die seit 4 Monaten keine Meldung mehr haben sind seit dem ersten Umzug vor 4 Monaten noch nicht wieder im Einsatz. Das sind die Sensoren die ich an die Heizkörperthermostate klebe.
Mal schauen wie lange ich die Heizungen noch aus lassen kann :grinning:
Der aus dem Flur2 hat aber ne Macke. Vermute einen HW Defekt, wenn ich den Resette und neu Verbinde geht es kurz, und dann wieder nicht. Wenn ich den per Knopfdruck physikalisch triggere, blinkt er nur ein mal statt 3 mal (was ein Senden von Daten zeigen würde). Den muss ich wahrscheinlich austauschen.
Aber genau für sowas habe ich ja diese Werte in der Tabelle haben wollen :D

[mickym]

@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:

Mal schauen wie lange ich die Heizungen noch aus lassen kann

Na dann wünsche ich Dir bei Deinem Survival - Trip viel Spass. :grin: - Zum Glück werden die Winter ja immer wärmer. ;) - Ich werde da wohl lieber auf andere Dinge verzichten. ;) -

[Schmetterfliege]

@mickym
Na noch hab ich überall 21-23 Grad in der Bude :grinning:
Spätestens wenn die Temperaturen hier drin anfangen unter 20 Grad zu gehen, muss ich wohl in den sauren Apfel beißen^^
Die Tado Thermostate hab ich gestern schon montiert. Nur eben die Sensoren die ich zusätzlich da dran möchte noch nicht, weil die Heizungen aktuell sowieso noch aus bleiben :)