Zigbee2mqtt installation

[Schmetterfliege]

@mickym
Na das traurige ist ja dass ich in der IT arbeite (wenn auch relativ speziell) und den Glauben an mich selbst verlieren muss

[Schmetterfliege]

Bei dem Teil wo ich das LastUpdate setze müsste ich auch nochmal was ändern.

Zwar splitte ich alles auf bevor ich das LastUpdate setze, aber der macht das scheinbar anhand der Topic, die bei allen aber gleich ist, und zwar die Topic von dem Sensor, der den Flow gerade getriggert hat.

Ich meine, diese Change Node hätten wir zusammen gemacht (also du hast sie mir vorbereitet und ich habe sie kopiert )
Die Timestamps im Flow sind definitiv unterschiedlich:

In der Change Node, das "payload.id" das da drin steht - was genau ist payload.id?
Aktuell sieht es mir danach aus dass payload.id == msg.topic ist, und er daher für alle Sensoren immer nur den einen Wert nimmt (zb Flur_1 wenn der Sensor gerade geupdated hat).
Wie muss ich das denn umbiegen dass er bei Büro auch Büro nutzt, Wohnzimmer dann Wohnzimmer usw?

[Schmetterfliege]

@mickym
Nachtrag:
Hab im Flow die Timestamps schon mal angepasst:

Weil in manchen Räumen mehrere Sensoren sind mit unterschiedlichen Namen.
D.h. ich möchte das LastUpdate auch nicht über den Raum setzen, sondern den jeweiligen Sensor.
Der dann im Flow eben wie im Screenshot abgespeichert ist.

[mickym]

@schmetterfliege In der payload.id muss genau "Wohnzimmer", "Büro" etc. stehen. Mach halt eine debug Node hinter die split Node.

[mickym]

@schmetterfliege Das ist Käse. Was soll denn moments mit einem Objekt anfangen. Dann ändere die das statt Büro halt andere Variablen abgespeichert werden.

[Schmetterfliege]

@mickym said in Zigbee2mqtt installation:

@schmetterfliege In der payload.id muss genau "Wohnzimmer", "Büro" etc. stehen. Mach halt eine debug Node hinter die split Node.

Na das ist ja das Problem:

Es gibt kein payload.id.
Und msg.topic ist wie gesagt bei allen gleich, je nachdem welcher Sensor grade das Update liefert:

[Schmetterfliege]

@mickym said in Zigbee2mqtt installation:

@schmetterfliege Das ist Käse. Was soll denn moments mit einem Objekt anfangen. Dann ändere die das statt Büro halt andere Variablen abgespeichert werden.

Okay, das kann ich natürlich machen.
Muss dann halt schauen dass ich niemals Sensoren habe die den gleichen Namen haben^^
Das hätte ich halt umgangen indem ich vorher auf Räume auftrenne.

[mickym]

@schmetterfliege Du kannst doch die Variablen so abspeichern - als Kombi zwischen Sensorname und Raum.

[Schmetterfliege]

@mickym said in Zigbee2mqtt installation:

@schmetterfliege Du kannst doch die Variablen so abspeichern - als Kombi zwischen Sensorname und Raum.

Done.

[Schmetterfliege]

Bleibt die Frage, was payload.id sein soll.

Übergeben wird jedenfalls kein payload.id an die Change Node.
Nur ein parts.id

Wo finde ich denn das, was payload.id sein soll? In den Flowvariablen steht das auch nicht.
Oder sind das hier die "IDs"?

[mickym]

@schmetterfliege Schau halt mal mit einer Debug Node nach der split Node?

[Schmetterfliege]

@mickym Der Debug aus dem Screenshot ist nach der Split Node

Was ich halt machen könnte, wäre msg.topic auf die entsprechenden Werte zu setzen wie sie in timestamps im Flow stehen.
Also zb. Büro/Besta.

Und dann in der Change node payload.id durch msg.topic ersetzen.
Würde das funktionieren?

[Schmetterfliege]

jetzt is diese dämliche Tabelle wieder leer und bleibt leer obwohl ich die Änderungen rückgängig gemacht habe und die Tabelle definitiv die Objekte bekommt -.-

[mickym]

@schmetterfliege Na wenn es jetzt nicht funktioniert - dann klar. Ich frag mich nur, warum das alles mal funktioniert hat und wir hier nur wieder alles neu machen müssen. Die Dinge hängen halt alle zusammen und ich habe keine Ahnung was geändert wurde. Meines Erachtens haben wir sicher irgendwo die id gesetzt - aber ich habe jetzt sorry keine Ahnung mehr. Ich kann auch nicht alle Flows hier immer bei mir abgespeichert halten, die ich mal zusammen entwickelt habe.

Natürlich musst dann halt wieder neu machen und halt verstehen, was in der ChangeNode gemacht wird.

Aus dem Objekt wird mithilfe von $lookup aus dem Objekt timestamps der Wert des Keys ermittelt. Den Key haben wir mit payload.id mitgegeben gehabt. Das topic entspricht doch nicht den Namen der Objekte in timestamps. Setze halt so wie Du es jetzt abgespeichert hast, die payload.id entsprechend, wie Du sie im Kontext abspeicherst. Die muss ja Bestandteil des Objektes sein, damit die nachdem split verfügbar ist.

Bei solchen Dingen würde ich mir halt den Flow von damals importieren (kann den ja insgesamt deaktivieren) und dort dann suchen, wo die id im Objekt gesetzt wurde.

