Zigbee2mqtt installation
-
@schmetterfliege Ok - ich glaube mir wär das im Moment zuviel Aufwand, insbesondere wenn das alles bei Dir einigermaßen funktioniert hat. Bei mir war es halt die Entscheidung auf zigbee2mqtt umzusteigen, da mir der Adapter hie rmit dem Conbee2 nicht genügend unterstützt wurde. Bei den anderen Dingen habe ich zugegebenermassen von Anfang an auf Adapter verzichtet, da mir originäres mqtt eine Fehlerquelle weniger darstellt und man nicht darauf angewiesen ist, ob ein bestimmtes Gerät unterstützt wird oder nicht.
-
Wunderschönen guten Abend!
Kurze Frage: zigbee2mqtt hat ja die aktuellen Werte von allen Geräten.
Wie kann ich in NR den Status denn aktiv abfragen?
Hab mal angefangen den Status der Kontaktsensoren wieder zum Laufen zu bringen.
Allerdings müsste ich alles einmal auf und zu machen damit die ihren Status pushen - ich sitz aber grade so schön^^ -
-
Na Du kannst nur die iob Datenpunkte nehmen. mqtt - hält keine Daten vor.
-
Du kannst alles im Kontext von NRim File Kontext speichern - aber da Du den iob hast, brauchst Du das nicht.
-
Eine andere Möglichkeit mit mqtt Du kannst das retain flag setzen - dann bleibt alles in mqtt gespeichert und spukt alles wieder aus, wenn Du Dich verbindest.
Wenn Du zigbee2mqtt auf mqtt V5 umstellst kannst auch ein Ablaufdatum definieren - aber hab ich nicht ausprobiert.
Fazit: Aktiv abfragen geht nicht - da das mqtt widerspricht, aber Du kannst es wie gesagt alles im Kontext speichern und somit hast Du es immer zur Verfügung.
-
-
Ich nehme mal Möglichkeit 3 für den Anfang.
Im IoB alles zu speichern ist vielleicht eine Option wenn alle Geräte mal verbunden sind und ich 100% sicher bin dass ich die Struktur etc. nicht mehr ändere.Was meinst du mit "wenn du dich verbindest"?
Ist das nicht alles die ganze Zeit miteinander verbunden?
Oder meinst du wenn eine mqtt Node zu irgendwas subscribed, dass diese dann die retained Daten bekommt? -
@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.
-
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-zigbee2mqtt -
@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.
