NEWS: Neu im Admin, zentrale Verwaltung für Passwörter und Schlüssel

[arteck]

17:25:40.439	info	[ÄNDERUNG] zigbee2mqtt.0.0x00158d0003628ed2.state | Neu: false | Alt: true | ack: true | Quelle: system.adapter.zigbee2mqtt.0
17:25:40.524	info	[ÄNDERUNG] zigbee2mqtt.0.0x00158d0003628ed2.state | Neu: true | Alt: false | ack: true | Quelle: system.adapter.zigbee2mqtt.0

das ist ok

das vom admin nicht... was da los ??

17:25:40.203	info	[ÄNDERUNG] zigbee2mqtt.0.0x00158d0003628ed2.state | Neu: true | Alt: false | ack: false | Quelle: system.adapter.admin.0

das sollte nicht passieren..würde ich mal behaupten

[FernetMenta]

@arteck

17:25:40.439	info	[ÄNDERUNG] zigbee2mqtt.0.0x00158d0003628ed2.state | Neu: false | Alt: true | ack: true | Quelle: system.adapter.zigbee2mqtt.0
17:25:40.524	info	[ÄNDERUNG] zigbee2mqtt.0.0x00158d0003628ed2.state | Neu: true | Alt: false | ack: true | Quelle: system.adapter.zigbee2mqtt.0

Warum wird der alte State nochmal acknowledged? Das führt bei mir im UI zu einem Zucken der Schalter.

EDIT: ich glaube das Bsp von oben zeigt, dass über admin geschalten wurde. Könnte auch vom UI kommen. Das Problem ist, dass der State danch hin und her springt.

[mcm1957]

Warum admin?
Quelle lt log ist doch zigbee...

[FernetMenta]

Beim Schalten eines "Schalters" (States), egal ob via Admin oder Skript

Die erste Zeile ist admin. Da wurde der State geändert. Zeile 2 und 3 ist das ping pong von Zigbee.

[mcm1957]

Ja das ist richtig. Ich hab nur deinen Beitrag und den von Artek vermischt. ER meinte, dass das admin log nicht ok sein - das ist es aber m.E. Das Problem ist m.E. zu 99% im zigbee zu suchen.

[Asgothian]

@arteck sagte:

17:25:40.439	info	[ÄNDERUNG] zigbee2mqtt.0.0x00158d0003628ed2.state | Neu: false | Alt: true | ack: true | Quelle: system.adapter.zigbee2mqtt.0
17:25:40.524	info	[ÄNDERUNG] zigbee2mqtt.0.0x00158d0003628ed2.state | Neu: true | Alt: false | ack: true | Quelle: system.adapter.zigbee2mqtt.0

das ist ok

das vom admin nicht... was da los ??

17:25:40.203	info	[ÄNDERUNG] zigbee2mqtt.0.0x00158d0003628ed2.state | Neu: true | Alt: false | ack: false | Quelle: system.adapter.admin.0

das sollte nicht passieren..würde ich mal behaupten

Nein, das vom Admin ist ok.

Interessant ist, das vom Z2M Adapter der State 2 mal mit ack false geschrieben wird, einmal mit dem Wert der Laut Admin geschaltet werden sollte (Admin -> neu true, ack:false, Z2N -> neu: true, ack: true)

Aus meiner Sicht ist der mittlere Auffällig.

@nevermind

Mach mal bitte folgendes:

• stell sicher das du nicht nur Änderungen sondern auch Aktualisierungen ins Log geschrieben bekommst.
• schalte den Schalter via Z2M auf einen Wert
• Warte 120 s (das ist wichtig)
• schalte den Schalter via Admin auf den anderen Wert
• Warte wieder 160 sekunden

Poste danach bitte das Log.

Meine Vermutung ist das Z2M die vom Gerät kommende Bestätigung des Zustandes verzögert liefert (mögliche Gründe dafür gibt es viele) - dementsprechend kann die mittlere Zeile aus anderen Gründen kommen.

Zusätzlich wird benötigt:

• Die Z2M Version
• Das Log von Z2M aus dem Zeitraum
• Die Version des ioBroker.zigbee2mqtt Adapters