[mickym]

Die Funktionsweise ist so, dass egal was reinkommt alle Zeitstempel abgeglichen werden mit dem aktuellen Zeitpunkt und dann ja Bestandteil des objektes sein müssen. Die id ist normalerweise implizit in der Table gesetzt. Um die aber bewusst setzen zu können und die Zeilen identifizieren zu können, bin ich überzeugt, dass wir die irgendwo gesetzt haben. Aber wie gesagt - das musst selbst suchen-

[Schmetterfliege]

Meine mich auch dunkel dran zu erinnern dass wir die gesetzt hatten, weiß aber selbst nicht mehr wo genau, und wieso ich das dann scheinbar wieder entfernt hatte.
Ich setze payload.id jetzt jedenfalls nach dem zersplitten für die Objekte, der Teil sollte also passen:

Jedes Objekt hat jetzt eine ID drin, und auch das LastUpdate.
Der Wert für LastUpdate ist halt trotzdem noch falsch.

Das ist aktuell im Flow gespeichert, da haben nämlich noch gar nicht alle Objekte einen Timestamp, weil die noch kein Update gesendet haben seit ich vorhin NR neu gestartet habe.

Kleines Bad hat aber zb auch drin stehen "vor ein paar Sekunden", obwohl er das gar nicht hätte berechnen können wenn gar kein Timestamp dafür existiert.
Die Change Node macht also trotzdem noch was falsch, obwohl ich nun payload.id übergebe.
Müsste da nicht eher "msg.payload.id" stehen? Oder darf das "msg." fehlen?

[mickym]

@schmetterfliege Nein in JSONATA ist das msg - Objekt implizit gemeint. Ist anders als bei JS.
War das nicht so, dass Du alle timestamps irgendwo ausgelesen hast und dann in der Kontextvariable abgespeichert hast. das ist doch unabhängig von aktuellen Ereignissen.

Importier Dir halt den Flow, den Du noch vor 2 Monaten hattest. Vielleicht wäre es gut - generell auf dem nochmal aufzusetzen.

[Schmetterfliege]

@mickym said in Zigbee2mqtt installation:

@schmetterfliege Nein in JSONATA ist das msg - Objekt implizit gemeint. Ist anders als bei JS.
War das nicht so, dass Du alle timestamps irgendwo ausgelesen hast und dann in der Kontextvariable abgespeichert hast. das ist doch unabhängig von aktuellen Ereignissen.

Importier Dir halt den Flow, den Du noch vor 2 Monaten hattest. Vielleicht wäre es gut - generell auf dem nochmal aufzusetzen.

ah okay
Würde das kaputt gehen wenn ich in JSONATA trotzdem msg. dran hänge? Würde es DAUs wie mir einfacher machen es einfach überall zu machen^^.

Dass ich alles ein mal auslese war gaaaanz früher so, als ich die Tabelle noch initialisiert habe anfangs.
Seit ich den Zigbee Adapter nicht mehr benutze, mache ich das allerdings nicht mehr - daher fehlen die Timestamps solange bis die Geräte ein Update senden.

Frag mich nicht was ich gemacht habe, aber grade sind wieder alle timestamps da (hatte versuch das Initialisieren wieder einzubauen, was aber eigentlich nicht geklappt hat und.. keine Ahnung.. egal).

Ich bin zwar in Mathe noch deutlich schlechter als in dem allem was wir hier machen, aber ich würde behaupten die Timestamps sind nicht nur ein paar Sekunden auseinander.
Und dennoch bekomme alle Objekte am Ende "vor ein paar Sekunden" reingeklatscht.

Das war definitiv auch schon vor 2 Monaten so kaputt.
Das letzte mal dass das richtig funktioniert hat mit den Timestamps war vor dem gesamtem Re-Work der Tabelle, also in dem Zustand Anfang des Jahres vor meinen 2 Umzügen^^
EDIT:
Das hab ich vor 2 Monaten bloß nicht bemerkt, weil ich da alle Sensoren neu angelernt habe wegen dem Umstieg zu Zigbee2MQTT und daher davon ausgegangen bin dass die wirklich alle grade erst updates gesendet hatten.
Bzw. ich mich schon drüber gefreut habe dass das jetzt überhaupt wieder in der Tabelle steht und dann nicht weiter dran geblieben bin.

[mickym]

@schmetterfliege sagte in Zigbee2mqtt installation:

ah okay
Würde das kaputt gehen wenn ich in JSONATA trotzdem msg. dran hänge? Würde es DAUs wie mir einfacher machen es einfach überall zu machen^^.

Nein - dann bekommst Du Warnmeldungen - mach es einfach nicht.

Na diese ChangeNode - dass nur bei Bedarf die Zeitspanne mithilfe der Change Node gemacht haben - ist definitiv erst in diesem Jahr gewesen. Das dumme ist, dass der Thread inzwischen so lange ist. da ist das ganze zigbee2mqtt mit drin.

[mickym]

@mickym Und wenn das halt anders ist und du die zigbee2mqtt später hast, dann hast Du doch mit zigbee2mqtt alles in dem JSON drin. da ist doch der timestamp mit enthalten.

Vielleicht findest ja noch die Stelle, wo wir das mit den Zeitstempeln diskutiert haben. Ansonsten ist es vielleicht wirklich sinnvoller kleinere Threads zu machen.