Zigbee2mqtt installation
-
@mickym said in Zigbee2mqtt installation:
@schmetterfliege Na ich weiss aber nicht, ob da Einstellungen oder auch status gespeichert sind. Wie gesagt - mqtt ist dafür da - dich dann zu benachrichtigen, wenn es das Gerät was meldet und nicht wann du es willst. Dafür musst du selbst sorgen. Ich würde deshalb Variante 1 bevorzugen. Alles andere ist Vergewaltigung von mqtt.
Okay, das heißt MQTT = Pipe, IoB = Datenbank und die muss ich - über welchen Weg auch immer - "selbst" aufbauen.
Was hältst du für den besseren Weg? Die Daten in IoB zu speichern, oder direkt in NR? Benutzt (in jeglicher Form) werden die von mir ja sowieso nur in NR.
Bin halt etwas verunsichert nachdem der MQTT Adapter in IoB mir so unzuverlässige Daten gezeigt hat^^
Wenn ich in z2m Sachen ändere (zb Name ändern) muss ich halt manuell im IoB den Ast löschen und dann in NR auch wieder die Nodes ändern - ist halt umständlich.@nox309 said in Zigbee2mqtt installation:
Moin Ihr beiden,
Ich habe hier den Beitrag durch Zufall gefunden und nur kurz überflogen, daher kann es durchaus sein, dass ich hier jetzt auf Sachen antworte, die schon längst geklärt sind. Aber ich glaube, viele deiner Fragen und "Probleme" können durch folgenden Adapter/Beitrag gelöst werden. https://forum.iobroker.net/topic/59260/test-adapter-zigbee2mqttAlso wenn der Adapter mir damit quasi das Frontend von zigbee2mqtt in den IoB holt (und die Daten da auch jederzeit "aktuell" sind - zumindest wirkt es für mich in dem Frontend so^^), dann wäre das in der Tat eine fantastische Bereicherung!
-
@schmetterfliege Ja er holt alle Daten sowie die WebUI von Zigbee2MQTT in den ioBroker.
Die Daten sind live in beide Richtungen. -
@schmetterfliege sagte in Zigbee2mqtt installation:
Was hältst du für den besseren Weg? Die Daten in IoB zu speichern, oder direkt in NR? Benutzt (in jeglicher Form) werden die von mir ja sowieso nur in NR.
Bin halt etwas verunsichert nachdem der MQTT Adapter in IoB mir so unzuverlässige Daten gezeigt hat^^
Wenn ich in z2m Sachen ändere (zb Name ändern) muss ich halt manuell im IoB den Ast löschen und dann in NR auch wieder die Nodes ändern - ist halt umständlich.Na ich denke - das ist einer der Hauptgründe den iob zu nutzen, da Du die States zur Verfügung hast und das auch grafisch schön aufbereitet ist. Der mqtt- Adapter funktioniert - da waren halt am Anfang viel Blödsinn, den Du aber gemacht hast mit Zuständen publishen und so einen Schmarn. ;)- Auch dass Du die Äste wieder löschen musst. Das wird immer so sein - man ändert die Struktur auch nicht und gerade weil Du über das zigbee2mqtt die Möglichkeit hast die Geräte logisch abzuspeichern hast Du auch kein Problem mehr, wenn Du Hardware tauschen musst.
Wenn man Gerätenamen ändert hast Du in jedem System ein Problem. Deswegen gibts ja auch die Aliase - die aber in dem Fall überflüssig sind. Allerdings wenn Du den Namen eines Alias änderst hast Du das gleiche Problem. Man sollte das halt vorher gut überlegen aber da hat kein System ein Vorteil. Selbst wenn Du alles subscribest musst Du immer individuell angepasst auf das Gerät zu reagieren. Also das Änderungsargument ist eher schwach bzw. spricht für mangelnde Planung. Insbesondere mit zigbee2mqtt - bist Du ja nicht mehr wie beim Zigbee- Adapter auf Gerätenamen festgelegt.
-
@mickym said in Zigbee2mqtt installation:
@schmetterfliege sagte in Zigbee2mqtt installation:
Was hältst du für den besseren Weg? Die Daten in IoB zu speichern, oder direkt in NR? Benutzt (in jeglicher Form) werden die von mir ja sowieso nur in NR.
Bin halt etwas verunsichert nachdem der MQTT Adapter in IoB mir so unzuverlässige Daten gezeigt hat^^
Wenn ich in z2m Sachen ändere (zb Name ändern) muss ich halt manuell im IoB den Ast löschen und dann in NR auch wieder die Nodes ändern - ist halt umständlich.Na ich denke - das ist einer der Hauptgründe den iob zu nutzen, da Du die States zur Verfügung hast und das auch grafisch schön aufbereitet ist. Der mqtt- Adapter funktioniert - da waren halt am Anfang viel Blödsinn, den Du aber gemacht hast mit Zuständen publishen und so einen Schmarn. ;)- Auch dass Du die Äste wieder löschen musst. Das wird immer so sein - man ändert die Struktur auch nicht und gerade weil Du über das zigbee2mqtt die Möglichkeit hast die Geräte logisch abzuspeichern hast Du auch kein Problem mehr, wenn Du Hardware tauschen musst.
Wenn man Gerätenamen ändert hast Du in jedem System ein Problem. Deswegen gibts ja auch die Aliase - die aber in dem Fall überflüssig sind. Allerdings wenn Du den Namen eines Alias änderst hast Du das gleiche Problem. Man sollte das halt vorher gut überlegen aber da hat kein System ein Vorteil. Selbst wenn Du alles subscribest musst Du immer individuell angepasst auf das Gerät zu reagieren. Also das Änderungsargument ist eher schwach bzw. spricht für mangelnde Planung. Insbesondere mit zigbee2mqtt - bist Du ja nicht mehr wie beim Zigbee- Adapter auf Gerätenamen festgelegt.
Na aber da hast du doch schon das Beispiel genannt mit dem Sachen ändern kaum Auswirkungen hat: Zigbee Adapter.
Da haben die Geräte immer die gleiche ID, wenn ich da den Namen ändere ist das einfach nur ein gelesener Wert der sich ändert.
Dass das jetzt anders funktioniert - auch was die Grundlegende Idee dahinter angeht - ist klar. Aber das (u.a. in meinem Kopf) komplett umzustellen geht halt nicht von jetzt auf nachher
Mache gleich noch einen Post mit einer Frage - köpfe mich bei der virtuell bitte nicht
-
Nur um mal sicherzustellen dass ich das gesamte Konzept überhaupt kapiere...
Mosquitto ist mein MQTT Broker.
Der publisht einfach nur Daten die er bekommt. (Der hält by Default keine Daten vor und ist dafür auch nicht gedacht)
Zigbee2mqtt kommuniziert mit den Zigbee Geräten und übersetzt diese Daten in MQTT.
Der MQTT Adapter in IoB hört dem Broker einfach nur zu.Das was ich in Zigbee2mqtt als "hat die aktuellen Daten" bezeichne ist tatsächlich eine Datenbank.
Aber eben nicht der "MQTT" Daten, sondern der Zigbee Daten.
(Merke: Ich muss in die Birne bekommen dass z2m != MQTT und umgekehrt.)Der neue Zigbee2mqtt Adapter der oben erwähnt wurde wird auch eben nur die "Zigbee Daten" liefern - von den Tasmota Devices weiß der nichts. Der Adapter wäre also eine (sinnvolle) Ergänzung um in IoB wieder die Zigbee Daten zu haben.
Die Tasmota Daten zu...datenbankisieren? (Mir fällt das Wort nicht ein) ist also trotzdem nötig.
-> MQTT Daten nutzen.
Also da zb. deine bereits geteilten Wege studieren mit denen du das easy realisiert hast.Und: Das Zeug in NR hat rein gar nichts mit dem MQTT Adapter in IoB zu tun - zumindest aktuell da ich die Datenpunkte ja noch gar nicht nutze, sondern in NR selbst über MQTT dem Broker direkt zuhöre.
Sofern ich da jetzt keine kolossalen Fehler drin habe, habe ich jetzt einiges Verstanden und ein deutlich besseres Bild davon wie das "Gesamtkonstrukt" aussieht, wie ich es nutzen muss und wie ich gewisse Dinge wie zb. die "Datenbank" umsetzen kann/muss.
Kurz: mir ist ein Licht aufgegangen? Oder ist das Stuss?
EDIT: Und zigbee2mqtt hört dem Broker nicht zu, sondern füttert den mit den übersetzten Zigbee Daten.
-
@schmetterfliege sagte in Zigbee2mqtt installation:
Nur um mal sicherzustellen dass ich das gesamte Konzept überhaupt kapiere...
Mosquitto ist mein MQTT Broker.
Der publisht einfach nur Daten die er bekommt. (Der hält by Default keine Daten vor und ist dafür auch nicht gedacht)
Zigbee2mqtt kommuniziert mit den Zigbee Geräten und übersetzt diese Daten in MQTT.
Der MQTT Adapter in IoB hört dem Broker einfach nur zu.Nun ich würde MQTT im Prinzip als Informationsverteiler sehen. Geräte können Themen abonnieren oder einen Status veröffentlichen. Der Broker sorgt dafür, dass die Werte jedes Endgerät erreichen, dass online ist.
Richtig: Zigbee2Mqtt ist ein Gateway und veröffentlicht deshalb Status der gekoppelten Geräte über MQTT. Der MQTT Adapter hört nicht nur zu, sondern published auch Status. Sprich Du kannst auch Datenpunkte im Adapter beschreiben und diese werden dann zum MQTT Broker gepublished. Werden diese Topics wiederum vom Zigbee2Mqtt Gateway subscribed (also abonniert), nimmt das Gateway die Befehle entgegen und leitet diese an das Endgerät weiter.
https://www.zigbee2mqtt.io/guide/usage/mqtt_topics_and_messages.html#zigbee2mqtt-friendly-name-set
Also auch hier greifst Du nicht auf gespeicherte Daten zurück, sondern weist das Gateway an, die Daten erneut zu senden. Ob dabei das Gateway die Daten aktiv vom Gerät abfragt oder den letzten bekannten Status erneut veröffentlicht - kann ich im Moment nicht sagen. In der Geräteübersicht siehst Du ja wie beim Zigbee Adapter wann die sich das letzte Mal gemeldet haben. Das funktioniert nach dem gleichen Prinzip.
Das was ich in Zigbee2mqtt als "hat die aktuellen Daten" bezeichne ist tatsächlich eine Datenbank.
Aber eben nicht der "MQTT" Daten, sondern der Zigbee Daten.
(Merke: Ich muss in die Birne bekommen dass z2m != MQTT und umgekehrt.)Nein Zigbee2mqtt ist ein Gateway und keine Datenbank. Wenn der Service neu startet, hat noch die letzten Daten gespeichert und kann ggf. die Daten auch abfragen. Beim zigbee2mqtt kannst Du (im Gegensatz zu tasmota) die Daten schon aktiv auf Bedarf abfragen - aber nicht weil es eine Datenbank ist. Mit bestimmten Befehlen kannst Du den Status eines Gerätes abrufen. Das ist aber nicht, weil es in MQTT gespeichert ist, sondern weil Du das zigbee2mqtt Gateway anweisen kannst - einen Status zu veröffentlichen (publishen)
Im Prinzip ist das Gateway Zigbee2mqtt - nur 1 Gerät - nämlich ein Gateway - das mehrere Geräte verwaltet. Sowie Tasmota ein Einzelgerät ist oder eine Steckdosenleiste mit mehren Steckdosen. Geräte kennen nur einen Status und der wird in der Regel nirgends vorgehalten, sondern es werden nur Änderungen oder Aktualisierungen von Momentanzuständen veröffentlicht. Das machen sie entweder auf Anforderung (status Ast bei Tasmota) oder in festgelegten Intervalen (tele Ast bei Tasmota). Sammeln von Zuständen kannst Du dann im iob Broker machen oder Du schreibst es in eine richtige Datenbank - dann kannst auch noch Historie aufzeichnen.
Im Prinzip musst Du Dich damit abfinden, dass die Geräte sagen wo es lang geht. Wenn Du Glück hast, antwortet es wann auf Anforderung, in der Regel macht es das aber vordefiniert entweder bei Änderungen oder nach eigenen Intervallen.
Der neue Zigbee2mqtt Adapter der oben erwähnt wurde wird auch eben nur die "Zigbee Daten" liefern - von den Tasmota Devices weiß der nichts. Der Adapter wäre also eine (sinnvolle) Ergänzung um in IoB wieder die Zigbee Daten zu haben.
Richtig.
Die Tasmota Daten zu...datenbankisieren? (Mir fällt das Wort nicht ein) ist also trotzdem nötig.
-> MQTT Daten nutzen.
Also da zb. deine bereits geteilten Wege studieren mit denen du das easy realisiert hast.Wie gesagt - und das ist aber mit allen Adaptern oder Hardware so. Die Adapter speichern einen letzten Status im iob. Wie aktuell die sind hängt vom Adapter ab und wie dieser mit der Hardware kommunizieren kann. MQTT ist halt für alle iot Geräte ein standardisiertes Protokoll, das einfach zu implementieren ist und mit den beschränkten Ressourcen einer Hardware Zustände verteilen kann, für die Geräte oder Systeme, die damit was anfangen wollen.
Und: Das Zeug in NR hat rein gar nichts mit dem MQTT Adapter in IoB zu tun - zumindest aktuell da ich die Datenpunkte ja noch gar nicht nutze, sondern in NR selbst über MQTT dem Broker direkt zuhöre.
Du hast grundsätzlich 2 Wege. Du kannst direkt über die mqtt-Nodes mit den Geräten sprechen oder über den iob Mqtt Adapter. Grundsätzlich kannst Du über die iobroker IN - OUT Nodes alles über den mqtt-Adapter steuern oder Dir anzeigen lassen.
Ist aber halt ein Umweg - da Du eben auch direkt von NR mit mqtt kommunizieren kannst.
Wenn man es optimal - durchdenkt - dann würde man wahrscheinlich so vorgehen:
Im Prinzip würde man die mqtt Nodes nutzen, um sich ggf. direkt informieren zu lassen oder Geräte zu steuern, die Daten im mqtt- Adapter um auf Bedarf die letzten Zustände abzufragen (also iob ist die Datenbank)-Sofern ich da jetzt keine kolossalen Fehler drin habe, habe ich jetzt einiges Verstanden und ein deutlich besseres Bild davon wie das "Gesamtkonstrukt" aussieht, wie ich es nutzen muss und wie ich gewisse Dinge wie zb. die "Datenbank" umsetzen kann/muss.
Kurz: mir ist ein Licht aufgegangen? Oder ist das Stuss?
Im Großen und Ganzen hast Du es schon verstanden. Nur ich würde eben sagen - letztlich sind die Datenpunkte im iob - Deine einzige Datenbank, die die letzten Zustände aller Geräte sammelt und die Du jederzeit abfragen kannst. Du musst allerdings selbst dafür sorgen, dass die Daten aktuell sind.
Wenn Du irgendeinen adapter im iob hast, der Daten abspeichert und Du schmeisst die Hardware weg, dann bleiben die Daten ja auch noch in der Datenbank. Es wird dir vielleicht ein Fehler angezeigt oder der Adapter startet nicht mehr, aber die Daten sind trotzdem noch so lange drin, bist Du den Adapter löschst. Das kannst Du im übertragenen Sinn auch auf mqtt anwenden. Bevor es systeme wie den iob gab, hat man nur mqtt gehabt. Für eine NodeRed Standalone Installation ist auch heute noch mqtt- die präferierte Statusdatenbank, aber es wird nichts gespeichert - sondern wird in der Regel nur mit aktuellen Zuständen gearbeitet. - Das ist auch meine Device - lieber keinen Status zu jeder Zeit, dafür lieber einen Status der von einem Gerät kommt.
-
@schmetterfliege sagte in Zigbee2mqtt installation:
EDIT: Und zigbee2mqtt hört dem Broker nicht zu, sondern füttert den mit den übersetzten Zigbee Daten.
Doch freilich hört es dem mqtt-Broker zu - und zwar die set - datenpunkte - über die Du Kommandos schicken kannst.
https://www.zigbee2mqtt.io/guide/usage/mqtt_topics_and_messages.html#zigbee2mqtt-friendly-name-set
Es gibt auch andere Topics auf die zigbee2mqtt zuhört.
https://www.zigbee2mqtt.io/guide/usage/mqtt_topics_and_messages.html#zigbee2mqtt-bridge-request
Um zum Beispiel das Pairing über mqtt- zu steuern
Also:
zigbee2mqtt/bridge/request/permit_joinDu musst halt lesen. Weiss zwar noch nicht wie man das anwendet - aber somit kannst Du quasi das zigbee2mqtt fernsteuern.
-
Vielen Dank für die Ausführung!
Wenn ich also den MQTT Adapter als "Datenbank" nutzen will - dann ist die ja schon vorhanden.
Nur ist aktuell eben alles als json vorhanden und ich muss mir jetzt nur überlegen ob ich mit den json arbeiten möchte, oder die Daten auseinander ziehe und einzelne Datenpunkte erstelle (zb. Temperatur, Zustand, etc.).Wenn ich die Daten dann in InfluxDB haben möchte muss ich ja gezwungenermaßen einzelne Datenpunkte nehmen, weil das mit nem JSON ja nicht funktioniert (zumindest nicht wenn ich die Graphen auch benutzen will).
Korrekt?
-
@mickym said in Zigbee2mqtt installation:
@schmetterfliege sagte in Zigbee2mqtt installation:
EDIT: Und zigbee2mqtt hört dem Broker nicht zu, sondern füttert den mit den übersetzten Zigbee Daten.
Doch freilich hört es dem mqtt-Broker zu - und zwar die set - datenpunkte - über die Du Kommandos schicken kannst.
https://www.zigbee2mqtt.io/guide/usage/mqtt_topics_and_messages.html#zigbee2mqtt-friendly-name-set
Es gibt auch andere Topics auf die zigbee2mqtt zuhört.
https://www.zigbee2mqtt.io/guide/usage/mqtt_topics_and_messages.html#zigbee2mqtt-bridge-request
Um zum Beispiel das Pairing über mqtt- zu steuern
Also:
zigbee2mqtt/bridge/request/permit_joinDu musst halt lesen. Weiss zwar noch nicht wie man das anwendet - aber somit kannst Du quasi das zigbee2mqtt fernsteuern.
Stimmt.
Wobei ich da für mich persönlich keinen Vorteil sehe, da ich im Frontend einfach nur einen Button drücken muss um das pairing zu starten, und um die angelernten Geräte dann zu konfigurieren muss ich ja dann sowieso im Frontend machen wenn ich das nicht verkomplizieren will^^
Aber ja, die Zigbee Steckdosen steuere ich ja, also logischerweiße hört er dem Broker auch zu -
@schmetterfliege Na ja - ein JSON Objekt hat gerade bei der Verarbeitung oder auch bei den Flows einen Riesenvorteil.
Wenn Du alles in einzelnen Datenpunkten hast musst Du es über JOIN Nodes oder über iobrokerIN und iobrokerGET Nodes in ein Objekt holen. In einem JSON hast Du alles schon beieinander und kannst wenn Du einen Sensor mit Temperatur und Luftfeuchtigkeit hast - nicht beide Werte einzeln abfragen und mergen.
Über den neuen Adapter - oder meinem Subflow - der ist halt zumindest beim Lesen universeller - kannst Du alles in einzelne Datenpunkte aufdröseln und dann in Influx etc. protokollieren. Wenn man aber aus dem JSON von 10 Datenpunkten nur einen braucht mit dem man protokollieren will, dann kann man auch einen Alias verwenden, der einem diesen Wert aus dem JSON zieht (natürlich kannst auch über NodeRed Datenpunkte individuell schreiben).
Wie Du einen Alias definierst und einen einzelnen Wert aus einem JSON aus MQTT ausliest - kannst Du zum Beispiel hier lesen:
-
@mickym said in Zigbee2mqtt installation:
@schmetterfliege Na ja - ein JSON Objekt hat gerade bei der Verarbeitung oder auch bei den Flows einen Riesenvorteil.
Wenn Du alles in einzelnen Datenpunkten hast musst Du es über JOIN Nodes oder über iobrokerIN und iobrokerGET Nodes in ein Objekt holen. In einem JSON hast Du alles schon beieinander und kannst wenn Du einen Sensor mit Temperatur und Luftfeuchtigkeit hast - nicht beide Werte einzeln abfragen und mergen.
Über den neuen Adapter - oder meinem Subflow - der ist halt zumindest beim Lesen universeller - kannst Du alles in einzelne Datenpunkte aufdröseln und dann in Influx etc. protokollieren. Wenn man aber aus dem JSON von 10 Datenpunkten nur einen braucht mit dem man protokollieren will, dann kann man auch einen Alias verwenden, der einem diesen Wert aus dem JSON zieht (natürlich kannst auch über NodeRed Datenpunkte individuell schreiben).
Wie Du einen Alias definierst und einen einzelnen Wert aus einem JSON aus MQTT ausliest - kannst Du zum Beispiel hier lesen:
Cool, danke!
Schaue ich mir mal an. Brauche bei den Multisensoren zb zwar 2 Werte, aber eben nicht alle 8 oder 9 die der liefert - also: JSON it is -
@schmetterfliege Ja aber wie gesagt im Node Red kannst Du es ja auch direkt dann einzeln wegschreiben oder was immer Du damit machen willst.
Nimm mal meinen XIAOMI Thermometer mit Luftdruck und Luftffeuchtigkeit.
zum Beispiel:
Und du kannst alles zusammen miteinander verknüpfen einzeln wegschreiben usw. und musst nicht 10 Datenpunkte auslesen.
-
Ich sach ja dass es JSON wird und keine einzelnen Datenpunkte für alles
Dass ich in NR die Daten ausm JSON ziehen kann ist klar - mache ich ja schon für die Kontaktsensoren.
Mir ging es aber um die Daten in IoB, bzw. die Überlegung ob es da sinnvoll wäre einzelne Datenpunkte zu haben zwecks Influx.
Aber wenn das mit den Aliasen funktioniert, belasse ich es wie gesagt bei den JSON -
@schmetterfliege Wie gesagt schaut Dir auch mal meinen Subflow an, der Dir jeden JSON zerlegt und im iob wegschreibt. Damit kannst Du auch ganze mqtt-Bäume wegschreiben.
-
@schmetterfliege sagte in Zigbee2mqtt installation:
Aber wenn das mit den Aliasen funktioniert, belasse ich es wie gesagt bei den JSON
Ja Du kannst aber auch mit NodeRed - wenn Du eh weisst wie Du das extrahierst in einzelne DAtenpunkte unter userdata schreiben.
-
Mahlzeit,
ich muss zugeben das ich jetzt nicht alles von euch beiden hier gelesen habe, denke aber dennoch das vielleicht mein neuer Adapter hier helfen könnte.
#Werbung
https://forum.iobroker.net/topic/59260/test-adapter-zigbee2mqtt -
This post is deleted! -
@idlebit said in Zigbee2mqtt installation:
Mahlzeit,
ich muss zugeben das ich jetzt nicht alles von euch beiden hier gelesen habe, denke aber dennoch das vielleicht mein neuer Adapter hier helfen könnte.
#Werbung
https://forum.iobroker.net/topic/59260/test-adapter-zigbee2mqttJa und nein
Austesten werde ich ihn ggfs mal, einfach um die Übersicht aus dem Frontend im IoB zu haben.
Aber ich habe eben nicht nur zigbee devices sondern auch Wifi Geräte die über Tasmota eingebunden sind.
Und die kennt Zigbee2Mqtt ja nicht.
Dein Adapter würde daher "nur" ~90% abdecken und daher nicht alle Probleme lösen
Was ja aber auch gar nicht seine Intention ist -
@schmetterfliege
Hat das einen Grund, warum du die WLAN-Geräte nicht über den Sonoff Adapter einbindest?
Ich habe so alle meine Gosound angebunden und habe keine Probleme die States richtig zu verarbeiten. -
@nox309 said in Zigbee2mqtt installation:
@schmetterfliege
Hat das einen Grund, warum du die WLAN-Geräte nicht über den Sonoff Adapter einbindest?
Ich habe so alle meine Gosound angebunden und habe keine Probleme die States richtig zu verarbeiten.Mit Sonoff waren sie vorher eingebunden. Aber da ich mein Zigbee Zeug nun auch nach MQTT geholt habe hätte ich das Ganze schon ganz gerne auch in einem Adapter, daher alles zum MQTT Adapter umgezogen.
Macht ja an sich überhaupt keinen Unterschied ob die Daten nun im MQTT Adapter oder Sonoff Adapter stehen - kommt aufs gleiche raus^^