A.

[FernetMenta]

@asgothian die mittlere Zeile kommt definitiv vom Vorgang. Wenn ich ein Licht auf "ein" schalte, sieht das in 2tm so aus:

[22/09/2026, 09:50:37] z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Dining-Light', payload '{"brightness":76,"color":{"hue":34,"saturation":75,"x":0.4369,"y":0.4041},"color_mode":"color_temp","color_temp":333,"last_seen":"2026-09-22T09:50:37+02:00","linkquality":98,"state":"OFF"}'
[22/09/2026, 09:50:37] z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/0-2', payload '{"brightness":76,"color":{"hue":34,"saturation":75,"x":0.4369,"y":0.4041},"color_mode":"color_temp","color_temp":333,"state":"ON"}'
[22/09/2026, 09:50:37] z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Dining-Light', payload '{"brightness":76,"color":{"hue":34,"saturation":75,"x":0.4369,"y":0.4041},"color_mode":"color_temp","color_temp":333,"last_seen":"2026-09-22T09:50:37+02:00","linkquality":98,"state":"ON"}'

in iob

22/09/2026, 09:50:37.768	[info ]: javascript.0 (784) script.js.common.lights.Debug: RAW    val=true ack=false from=system.adapter.lovelace.0
22/09/2026, 09:50:37.887	[info ]: javascript.0 (784) script.js.common.lights.Debug: RAW    val=false ack=true from=system.adapter.zigbee2mqtt.0
22/09/2026, 09:50:37.982	[info ]: javascript.0 (784) script.js.common.lights.Debug: RAW    val=true ack=true from=system.adapter.zigbee2mqtt.0

Das ist zigbee2mqtt Adapter 3.2.2 und z2m 2.14.1

Da kommt also erst OFF obwohl das der aktuelle Zustand ist.

[Asgothian]

• Kommt das Log von dem Test um den ich oben gebeten habe ?

• Ist sichergestellt, das
  -- niemand die Lampe in der Zeit davor geschaltet hat ?
  -- es keine durchlaufendes Skript gibt, welches daten von Z2M per polling regelmässig abholt ?
  -- die betroffene Lame nicht bestandteil einer Gruppe ist ?

• wie ist das Log von Z2M sortiert ? Leider fehlen die ms, so das ich nicht sehen kann welche der Meldungen neu oder alt sind

• Was macht der Publish auf 'zigbee2mqtt/0-2' da drin ?

du darfst nicht vergessen - Du kennst den Kontext, und was du machst, ich sehe nur die Texte die du postest.

A.

Nachtrag: Wenn die Antwort auf die meisten / alle Fragen die ich gestellt habe ja ist, dann ist das Problem bei Zigbee2mqtt.io zu suchen - dein Log legt nahe das Z2M den falschen Status sendet, und der ioBroker den nur Anzeigt.

[FernetMenta]

Kommt das Log von dem Test um den ich oben gebeten habe ?

Ich habe mich bemüht das so zu machen.

Ist sichergestellt, das ...

Alle meine Lichter sind in Gruppen, weil ich die auch mit FB bediene.

Was macht der Publish auf 'zigbee2mqtt/0-2' da drin ?

Weiß ich nicht. Da bin ich nicht tief genug drin.

Ich habe das gemerkt als ich ganz auf Lovelace umgestellt habe. Da tippe ich auf das UI, der Schalter geht an. Kurz darauf springt er wieder zurück und wieder auf an. Das war in meinem alten UI (Jarvis) nicht so. Darum kann ich auch nicht sagen, ob das neu ist oder schon immer so war.

[FernetMenta]

Hier das z2m log aus dem logfile. Da steht etwas mehr als im Logfenster des UI.

Spoiler

 [2026-09-22 09:50:37] debug: 	z2m:mqtt: Received MQTT message on 'zigbee2mqtt/Dining-Light/set' with data '{"state":"ON"}'
