Zigbee2mqtt installation

[Schmetterfliege]

@mickym said in Zigbee2mqtt installation:

@schmetterfliege

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

[mickym]

@schmetterfliege sagte in Zigbee2mqtt installation:

@mickym said in Zigbee2mqtt installation:

@schmetterfliege

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

Richtig - mit RegEx.

$exists($match(topic,/.*availability$/))

[Schmetterfliege]

@mickym said in Zigbee2mqtt installation:

$exists($match(topic,/.*availability$/))

Genial! vielen Dank

[mickym]

@schmetterfliege Wenn Du mqtt Nodes verwendest - in der mqtt Notation kann man die unteren Ebenen so ausschließen:

zigbee2mqtt/Multisensor/+/+

[Schmetterfliege]

@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!

[mickym]

@schmetterfliege Gut zum Initialisieren ist iob besser.

[Schmetterfliege]

Ich wollte mir mal ne Tabelle basteln um mir den Onlinestatus der Zigbee Devices anzeigen zu lassen.
Ich hab da versehentlich was echt geiles gemacht glaube ich:

Alle Datenpunkte initialisieren mit .availability.
In der Change Node wird nur die Topic angepasst damit das mqtt.0.zigbee2mqtt nicht mehr drin steht und am ende ".availability" abgeschnitten.

In der Function Node schreibe ich dann den Status in den Flow Kontext.
Ich hätte jetzt eigentlich erwartet dass da sowas rauskommt wie:
Availability

