@borio85
Hab mal die Scripte pausiert (kann ich ja jetzt löschen ) und den Adapter neu gestartet. Jetzt läuft es deutlich flüssiger und das Log wird auch nicht mehr vollgespammt.
Vielen Dank für deine Hilfe!!!
@borio85
Hab mal die Scripte pausiert (kann ich ja jetzt löschen ) und den Adapter neu gestartet. Jetzt läuft es deutlich flüssiger und das Log wird auch nicht mehr vollgespammt.
Vielen Dank für deine Hilfe!!!
In dem Github Issue hat @Asgothian erwähnt dass es gestern Abend wohl ein Update gab mit dem das Device nun supportet sein sollte.
Allerdings hatte ich ja leider diesen Issue "geklaut" und zu meinem gemacht - weil er Ersteller ein anderes Tuya Device hatte als ich (war mir nicht bewusst).
Deshalb bin ich jetzt nicht sicher ob Asgothian sich auf mein Device bezogen hat, oder das des Issuers.
Ich habe spaßeshalber einfach mal den Zigbee Adapter über Github geupdated (nicht neu installiert), und es damit probiert. Hatte aber leider das gleiche Ergebnis.
Aktuell warte ich daher auf Rückmeldung ob a) mein Device überhaupt gemeint war und b) eine Neuinstallation nötig ist oder ich schlicht das Update falsch gemacht habe.
@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
@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.
@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
aaaaaah okay, dann macht das natürlich Sinn!
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.
@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()
@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 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?
@mickym said in Zigbee2mqtt installation:
@schmetterfliege So geht es auch, wenn auch etwas umständlicher - aber eben nicht mehr mit Zeit usw.
Okay, da habe ich es lieber in der Change Node und spar mir den Split und komplizierten Join
Hab das den Kontext jetzt auch angepasst dass alles auf gleiche Art benannt ist usw.
Nur das LastUpdate muss ich jetzt halt noch hinbiegen.
Kontext war gelöscht, daher aktuell nur für 1 Sensor der Timestamp da - trotzdem wird bei allen Sensoren die aktuell "da" sind der Wert gleich gesetzt.