[2026-09-22 09:50:37] debug: 	z2m: Publishing 'set' 'state' to 'Dining-Light'
[2026-09-22 09:50:37] debug: 	zh:controller:endpoint: ZCL command 0x00158d00029f8c44/2 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false})
[2026-09-22 09:50:37] debug: 	zh:zstack: sendZclFrameToEndpointInternal 0x00158d00029f8c44:47957/2 (0,0,1)
[2026-09-22 09:50:37] debug: 	zh:zstack:znp: --> SREQ: AF - dataRequest - {"dstaddr":47957,"destendpoint":2,"srcendpoint":1,"clusterid":6,"transid":159,"options":0,"radius":30,"len":3,"data":{"type":"Buffer","data":[1,103,1]}}
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:writer: --> frame [254,13,36,1,85,187,2,1,6,0,159,0,30,3,1,103,1,38]
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: <-- [254,1,100,1,0,100]
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: --- parseNext [254,1,100,1,0,100]
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: --> parsed 1 - 3 - 4 - 1 - [0] - 100
[2026-09-22 09:50:37] debug: 	zh:zstack:znp: <-- SRSP: AF - dataRequest - {"status":0}
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: --- parseNext []
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: <-- [254,3,68,128,0,1,159,89]
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: --- parseNext [254,3,68,128,0,1,159,89]
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: --> parsed 3 - 2 - 4 - 128 - [0,1,159] - 89
[2026-09-22 09:50:37] debug: 	zh:zstack:znp: <-- AREQ: AF - dataConfirm - {"status":0,"endpoint":1,"transid":159}
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: --- parseNext []
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: <-- [254,3,69,196,85,187,0,108,254,25,68,129,0,0,6,0,85,187,2,1,0,98,0,114,125,114,0,0,5,24,103,11,1,0,85,187,29,171]
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: --- parseNext [254,3,69,196,85,187,0,108,254,25,68,129,0,0,6,0,85,187,2,1,0,98,0,114,125,114,0,0,5,24,103,11,1,0,85,187,29,171]
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: --> parsed 3 - 2 - 5 - 196 - [85,187,0] - 108
[2026-09-22 09:50:37] debug: 	zh:zstack:znp: <-- AREQ: ZDO - srcRtgInd
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: --- parseNext [254,25,68,129,0,0,6,0,85,187,2,1,0,98,0,114,125,114,0,0,5,24,103,11,1,0,85,187,29,171]
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: --> parsed 25 - 2 - 4 - 129 - [0,0,6,0,85,187,2,1,0,98,0,114,125,114,0,0,5,24,103,11,1,0,85,187,29] - 171
[2026-09-22 09:50:37] debug: 	zh:zstack:znp: <-- AREQ: AF - incomingMsg - {"groupid":0,"clusterid":6,"srcaddr":47957,"srcendpoint":2,"dstendpoint":1,"wasbroadcast":0,"linkquality":98,"securityuse":0,"timestamp":7503218,"transseqnumber":0,"len":5,"data":{"type":"Buffer","data":[24,103,11,1,0]}}
[2026-09-22 09:50:37] debug: 	zh:controller: Received payload: clusterID=6, address=47957, groupID=0, endpoint=2, destinationEndpoint=1, wasBroadcast=false, linkQuality=98, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"transactionSequenceNumber":103,"commandIdentifier":11},"payload":{"cmdId":1,"statusCode":0},"command":{"name":"defaultRsp","ID":11}}
[2026-09-22 09:50:37] info: 	z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Dining-Light', payload '{"brightness":76,"color":{"hue":34,"saturation":75,"x":0.4369,"y":0.4041},"color_mode":"color_temp","color_temp":333,"last_seen":"2026-09-22T09:50:37+02:00","linkquality":98,"state":"OFF"}'
[2026-09-22 09:50:37] debug: 	zh:zstack:unpi:parser: --- parseNext []
[2026-09-22 09:50:37] info: 	z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/0-2', payload '{"brightness":76,"color":{"hue":34,"saturation":75,"x":0.4369,"y":0.4041},"color_mode":"color_temp","color_temp":333,"state":"ON"}'
[2026-09-22 09:50:37] info: 	z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Dining-Light', payload '{"brightness":76,"color":{"hue":34,"saturation":75,"x":0.4369,"y":0.4041},"color_mode":"color_temp","color_temp":333,"last_seen":"2026-09-22T09:50:37+02:00","linkquality":98,"state":"ON"}'

[FernetMenta]

Scheint wirklich ganz auf Seite z2m zu liegen. Auch wenn ich direkt in z2m schalte, prellt es. Vielleicht gibt es da drüben eine Einstelliung, die das verhindert.

[arteck]

ist das eine HUE Lampe ??? da wurde die Verarbeitung umgestellt

[FernetMenta]

Ich (mit KI) habe es eingegrenzt:
Wenn ein Device keinen ordentlichen defaultRespose mit Attributen schickt, sonder nur "ja, habe ich gemacht", und last_seen aktiv ist, sendet z2m eine Nachricht mit dem letzten Zustand.
Ich habe bei mir jetzt last_seen (settings - advanced) ausgeschaltet.

[FernetMenta]

last_seen sollte eigentlich default auf disabled stehen. HA sollte auch default auf false sein. Bei wir war beides enabled. Ich habe das eigentlich nie aktiviert. HA ganz bestimmt nicht. Hat sich wahrscheinlich mal ein Update verhaspelt.

[FernetMenta]

@asgothian @arteck ich hatte last_seen, weil ich es aus dem getting started von hier übernommen hatte: https://github.com/arteck/ioBroker.zigbee2mqtt/blob/main/docs/DE/DE_get-started.md

Gibt es einen Grund, warum das hier aktiv ist, obwohl in z2m default disabled?

[nevermind]

Hallo Zusammen

oh mann... ja, bei mir lag es scheinbar auch am "last seen". Hatte ich aktiviert um Probleme in meinem Zigbee-Netzwerk zu finden. Jetzt habe ich es wieder deaktiviert und das Pingpong, also die Meldung mit dem alten, vorherigen Status ist weg.

Vielen Dank :)

[arteck]

"last seen"

wovon redet ihr wo soll das sein ??

der hier +

wird der nicht gesendet funktioniert device-watcher nicht richtig

[arteck]

ich hab die Kiste (klaus) mal analysieren lassen

Da beide ack:true-Zeilen aus getrennten eingehenden Nachrichten stammen müssen, liegt die Ursache außerhalb des Adapters – bei Zigbee2MQTT bzw. dem Zigbee-Funkgerät selbst. Typische Erklärungen:

• ListenpunktOptimistic Mode von Z2M (Standard: optimistic: true): Z2M published sofort nach dem Senden des Zigbee-Kommandos den erwarteten Zielwert – trifft danach noch ein reales reportAttributes-Frame vom Gerät mit einem kurzzeitig abweichenden Ist-Wert ein (z. B. weil der Schaltvorgang de facto etwas verzögert/mit Zwischenzustand abläuft), entstehen zwei Nachrichten kurz hintereinander.

• ListenpunktBekanntes Relais-/Firmware-Verhalten bei Xiaomi/Aqara-Geräten (IEEE-Präfix 0x00158d0003... = Aqara): Manche Aqara-Steckdosen/Schalter senden beim Umschalten zwei onOff-Reports kurz hintereinander (Relais-Bounce bzw. internes Verifikationsverhalten), die Z2M 1:1 weiterreicht.

• ListenpunktNetzwerk-/MQTT-Duplikate: Ein Zigbee-Mesh-Retry (kein App-Level-ACK erhalten → erneutes Senden) oder eine doppelte MQTT-Zustellung (QoS-Redelivery) kann ebenfalls zwei fast identische, aber leicht unterschiedliche Publishes erzeugen.

• ListenpunktFalls advanced.last_seen bei dir aktiv ist, kann u. U. eine zusätzliche last_seen-only-Nachricht kurz vor/nach der echten state-Nachricht eintreffen – das erklärt aber nicht den Wertewechsel false→true, sondern höchstens den zeitlichen Abstand

[FernetMenta]

[nevermind]

Ja, was einfach strange ist, ist dass das deaktivieren von "last seen" in z2m das Problem behebt. Aber ja, liegt sicher nicht am Adapter. Ich habe mal noch ein kurzes Video gemacht:

https://www.youtube.com/watch?v=Md6h4tV19GI