• Sp15.Schlafzimmer.Eingang
• Status: Online
• Multisensor.Büro.Besta
• Status: Online
  usw.
  Aber da kam das raus:
  
  Also irgendwie perfekt alles im Kontext, sortiert nach Gerätetyp, Raum und dann - wenn vorhanden - Ort.
  Keine Ahnung wieso das so da raus kommt, aber es ist Hammer.
  Nur... wie addressiere ich im weiteren nun die einzelnen "Kategorien"?
  Mit sowas wie [0], [1] wenn ich zb. die Gerätetypen haben will? (Also 0 = Heizungsthermostat, 1 = Kontaktsensor, usw)
  Bei der anderen Tabelle hab ichs ja leider nicht geschafft diese "Werte" aus dem Kontext zu verwenden (sondern musste ja den Raum separat in den Payload packen nach der Join Node.
  Das dürfte hier aber nicht so easy funktionieren weil es je nach Gerätetyp mehr oder weniger "Ebenen" gibt (Thermostate haben zb nur den Raum, keinen Ort)

Splitten geht hier ja nicht weil es Kategorien und Unterkategorien gibt, ein Split würde mir ja das ganze Ding dann kaputt machen

[mickym]

@schmetterfliege Na ja deswegen hab ich ja auch den availabilty Punkt- Solche Dinge stehen aber in der Beschreibung:

Das dürfte hier aber nicht so easy funktionieren weil es je nach Gerätetyp mehr oder weniger "Ebenen" gibt (Thermostate haben zb nur den Raum, keinen Ort)

Aber bei Deinen Gerätetypen sind doch immer die erste Ebene - wo ist da das Problem? (Egal wieviele Ebenen darunter sind?)

[Schmetterfliege]

@mickym

Ich glaube mit etwas rumprobieren sollte ich das hinbekommen.
Nachdem der Kontext in den Payload geladen wird, sieht das so aus:

Damit kann man also schon mal arbeiten und schritt für schritt splitten.

In der Tabelle soll ja nicht nur der Gerätetyp stehen, sondern auch der Raum und wenn vorhanden der Ort.
Und da bin ich halt unsicher wie das geht wenn es verschiedene "Ebenen" gibt, als wenn pro Gerät Raum und Ort jeweils eigene Werte sind die direkt da drunter stehen - statt verschachtelt in Ebenen

EDIT:

So sieht es nach dem ersten Splitt aus. Wird also erstmal nach Typen gesplittet.
Dann whsl einfach eine switch node die die Gerätetypen kennt (kommt ja per Topic rein) und dann je nach Typ noch 1 oder 2 Split Nodes - den Aufbau der einzelnen Typen kenne ich ja.

[mickym]

@schmetterfliege Verstehe ich alles nicht. Mach mal praktisches Beispiel

1. Ebene ist doch immer Gerätetyp
2. Ebene Raum
3. Ebene ist Ort oder availability

[Schmetterfliege]

Vielleicht wird es so klarer wo mein Denkproblem ist:

Die Tabelle füttere ich ja mit dem gesamten Kontext.
Wie ich zb den status in die Tabelle packe weiß ich.

Mein Problem: Ich weiß nicht wie ich in der Definition der Tabelle die "Ebenen" einfüge.
Also Büro, Großes_Bad, Küche, etc.
status ist ja klar weil das ein Value ist.
Das andere sind aber Objekte. Wie komme ich an den "Namen" eines Objekts?

In der Tabelle mit den Temperaturen hatte ich ja das gleiche Problem und bin das umgangen indem ich vorher im Flow den "Raum" mit in den Payload jedes Objektes packe.

An den Status komme ich easy weil es ein Value ist der überall gleich heißt. "*.status"
An "Abstellkammer.Regal" komme ich aber eben nicht "automatisch" ran, weil das ja überall anders heißt.

[mickym]

@schmetterfliege sagte in Zigbee2mqtt installation:

In der Tabelle mit den Temperaturen hatte ich ja das gleiche Problem und bin das umgangen indem ich vorher im Flow den "Raum" mit in den Payload jedes Objektes packe.

Das ist keine Umgehung. Du musst grundsätzlich alle Spalten, die Du in der Tabelle anzeigen willst, als eigene Eigenschaften in den Objekten mitführen. Das ist keine Umgehung sondern - das ist so definiert.

[Schmetterfliege]

@mickym said in Zigbee2mqtt installation:

@schmetterfliege sagte in Zigbee2mqtt installation:

In der Tabelle mit den Temperaturen hatte ich ja das gleiche Problem und bin das umgangen indem ich vorher im Flow den "Raum" mit in den Payload jedes Objektes packe.

Das ist keine Umgehung. Du musst grundsätzlich alle Spalten, die Du in der Tabelle anzeigen willst, als eigene Eigenschaften in den Objekten mitführen. Das ist keine Umgehung sondern - das ist so definiert.

Manno

dann wird das ziemlich umständlich

[mickym]

@schmetterfliege Verstehe nicht, warum das umständlich sein soll. Jedes Objekt entspricht einer Zeile und jede Eigenschaft des Objektes ist eine Spalte. - So ist die Tabelle aufgebaut. Ich seh das Problem nicht.

Wenn Du Hierarchien aufbauen willst in der Tabelle - dann geht das denke ich auch - aber da bin ich raus.

Dann solltest Du Dir anstelle der table NOde - direkt mit dem Tabulator arbeiten.

Dazu schau Dir mal diesen Flow an:
https://forum.iobroker.net/post/878465

und da gibts auch Beispiele - aber wie gesagt da bin ich erst mal raus.

Damit kannst dann auch Gruppieren oder Baumstrukturen aufbauen. Aber wie gesagt - das hab ich alle noch nicht gemacht.

[Schmetterfliege]

@mickym
Grade versuche ich mich daran die dinger per Split Node erstmal außeinander zu nehmen.

Bei den Kontaktsensoren komme ich dann schon an so einen Punkt.
Die nach Raum zu trennen geht mit einer split Node problemlos.
Aber in Räumen wo 2 sind habe ich dann 2 Objekte im Payload + den Raum.
Da habe ich jetzt 2 Probleme:

1. wenn ich jetzt noch eine Split Node dran hänge kommt nur noch einzelnes Zeug raus das nicht mehr zusammenhängt.
   Also Fenster_Rechts hätte dann keinen Wert "Status" mehr, sondern erster Output = Fenster_Rechts, zweiter Output = status.
   

2. Könnte ich ja theoretisch umgehen indem ich den raum nicht im Payload vom "Hauptobjekt" habe, sondern in den einzelnen Objekten im Payload.
   Aber da ist dann wieder das Problem dass ich nicht weiß wie ich payload.status nach payload.*.status verschieben kann. Wildcards gehen da ja nicht.

[mickym]

@schmetterfliege sagte in Zigbee2mqtt installation:

@mickym
Grade versuche ich mich daran die dinger per Split Node erstmal außeinander zu nehmen.

Na mach mal - ich kapier nicht, was Du willst. Wie gesagt - Du mussen die Werte aller Spalten als Eigenschaften in den Objekten vorhanden sein.

[Schmetterfliege]

@mickym said in Zigbee2mqtt installation:

@schmetterfliege sagte in Zigbee2mqtt installation:

@mickym
Grade versuche ich mich daran die dinger per Split Node erstmal außeinander zu nehmen.

Na mach mal - ich kapier nicht, was Du willst. Wie gesagt - Du mussen die Werte aller Spalten als Eigenschaften in den Objekten vorhanden sein.

Genau das versuche ich gerade

[Schmetterfliege]

In anderen Worten:

"raum" soll in die Objekte verschoben/kopiert werden.
Und zwar in einer Syntax die allgemein geht - also wo nicht "payload.Fenster_Links.raum" steht sondern payload.*.raum

[Schmetterfliege]

JSON schaut schon mal nach einer guten Richtung aus

[mickym]

@schmetterfliege

Du machst alles einheitlich.

Wenn es sich nur darum handelt, dass Du einmal nur Raum hast und einmal Raum und Ort. Dann behandelst Du halt im ersten Schritt alles als Raum.

Also in den Objekten wo nur ein Raum vorhanden ist - das halt ein einfacher Raum.

Also

Gerätetyp/Raum/Gerät

oder halt

Gerätetyp/Raum/Ort/Gerät

Wie gesagt - ich werde sicher keine Flows nachvollziehen jetzt - sondern die Basis muss halt stimmen.

Gerätetyp ist die erste Ebene, Gerät ist die letzte Ebene
Raum ist erst mal das dazwischen.

Das kannst ja dann abprüfen, ob Raum dann solo steht oder Raum/ort enthält. Wie gesagt - mit Deinen Objekten bin ich raus. Weil ich halt das Objekt am Anfang immer nur in 3 Ebenen unterteilen würde.

Du machst Dir mit der dummen function Node und aufsplitten des Pfades alles kaputt. Dann speichere Dir lieber den ganzen Pfad als Eigenschaft im Objekt mit und dann kannst Du das im Objekt selbst immer noch auseinanderfieseln.

Der status Datenpunkt ist doch immer der letzte in der Hierarchie - also speichere halt den ganzen Pfad ab und anlysiere das in dem Objekt,

Wie gesagt in dem Fall, wenn es um die Verfügbarkeit geht, halte ich eine Initialisierung eh für "Schwachsinn" - da bin ich grundsätzlich ein Anhänger von Echtdaten.