Monatsrückblick Januar/Februar 2026 ist online!

[Bennyoe]

@toralt Im Screenshot ist die erweitere Option für availability, nur auf true setzen hatte ich zu beginn, das hat jedoch auch nicht funktioniert.

[toralt]

@bennyoe ist das das selbe wie in der configuration.yaml? Ich habe mich damals halt stur an die speziellen Adapteranpassungen gehalten.
https://github.com/arteck/ioBroker.zigbee2mqtt/blob/main/docs/DE/DE_get-started.md

[Bennyoe]

@toralt ja in beide Richtungen getestet, das ist nur ein Frontend für die config, händisches ändern der config hat auch die passende Anzeige im Frontend zur Folge.

[Bennyoe]

Hat sich erledigt, wer Fehler Logs lesen kann ist klar im Vorteil.
Sollte jemand die selben Probleme haben, in der config.yaml sind folgende Punkte einzutragen:
advanced:
legacy_api: false
legacy_availability_payload: false

device_options:
legacy: false

[arteck]

@bennyoe sagte in Zigbee2MQTT Datenpunkte falsch:

advanced:
legacy_api: false
legacy_availability_payload: false
device_options:
legacy: false

wer lesen kann ist klar im Vorteil
steht auch hier
https://github.com/arteck/ioBroker.zigbee2mqtt/blob/main/docs/DE/DE_faq.md#welche-zigbee2mqtt-konfigurationsparameter-werden-benötigt-

wozu schreiben wir die Doku

[Wildbill]

@arteck Was hat es denn mit dem Punkt

cache_state: false

auf sich, der sich im Dir verlinkten Beitrag befindet und den man so setzen sollte? Ich hatte den bislang nicht gesetzt (also war der default true) und es hat anscheinend dennoch alles funktioniert. Habe es jetzt wie im DOC auf false gesetzt, merke aber keinen Unterschied im Verhalten?!

Gruss, Jürgen

[Wildbill]

@arteck Kannst Du dazu nichts sagen, was es mit cache_state: false auf sich hat? Ich hatte es bis damals auf true, ohne Probleme festzustellen (habe Zigbee2MQTT aber auch erst 2 Wochen am Laufen, nachdem ich von Deconz gewechselt bin). Dann hatte ich es am 14.01. auf false umgestellt und hatte jetzt zweimal das Problem, dass mir Geräte (batteriebetriebene) die mal offline gingen, weil bei einem Stromkreis mit deren Routern kurz der Strom weg war, in iobroker auf offline blieben und erst nach einem Neustart des Adapters wieder online waren. Mit cache_state: true meine ich, dass sie automatisch wieder auf available=true gingen, sobald wieder ein Paket ankam. Mein Verständnis des Cache bei Zigee2MQTT würde mir jetzt sagen, dass eben mit true immer alle Attribute übertragen werden und bei false nur die, die sich geändert haben?! Aber warum dann das unterschiedliche Verhalten, wenn sich die Availability in Zigbee2MQTT ja geändert hat? Und warum sollte ich NICHT wollen, dass auch unveränderte Attribute einfach (nochmal) mit übertragen werden?

Gruss, Jürgen

[arteck]

@wildbill google hilft oder einfach nur das zigbee2mqtt Project sich anschauen

https://github.com/Koenkk/zigbee2mqtt/issues/4225

https://www.zigbee2mqtt.io/guide/configuration/mqtt.html#mqtt-behaviour

[Wildbill]

@arteck Das hatte ich ja bereits gelesen und macht eigentlich auch Sinn, erklärt aber irgendwie nicht das komische Verhalten, dass Geräte in iobroker bei availability weiterhin offline bleiben, auch wenn sie längst wieder senden, bis ich den Adapter einmal neu starte, wenn ich den Cache abschalte. Ich beobachte das mal weiterhin.

Gruss, Jürgen

[Segway]

@arteck sagte in Zigbee2MQTT Datenpunkte falsch:

https://github.com/arteck/ioBroker.zigbee2mqtt/blob/main/docs/DE/DE_faq.md#welche-zigbee2mqtt-konfigurationsparameter-werden-benötigt-

wozu schreiben wir die Doku

Dann ist das an 5. Stelle in der Doku als Frage definiert genau richtig platziert 👍