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.
-
@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:
-
@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. -
@schmetterfliege Du kannst doch die Variablen so abspeichern - als Kombi zwischen Sensorname und Raum.
-
@mickym said in Zigbee2mqtt installation:
@schmetterfliege Du kannst doch die Variablen so abspeichern - als Kombi zwischen Sensorname und Raum.
Done.
-
Bleibt die Frage, was payload.id sein soll.
Übergeben wird jedenfalls kein payload.id an die Change Node.
Nur ein parts.idWo finde ich denn das, was payload.id sein soll? In den Flowvariablen steht das auch nicht.
Oder sind das hier die "IDs"?
-
@schmetterfliege Schau halt mal mit einer Debug Node nach der split Node?
-
@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? -
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 -.-
-
@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.
-
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-
-
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? -
@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.
-
@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. -
@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 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.
-
@mickym said in Zigbee2mqtt installation:
@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.
Das ist schon richtig, nur lese ich ja nirgends das gesamte zigbee2mqtt Objekt aus, sondern die einzelnen Sensoren.
Und da bekomme ich dann auch nur die Werte von denen.
Das initialisieren hatte ich damals so gemacht:
Nur eben für zigbee.*.
Damit hatte ich vorhin versucht das Initialiseren in der Tabelle wieder einzubauen, was aber nicht funktioniert hatte.
Zumindest bekomme ich in der Debug Node keinerlei Output wenn ich das triggere.
Deshalb: Keine Ahnung wieso da dann plötzlich wieder alle Sensoren im Flow gespeichert sind, obwohl die meisten bisher noch kein Update geliefert haben seit ich vor mittlerweile fast einer Stunde NR neu gestartet habe.
Aber, das ist auch aktuell gar nicht mein ProblemAktuell folgende 2 Themen:
- LastUpdate wird nicht richtig berechnet.
- Meine Tabelle ist weiß Gott warum leer und ich komme da ums verrecken nicht dahinter was das Problem ist.
Es wird alles richtig übergeben, und die Änderung die das kaputt gemacht hat wieder rückgängig gemacht wurden.
Aber bevor ich das in Angriff nehme, würde ich halt gerne die Change Node die das LastUpdate berechnet dazu bringen richtig zu funktionieren - hat mit der Tabelle ja jetzt eh erst mal nichts zu tun
-
@schmetterfliege Na ja ich hatte Dir aber auch gesagt, dass ich das auslesen nicht brauche, weil ich die Initialisierung am Anfang verzichte. Mir langt es wenn ich sehe, wie sich die werte füllen. Das wolltest Du aber nicht.
Fehlt da nicht ein Punkt hinter Multisensor?
-
@mickym said in Zigbee2mqtt installation:
@schmetterfliege Na ja ich hatte Dir aber auch gesagt, dass ich das auslesen nicht brauche, weil ich die Initialisierung am Anfang verzichte. Mir langt es wenn ich sehe, wie sich die werte füllen. Das wolltest Du aber nicht.
Fehlt da nicht ein Punkt hinter Multisensor?
Wie gesagt, das initialisieren habe ich ja auch nicht mehr drin. Eben mit der Konsequenz dass die Werte erst mal alle weg sind wenn ich den Flowkontext mal lösche. Dass die Werte gefehlt haben, war ja aber auch gar nicht mein Problem, sondern die beiden erwähnten Themen
Selbst wenn ich den Punkt da hin mache, hatte ich keinerlei Output. Aber is ja auch egal, weil ich eh nicht mehr initialisiere
Und: dort fehlt der Punkt auch und Updates der Sensoren kommen trotzdem rein^^
-
Mal ganz blöd gefragt...
kannst du mal schauen ob bei dir die Tabelle damit funktioniert? Also Werte hat?Nodes:
Werte:
