NEWS
Zigbee2mqtt installation
-
@schmetterfliege Dann musst halt step für Step schauen - Du musst das ganze ja machen bevor du die table Node speist.
Also das Array auftrennen und in jedes Objekt die Differenz eintragen. Geh halt Schritt für Schritt vor. Die Tabelle interessiert doch erst mal nicht. Es interessiert nur das Array, das Du in die Tabelle speist.
Sprich wird der richtige Wert aus dem Kontext geholt und dann die Differenz richtig berechnet. Musst halt Step für Step machen.
-
@mickym said in Zigbee2mqtt installation:
@schmetterfliege Dann musst halt step für Step schauen - Du musst das ganze ja machen bevor du die table Node speist.
Also das Array auftrennen und in jedes Objekt die Differenz eintragen. Geh halt Schritt für Schritt vor. Die Tabelle interessiert doch erst mal nicht. Es interessiert nur das Array, das Du in die Tabelle speist.
Sprich wird der richtige Wert aus dem Kontext geholt und dann die Differenz richtig berechnet. Musst halt Step für Step machen.
Genau das ist mein Problem - ich weiß ja nicht was sich die ChangeNode aus dem Kontext holt^^
"topic" entspricht hier jeweils diesen Strings:
Da übergibt auch jedes Objekt der Change Node den richtigen Wert.
Ist das Problem dass die Timestamps jeweils direkt unter dem Namen gespeichert sind, und es kein "timestamp" unter jedem Objekt gibt? -
@schmetterfliege sagte in Zigbee2mqtt installation:
Ist das Problem dass die Timestamps jeweils direkt unter dem Namen gespeichert sind, und es kein "timestamp" unter jedem Objekt gibt?
Klar das ist es, mach einfach mal das .timestamp hinter der Klammer raus.
Genau das ist mein Problem - ich weiß ja nicht was sich die ChangeNode aus dem Kontext holt^^
Warum weisst Du das nicht. - Du sollst ja den Flow selbst verstehen.
Es gibt den Wert aus, den topic ausgibt. Wahrscheinlich musst Du noch ein x für das Eingabeformat für den Moment eingeben.
-
@mickym said in Zigbee2mqtt installation:
@schmetterfliege sagte in Zigbee2mqtt installation:
Ist das Problem dass die Timestamps jeweils direkt unter dem Namen gespeichert sind, und es kein "timestamp" unter jedem Objekt gibt?
Klar das ist es, mach einfach mal das .timestamp hinter der Klammer raus.
Warum weisst Du das nicht.
Es gibt den Wert aus, den topic ausgibt.
Das ist mir an sich schon klar, mich macht nur fertig dass überall wo es noch keinen Timestamp gibt trotzdem "vor ein paar Sekunden" drin steht
Das dürfte doch eigentlich gar nicht, ich meine so wie ich es hatte (also dass noch .timestamp drin stand) hätte das Teil ja mit nem String gerechnet. Da würde ich eine Fehlermeldung erwarten, und nicht dass er dann einfach sagt "joa, dann mach ich da halt jetzt draus" ^^Geht jetzt jedenfalls und er ersetzt langsam die Werte für Sensoren die Updates liefern.
-
@mickym Nochmal ich glaube der Moment wird nicht richtig gesetzt.Mach mal hinter der topic Klammer noch ein Komma und ein 'x' als Eingabeformat.
Falls Du das nicht verstehst - dann poste es einfach nochmal was jetzt drin steht in CodeTags - habe keine Lust Screenshots abzuschreiben.
-
@mickym said in Zigbee2mqtt installation:
@mickym Nochmal ich glaube der Moment wird nicht richtig gesetzt.Mach mal hinter der topic Klammer noch ein Komma und ein 'x' als Eingabeformat.
Falls Du das nicht verstehst - dann poste es einfach nochmal was jetzt drin steht in CodeTags - habe keine Lust Screenshots abzuschreiben.
Was meinst du denn mit "der Moment"?
EDIT: vergiss die Frage... glaube ich^^$moment($lookup($flowContext("timestamps"), topic)).locale("de").fromNow()
-
@schmetterfliege sagte in Zigbee2mqtt installation:
$moment($lookup($flowContext("timestamps"), topic)).locale("de").fromNow()
Na Du erstellst doch Momente mit $moment().
Das ist eine mächtige Bibliothek. Ich dachte das hättest Du Dir mal angeschaut.
Also erstes geht man halt so vor, dass man erst mal schaut ob die timestamps richtig rauskommen, bevor du mit trial&error rumfuhrwerkst.
$lookup($flowContext("timestamps"), topic)
Das heißt, wenn die timestamps nun korrekt rauskommen, dann ändere ich das Eingabeformat.
$moment($lookup($flowContext("timestamps"), topic),'x').locale("de").fromNow()
Mit dem kleinen x - zeige ich der Momentbibliothek, dass sie Unix timestamps in ms zum Fressen bekommt.
-
Na dass die richtigen Werte (zumindest jetzt nachdem .timestamps raus ist) kommen weiß ich ja, da er die Tabelle nach und nach mit den echten Zeitdifferenzen füllt.
Wenn ich nun eine Topic übergebe, die es nicht gibt, bekomme ich "undefined" raus.
"Test" gibt es im Flow nicht, "Büro/Besta" schon.
Daher würde ich erwarten dass in der eigentlichen Change Node dann auch "undefined" raus kommt und in der Tabelle entsprechend undefined drin steht - statt "vor ein paar Sekunden"?
EDIT: also für die Sensoren die im Flow noch keinen Timestamp hatten, und daher unter "timestamps" eben auch noch nicht existieren. -
@schmetterfliege sagte in Zigbee2mqtt installation:
Daher würde ich erwarten dass in der eigentlichen Change Node dann auch "undefined" raus kommt und in der Tabelle entsprechend undefined drin steht - statt "vor ein paar Sekunden"?
Nein dann ignoriert die moments Bibliothek den gesamten Inhalt.
und $moments() gibt immer den aktuellen Zeitpunkt aus.
-
aaaaaah okay, dann macht das natürlich Sinn!
-
@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?
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.
-
@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 -
@schmetterfliege Na nur der untere Teil interessiert im Moment.
-
@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