Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[astrakid]

hi,
ich habe den zigbee-adapter erfolgreich im einsatz und möchte nun die states per mqtt bereitstellen, um evcc per mqtt bestimmte geräte steuern lassen zu können.
mit dem mqtt-adapter habe ich dazu die states publishen wollen gegen meinen mqtt-broker (mosquitto). problem: wenn ich das mache, dann läuft mein server amok, da scheinbar die selbst publizierten states dann wieder per mqtt konsumiert werden und sich das dann aufschaukelt.
hat einer eine idee, wie ich das am sinnvollsten machen kann?

gruß,
andre

[Homoran]

@astrakid sagte in zigbee-states per mqtt bereitstellen:

mit dem mqtt-adapter habe ich dazu die states publishen wollen gegen meinen mqtt-broker (mosquitto)

wie hast du das versucht?
bitte zeigen!

wenn du schon einen externen Broker hast, warum dann niht mit dem mqtt-client Adapter)

[Marc Berg]

@astrakid sagte in zigbee-states per mqtt bereitstellen:

hat einer eine idee, wie ich das am sinnvollsten machen kann?

Mit den richtigen Einstellungen sollte das ohne Probleme machbar sein, auch mit dem MQTT Adapter.

@Homoran sagte in zigbee-states per mqtt bereitstellen:

bitte zeigen!

[Homoran]

@Marc-Berg sagte in zigbee-states per mqtt bereitstellen:

auch mit dem MQTT Adapter.

Natürlich

@Marc-Berg sagte in zigbee-states per mqtt bereitstellen:

Mit den richtigen Einstellungen

aber mich interessiert einfach die dahinterstehende Intention den MQTT-Adapter zu nehmen.

[mickym]

Ich habe das nun schon seit ein paar Jahren so laufen - du musst nur alle Haken im mqtt-Adapter wegmachen.

Und bei dem zigbee2mqtt Adapter würde ich halt direkt in mosquitto publishen. Ich arbeite aber ohne den Adapter und lasse direkt in mosquitto von zigbee2mqtt publishen.

[Asgothian]

@mickym sagte in zigbee-states per mqtt bereitstellen:

Und bei dem zigbee2mqtt Adapter würde ich halt direkt in mosquitto publishen. Ich arbeite aber ohne den Adapter und lasse direkt in mosquitto von zigbee2mqtt publishen.

Ich sehe da 4 Optionen - 2 reelle, 2 theoretische:

1. Zigbee Adapter weiter nutzen, und via MQTT Adapter die gewünschten States zu MQTT Publishen
2. Zigbee2mqtt nutzen. im ioBroker den ioBroker.Zigbee2Mqtt Adapter nutzen. Der Adapter kommuniziert mit Z2M via Websocket. Zigbee2mqtt.io kann dann direkt an den MQTT Broker publishen und auch direkt nachrichten von EVCC subscriben.
3. (theoretisch): Zigbee2mqtt nutzen, via iobroker.zigbee2mqtt in den ioBroker holen, und dann vom ioBroker zu MQTT publishen ist am Ende unnötig viel Arbeit.
4. (theoretisch): zigbee2mqtt nur am mqtt Broker zu betreiben und alle gewünschten Control-States manuell managen. Auch da sehe ich letztendlich viel zu viel Arbeit - auch wenn das genau das it was @mickym nutzt. Wenn ich das richtig erinnere nutzt er aber MQTT auch an anderen Stellen sehr intensiv, so das da viel Detailwissen und 'best practices' zum Umgang mit neuen / geänderten Geräten vorhanden ist.

Die Optionen 1 und 2 haben jeweils ihre Vor- und Nachteile. Insbesondere wenn nur gezielte Geräte von evcc via MQTT gesteuert werden sollen ist die Option 1 ggf. die beste - dann hast du im ioBroker die Kontrolle, da dieser die Steuerbefehle annehmen und weitergeben muss. Da lassen sich dann auch 'einfachere' Logiken abbilden.

A.

[mickym]

@Asgothian Ich weiß zwar nicht, warum das kompliziert ist, wenn man zigbee2mqtt direkt in mosquitto reporten lässt, insbesondere da die Attribute, wenn man kein JSON will nun auch einzeln in mqtt schreiben lassen kann.

Ich finde auch, dass das Front-End von zigbee2mqtt hervorragend ist.

Und über den set Datenpunkt mit einem JSON, eine Lampe durch

{"state":"on"}

oder off zu schalten, sollte ja nun auch nicht mehr so schlimm sein - da ja Blockly nun auch Objekte schreiben kann.

