NEWS
Zigbee2mqtt installation
-
@mickym said in Zigbee2mqtt installation:
@schmetterfliege Aber Du kannst ja im vorfeld nach dem split 2 Wege einschlagen, bevor Du das wieder zusammensetzt. Du nutzt doch eine split und eine JOIN Node?
Du meinst dass ich nach dem Split schaue ob der Wert existiert und dann entsprechend berechne oder eben nicht berechne?
Naja, das würde in jedem Fall den Flow verkomplizieren, da lebe ich lieber damit dass ich kurz falsche Sachen drin stehen habe wenn aus irgendeinem Grund die Flowvariablen weg sind
@schmetterfliege Na schlimm ist das nicht - zeig mal den Ausschnitt des Flows und exportiere das mal.
-
@schmetterfliege Aber Du kannst ja im vorfeld nach dem split 2 Wege einschlagen, bevor Du das wieder zusammensetzt. Du nutzt doch eine split und eine JOIN Node?
Wie setzt Du denn die Eigenschaft im Objekt - wie lange es her ist?
@mickym said in Zigbee2mqtt installation:
@schmetterfliege Aber Du kannst ja im vorfeld nach dem split 2 Wege einschlagen, bevor Du das wieder zusammensetzt. Du nutzt doch eine split und eine JOIN Node?
Wie setzt Du denn die Eigenschaft im Objekt - wie lange es her ist?

Sensor liefert update -> gucken ob "availability" vorhanden ist weil ich den Teil nicht haben will -> Trigger -> Paar Variablen anpassen -> In Objekt umwandeln -> Name nach Payload verschieben -> alle Flowvariablen setzen.
Also in der Function Node wird alles was im Flow gespeichert wird gesetzt, also auch die Timestamps.
Entsprechend gibts den Wert halt erst, wenn ein Sensor ein Update liefert.@mickym said in Zigbee2mqtt installation:
@schmetterfliege Na schlimm ist das nicht - zeig mal den Ausschnitt des Flows und exportiere das mal.

Flowvariablen in Payload laden -> Split -> LastUpdate für jedes Objekt berechnen -> Join (automatisch, da das Array nun in der ui-control gesetzt wird.
Das "vor ein paar Sekunden" oder welche Zeit auch immer bei rum kommt speicher ich nicht im Flow, sondern übergebe es nur an die Tabelle.
Also LastUpdate wird dann für alle Objekte einzeln berechnet, die im Flowkontext gespeichert sind - weil ja der Kontext in den Payload geladen wird und dann gesplittet -
@mickym said in Zigbee2mqtt installation:
@schmetterfliege Aber Du kannst ja im vorfeld nach dem split 2 Wege einschlagen, bevor Du das wieder zusammensetzt. Du nutzt doch eine split und eine JOIN Node?
Wie setzt Du denn die Eigenschaft im Objekt - wie lange es her ist?

Sensor liefert update -> gucken ob "availability" vorhanden ist weil ich den Teil nicht haben will -> Trigger -> Paar Variablen anpassen -> In Objekt umwandeln -> Name nach Payload verschieben -> alle Flowvariablen setzen.
Also in der Function Node wird alles was im Flow gespeichert wird gesetzt, also auch die Timestamps.
Entsprechend gibts den Wert halt erst, wenn ein Sensor ein Update liefert.@mickym said in Zigbee2mqtt installation:
@schmetterfliege Na schlimm ist das nicht - zeig mal den Ausschnitt des Flows und exportiere das mal.

Flowvariablen in Payload laden -> Split -> LastUpdate für jedes Objekt berechnen -> Join (automatisch, da das Array nun in der ui-control gesetzt wird.
Das "vor ein paar Sekunden" oder welche Zeit auch immer bei rum kommt speicher ich nicht im Flow, sondern übergebe es nur an die Tabelle.
Also LastUpdate wird dann für alle Objekte einzeln berechnet, die im Flowkontext gespeichert sind - weil ja der Kontext in den Payload geladen wird und dann gesplittet -
@mickym said in Zigbee2mqtt installation:
@schmetterfliege Na nur der untere Teil interessiert im Moment.
Okay, hatte deine (erste) Frage falsch verstanden, my bad.
Hast recht, das ist deutlich kompakter als ich es mir vorgestellt habe - worth it
