Zigbee2mqtt installation
-
Ich hoffe das wird jetzt nicht viiiel zu kompliziert was ich hier von mir gebe, muss aber glaube ich etwas ausholen zum Verständnis:
Der erste Kasten ist das Updaten der Tabelle.
Der zweite Kasten ist hinfällig, da hatte ich den Raum im Kontext gespeichert. Kommt weg, weil ist ja oben mit drin.
Der dritte Kasten ist das "initialisieren" der Tabelle, also der erste Aufbau nach einem Neustart.
Im Dritten hatte ich daher alle Zigbee Daten geholt, im Kontext gespeichert und die Tabelle anhand des Kontext aufgebaut.
Den dritten Teil kann ich ja prinzipiell jetzt genau so easy wie den ersten machen.Den Raum möchte ich ja nicht im Kontext speichern, weil der schon drin steht (die Objekte sind als Raum gespeichert, nicht mehr als zigbee-id). Deshalb kann ich den Raum auch erst nach dem Array in die Tabelle einfügen, weil ich dafür die Objekte aus dem Kontext brauche.
Fällt natürlich weg wenn ich den Raum vorher im Kontext speichere, das ist absolut klar. Aber wären halt redundante Daten :S -
@schmetterfliege Ich bin jetzt wieder mal zu faul - auch wenn ich Deinen Flow schon x Mal durchdacht habe - habe ich ja damals mit gearbeitet, aber:
- Du brauchst keine Prüfung auf irgendwelche IDs?
- Du brauchst keine Liste von Räumen
- Auch Gerätenamen halte ich für überflüssig - da der doch auch Bestandteil des topics ist.
Also die ganzen Topic Objekte zum extrahieren von diesen Informationen ist doch alles im topic enthalten. Und nochmal Du brauchst keine Objekte mehr auszulesen. Was willst Du denn initialisieren - über die Objekte musst Du ja auch nicht mehr Werte aus anderen Datenpunkten auslesen. Das ist doch gerade der Vorteil der Objekte.
Du kannst das ja alles behalten
- aber ich würde den Flow neu aufbauen. -
@mickym said in Zigbee2mqtt installation:
@schmetterfliege Ich bin jetzt wieder mal zu faul - auch wenn ich Deinen Flow schon x Mal durchdacht habe - habe ich ja damals mit gearbeitet, aber:
Bin grad ein wenig überfordert das zu kapieren^^
- Du brauchst keine Prüfung auf irgendwelche IDs?
Wie meinst das? IDs prüfe ich doch gar nicht? Glaube ich^^
- Du brauchst keine Liste von Räumen
Eine Liste von Räumen habe ich auch nicht mehr - den Raum ziehe ich mir ja aus der Topic jedes Objektes (im Flow-Kontext)
- Auch Gerätenamen halte ich für überflüssig - da der doch auch Bestandteil des topics ist.
Gerätenamen habe ich doch gar keine drin? In der Tabelle steht: Raum - Ort (falls es mehr als 1 im Raum gibt) - Temp - Humidity - Last Update
Also die ganzen Topic Objekte zum extrahieren von diesen Informationen ist doch alles im topic enthalten. Und nochmal Du brauchst keine Objekte mehr auszulesen. Was willst Du denn initialisieren - über die Objekte musst Du ja auch nicht mehr Werte aus anderen Datenpunkten auslesen. Das ist doch gerade der Vorteil der Objekte.
Du kannst das ja alles behalten
- aber ich würde den Flow neu aufbauen. Wieso muss ich keine Objekte auslesen? Den Teil verstehe ich nicht.
Ich bekomme vom IoB doch immer ganze Objekte, ich hole die Werte ja gar nicht mehr einzeln ausm IoB sondern nur das JSON.
Also ich glaube ich mache ja genau das was du da sagst^^
In meinem großen Screenshot mit den 3 Kästen: ich habe bisher nur den ersten angepasst. 2. und 3. sind noch alt, der zweite fällt komplett weg und der dritte wird genau so komprimiert wie der erste -
@schmetterfliege sagte in Zigbee2mqtt installation:
Ich bekomme vom IoB doch immer ganze Objekte, ich hole die Werte ja gar nicht mehr einzeln ausm IoB sondern nur das JSON.
Du liest doch in deiner iobroker-IN Node Objekte und keine Werte aus. Das Objekte auslesen war mit dem Zigbee-Adapter notwendig - aber doch jetzt nicht mehr.
Aussderdem fehlt meines Erachtens ein Punkt - zeig halt mal die Definition Deiner iobroker IN Node.
-
Du meinst statt Objekt auf Value ändern?
Das erste ist als Value, das zweite als Objekt.
Das meintest du, oder? -
Erstens ist Deine Wildcard verkehrt. Die ist nicht wie bei einem Dateinamen, sondern gilt für Hierarchieebenen.
Das Topic müsste in meinen Augen
mqtt.0.zigbee2mqtt.Multisensor.*lauten. Bei Dir fehlt der Punkt.
Ja und statt Objekt - benötigst Du doch nur noch den Value - das Objekt hast Du nur früher gebraucht, da Du common Attribute des Datenpunktes gebraucht hast, um den Raum zu mappen. -
@schmetterfliege Das Einzige - was ich nicht mehr im Kopf habe - ob Du irgendwie die Zeitstempel im Objekt gebraucht hast. Das war irgendwie zum Initialisieren, wann die letzte Änderung war. Also lass es auf Objekt.
Also von mir aus lass es als Objekt - da ich glaube Du initialisiert damit Deine Zeitstempel
-
Wie das bei den Zigbee Daten war weiß ich leider nicht mehr, und die Daten sind gelöscht, kann ich also nicht mehr anschauen.
Aber, das hier ist der output wenn ich das als Value auslese und den Punkt der fehlen soll noch nicht rein gemacht habe:
Timestamp ist auch bei Value dabei
Wenn der Punkt fehlt, wieso geht das dann trotzdem?
Edit: Sorry, in dem Screenshot ist nicht die originale ausgabe, sondern Topic angepasst an Raumname und das JSON bereits zerlegt
-
@schmetterfliege sagte in Zigbee2mqtt installation:
Wenn der Punkt fehlt, wieso geht das dann trotzdem?
Keine Ahnung.
- Also alles gelöst? -
@mickym said in Zigbee2mqtt installation:
@schmetterfliege sagte in Zigbee2mqtt installation:
Wenn der Punkt fehlt, wieso geht das dann trotzdem?
Keine Ahnung.
- Also alles gelöst?Jep - aber eine Frage noch.
Müsste ich mit der IN Node nicht auch den "Availability" Datenpunkt bekommen?
Weil nach * kann ja alles kommen.
Also nicht nur /Abstellkammer/Regal sondern auch /Abstellkammer/Regal/availability.
Wieso tut's das nicht?
Ich will den nicht - aber verstehe nicht wieso er nicht in NR ankommt^^ -
@schmetterfliege Vielleicht ist das das Problem ohne Punkt.
-
Nevermind... beim Updaten der Sensoren wird dieser Datenpunkt nicht geupdated.
Wie stelle ich am besten sicher dass dieser Datenpunkt nicht in der IN Node landet? bzw dass ich ihn danach verwerfe?Einfach ne Switchnode die die Topic anschaut und wenn da "availability" vorkommt verwerfen?
-
@schmetterfliege sagte in Zigbee2mqtt installation:
Einfach ne Switchnode die die Topic anschaut und wenn da "availability" vorkommt verwerfen?
Genau - ich mach Dir gerade so was.
-
@mickym
ist doch einfach nur das, oder?
Dachte vielleicht gibts ne Möglichkeit über eine Ausdruck in der IN Node schon das auszuschließen^^
-
Ist doch einfach nur das, oder?
Ja ist nur das - ich wollte dir nur eine Switch Node mit einem Ausgang basteln.
-
@mickym said in Zigbee2mqtt installation:
Ist doch einfach nur das, oder?
Ja ist nur das - ich wollte dir nur eine Switch Node mit einem Ausgang basteln.
Mit einem ? Da bin ich gespannt!
Eine "enthält nicht" Option whsl über Regex gelöst nehme ich an -
@schmetterfliege sagte in Zigbee2mqtt installation:
@mickym said in Zigbee2mqtt installation:
Ist doch einfach nur das, oder?
Ja ist nur das - ich wollte dir nur eine Switch Node mit einem Ausgang basteln.
Mit einem ? Da bin ich gespannt!
Eine "enthält nicht" Option whsl über Regex gelöst nehme ich anRichtig - mit RegEx.
$exists($match(topic,/.*availability$/)) -
@mickym said in Zigbee2mqtt installation:
$exists($match(topic,/.*availability$/))
Genial! vielen Dank
-
@schmetterfliege Wenn Du mqtt Nodes verwendest - in der mqtt Notation kann man die unteren Ebenen so ausschließen:
zigbee2mqtt/Multisensor/+/+ -
@mickym said in Zigbee2mqtt installation:
@schmetterfliege Wenn Du mqtt Nodes verwendest - in der mqtt Notation kann man die unteren Ebenen so ausschließen:
zigbee2mqtt/Multisensor/+/+
Hab ich tatsächlich als erstes so getestet. Kam dann aber drauf dass ich damit ja nicht bei einem NR Neustart initialisieren kann, sondern da aus IoB die Werte holen muss.
Und dann hab ich eben auch zum "Updaten" die IoB Daten genommen statt MQTT.
Aber ja, wäre whsl ein wenig eleganter so!