[Asgothian]

@mickym sagte in zigbee-states per mqtt bereitstellen:

@Asgothian Ich weiß zwar nicht, warum das kompliziert ist, wenn man zigbee2mqtt direkt in mosquitto reporten lässt, insbesondere da die Attribute, wenn man kein JSON will nun auch einzeln in mqtt schreiben lassen kann.

Ich muss zugeben das ich nicht weiss in wie weit die zum steuern benutzten Datenpunkte im ioBroker vom Frontend auch entsprechend automatisch angelegt werden. Als ich das (zugegebenermassen vor 3 Jahren) probiert hatte war dem nicht so. Da bekam ich alle Datenpunkte die reportet wurden geliefert, musste aber alle Datenpunkte zum Ansteuern selber anlegen.

Wenn das inzwischen nicht mehr so ist dann ändere ich den Post oben natürlich - dann ist meine Info da veraltet.

A.

Edit - TypoEx.

[mickym]

@Asgothian Wie gesagt, ich arbeitet nur noch mit JSON und nicht mehr mit einzelnen Werten und will auch gerade nicht mehr mein produktives System mit einzelnen Datenpunkten vollschreiben lassen und ob man dann das Attribut direkt ändern kann.

Wenn Du wie ich über den Set Punkt gehst (das wäre dann das einzige topic, das man publishen muss - geht aber auch mit dem SendTo Baustein).

, dann kann man auch mehrere Parameter in dem Objekt aufeinmal steuern und ändern.

Hier am Beispiel gleichzeitig einschalten und die Helligkeit setzen.

EDIT: Ich gebe Dir allerdings recht, bei solchen Einstellungen wie beim Bewegungsmelder der occupancy_timeout etc. muss man dann das Interface zu Hilfe nehmen, da dies nicht bei den normalen Optionen, sondern in den Gerätedefinitionen gespeichert wird.

[Asgothian]

Ich fürchte, damit ist die Behandlung dieser Geräte doch etwas komplexer, als wenn man es über den zigbee2mqtt Adapter macht. Ja, es ist nicht unendlich komplex, und es hat auch durchaus Vorteile, aber es ist eine Abkehr von dem Ansatz, dass für dedizierte Befehle und Informationen entsprechende Datenpunkte im Objektbaum verfügbar sind.
Damit kann man sicherlich gut arbeiten, aber es ist letztendlich dann doch komplexer, insbesondere, wenn man zusätzlich noch das Ganze an eine Visualisierungen oder Alexa weitergeben möchte. Da hat man dann entsprechend Zusatzaufwand.
Wenn man sich dafür ein gutes System geschaffen hat, dann ist das sicherlich eine sehr gute Methode. Und ich gehe davon aus, dass du dieses System auch für dich gefunden hast. Deswegen die Aussage bitte nicht als Kritik an deiner Arbeitsweise sehen, sondern es als Beschreibung für Leute sehen die neu damit anfangen.

A.

[mickym]

@Asgothian Na ich habe gerade geschrieben, alles wird nicht in mqtt gepublished, sondern man braucht ggf. noch das Interface. - Na egal, mir gehts ja auch nicht darum, jetzt die EINE Lösung zu präferrieren, wobei ich halt aus Gründen der möglichen Fehler nicht unbedingt 3 Systeme haben wollte, um ein Ergebnis zu erzielen. ;)

Und wie gesagt man kann auch die Attribute einzeln via mqtt schreiben lassen - aber ich hab es jetzt auch nicht ausprobiert.

Aber alles gut - ich fasse es nicht als Kritik auf, sondern soll ja nur aufzeigen, dass man es mal versuchen kann, insbesondere, wenn man einen externen mqtt Broker hat über den halt noch andere Systeme außer dem iobroker kommunizieren.

[astrakid]

@Asgothian sagte in zigbee-states per mqtt bereitstellen:

Zigbee2mqtt nutzen. im ioBroker den ioBroker.Zigbee2Mqtt Adapter nutzen. Der Adapter kommuniziert mit Z2M via Websocket. Zigbee2mqtt.io kann dann direkt an den MQTT Broker publishen und auch direkt nachrichten von EVCC subscriben

perfekt, danke euch allen. ich werde dann diese variante umsetzen. migration hab ich schon hinbekommen. muss nur noch schauen, wie ich ein paar wenige datenpunkte aus iobroker in richtung mqtt-broker bekomme und die last gering halte.

danke für die anregungen und die hilfe!