UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Schmetterfliege]

@mickym said in Zigbee2mqtt installation:

@schmetterfliege Überprüfe Deine Kabel mal - vielleicht sind die zu eng zusammen und Du bypassed . ;) Sprich die CHange Node ist gar nicht mit der function Node verbunden. ;) - Wahrscheinlich ist die function Node direkt mit dem Vorgänger verbunden und Du hast die nicht richtig eingeüftg.

omfg.... ich spring aus'm Fenster....

[mickym]

@mickym

@schmetterfliege sagte in Zigbee2mqtt installation:

@mickym said in Zigbee2mqtt installation:

@schmetterfliege Überprüfe Deine Kabel mal - vielleicht sind die zu eng zusammen und Du bypassed . ;) Sprich die CHange Node ist gar nicht mit der function Node verbunden. ;) - Wahrscheinlich ist die function Node direkt mit dem Vorgänger verbunden und Du hast die nicht richtig eingeüftg.

omfg.... ich spring aus'm Fenster....

Genau das habe ich vermutet. ;)

[Schmetterfliege]

so hart wie ich grad gern den Kopf schütteln würde, würde wahrscheinlich mein Genick brechen...
Danke dir - und sorry

[mickym]

@schmetterfliege sagte in Zigbee2mqtt installation:

so hart wie ich grad gern den Kopf schütteln würde, würde wahrscheinlich mein Genick brechen...
Danke dir - und sorry

Na zum Glück - muss ich nicht den Glauben an die IT verlieren. Ich hatte mal einen Kollegen der meinte bei solchen Phänomen immer: "Es gibt Dinge zwischen Himmel und Erde ... "
und ich habe mich immer geweigert so was zu akzeptieren. Das würde jedes IT-System in den Bereich des Esoterischen verschieben. ;)

[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 :grin:

[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 :grin: )
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?