Koenkk
IKEA Bulbs doesn't seem to have correct state to reality
What happened?
An automation triggered lights to turn on, and only one of them actually did and after checking in the frontend and HA, it's reported as being on, despite in reality that did not happen.
This is happening with:
What did you expect to happen?
I would have expected it to return the correct state from the device.
How to reproduce it (minimal and precise)
No response
Zigbee2MQTT version
1.29.2 commit: bb3e8f6
Adapter firmware version
20220219
Adapter
Tube's cc2652p2 PoE coordinator
Debug log
I have the same Issue with a L1529 and a LED1623G12. The L1529 claims to be on when it isn't. Even updating the status of it yields it being on while it's off. The LED1623G12 behaves completely erratic for a few days now. It won't react at all, but will claim to be on or off and react to brightness changes. In reality, the lamp is still off. Resetting the LED1623G12 doesn't help at all.
Zigbee2MQTT Version 1.30.1
Coordinator-Type zStack3x0
Coordinator-Version 20221226
Adapter: Electrolama zig-ah-zig-ah!
Hey @merlinschumacher out of curiosity, which firmware versions are your problem LED1623G12 running?
Mine LED1624G9 is on firmware 2.3.093 and the mostly working LED1924G9 one is on 1.0.021
I have similar issues with my LED1924G9. After a 6h power outage, I had to re-pair all of my IKEA bulbs. The LED1924G9 kinda work, but everything takes forever. Every change/command takes up to 10 seconds to perform. All other bulbs seem to work fine.
I've tried to remove, reset and add them again several times. Initially they seem fine, but after 6-12h (hard to be more precise) they once again respond extremely slowly. Some of them even drop of completely. I've paired them directly to the coordinator and the maximum distans to some of the bulbs is 4 meters (16.4 feet) without any major obstacles (the signal strength is roughly 160 LQI).
LED1924G9 firmware: 1.0.021
Zigbee2MQTT Version: 1.30.1-1
Coordinator-Type: zStack3x0
Coordinator-Version: 20221226
Adapter: Sonoff Zigbee 3.0 USB Dongle Plus
Hey @merlinschumacher out of curiosity, which firmware versions are your problem LED1623G12 running?
Mine LED1624G9 is on firmware 2.3.093 and the mostly working LED1924G9 one is on 1.0.021
My lamps are all on the newest firmware.
Nevertheless, i found the fundamental issue: A node I used in my Node-RED setup was outdated, and I also had disabled retain (which was neede for the node to work) for the lights that caused issues. The problems seem to have gone now.
I have retain enabled, and it's still affecting me on 1.30.1 commit: eb878d3
In case it matters, this is my Livingroom bulb (0x000d6ffffe2683e3) that has the issue and when I clicked on refresh in UI with zigbee-herdsman debug enabled:
2023-02-16T17:20:34.689Z zigbee-herdsman:controller:endpoint Read 0x000d6ffffe2683e3/1 genOnOff(["onOff"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
2023-02-16T17:20:34.689Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0x000d6ffffe2683e3:121/1 (0,0,1)
2023-02-16T17:20:34.690Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":121,"destendpoint":1,"srcendpoint":1,"clusterid":6,"transid":22,"options":0,"radius":30,"len":5,"data":{"type":"Buffer","data":[16,9,0,0,0]}}
2023-02-16T17:20:34.690Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,15,36,1,121,0,1,1,6,0,22,0,30,5,16,9,0,0,0,65]
2023-02-16T17:20:34.707Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
2023-02-16T17:20:34.707Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
2023-02-16T17:20:34.707Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2023-02-16T17:20:34.708Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2023-02-16T17:20:34.708Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2023-02-16T17:20:34.712Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,0,1,22,208]
2023-02-16T17:20:34.712Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,1,22,208]
2023-02-16T17:20:34.712Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,1,22] - 208
2023-02-16T17:20:34.712Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":22}
2023-02-16T17:20:34.712Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2023-02-16T17:20:34.724Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,69,196,121,0,0,251]
2023-02-16T17:20:34.724Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,69,196,121,0,0,251]
2023-02-16T17:20:34.724Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 5 - 196 - [121,0,0] - 251
2023-02-16T17:20:34.724Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - srcRtgInd - {"dstaddr":121,"relaycount":0,"relaylist":[]}
2023-02-16T17:20:34.724Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2023-02-16T17:20:34.777Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,28,68,129,0,0,6,0,121,0,1,1,0,69,0,175,148,236,0,0,8,24,9,1,0,0,0,16,1,121,0,29,89]
2023-02-16T17:20:34.777Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,28,68,129,0,0,6,0,121,0,1,1,0,69,0,175,148,236,0,0,8,24,9,1,0,0,0,16,1,121,0,29,89]
2023-02-16T17:20:34.777Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 28 - 2 - 4 - 129 - [0,0,6,0,121,0,1,1,0,69,0,175,148,236,0,0,8,24,9,1,0,0,0,16,1,121,0,29] - 89
2023-02-16T17:20:34.779Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":6,"srcaddr":121,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":69,"securityuse":0,"timestamp":15504559,"transseqnumber":0,"len":8,"data":{"type":"Buffer","data":[24,9,1,0,0,0,16,1]}}
2023-02-16T17:20:34.780Z zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"transactionSequenceNumber":9,"manufacturerCode":null,"commandIdentifier":1},"Payload":[{"attrId":0,"status":0,"dataType":16,"attrData":1}],"Command":{"ID":1,"name":"readRsp","parameters":[{"name":"attrId","type":33},{"name":"status","type":32},{"name":"dataType","type":32,"conditions":[{"type":"statusEquals","value":0}]},{"name":"attrData","type":1000,"conditions":[{"type":"statusEquals","value":0}]}]}},"address":121,"endpoint":1,"linkquality":69,"groupID":0,"wasBroadcast":false,"destinationEndpoint":1}'
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I have this issue too and it has been happening only with Ikea bulbs, I have:
- 2 x LED1925G6
- 3 x LED2003G10
All of them have this disconnect between the state being published by Z2M and what the actual state of the bulb is.
At first I thought that my EZSP Sonoff dongle might be the culprit and so I switched to the dev branch of Z2M but the issue is till there. Also looking at the issues here it seems that it's affecting a bunch of different coordinators.
There's a few issues that have been opened that all describe the same problem:
#16484
#16685
Is someone looking into this? How can we help debug this?
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
This issue has been present for a while now and I honestly wouldn't know how to help in debugging it. I can replicate this both when turning on the bulbs on Home Assistant on the app and with voice commands coming from a Google Home.
I have found that when using voice commands if instead of asking "Turn on xxx" I ask "Set xxx to 100%" the light turns on normally.
I have this issue with the L1527 and LED1545G12. Multiple times a week the lamps are still on after a HA-automation (motion based) should have turned them off and even Z2M and HA report them to be off.
The other IKEA TRADFRI bulb I have, the LED1934G3_E27, seems not affected by this problem.
I have this issue with a few LED2003G10 bulbs. In my case turning off adaptive lighting seems to solve it. If this is the case it may have something to do with sending commands in quick succession causing the bulb to "get stuck"
@Mr-Quin interesting observation. I also use Adaptive lighting.
I use it with the default interval of 90 seconds between commands being sent to the lights, which doesn't seem that short of an interval. But I will try increasing the interval, maybe that helps.
I'm having this issue but I don't use Adaptive lighting so I think, at least in my case, it must be something else.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
Seeing the same with LED2005R5 bulbs too. I'm using adaptive lighting, but not on the affected bulbs. I'm pretty sure this has only started for me in the last 24h, after an extended power outage to a subset of the bulbs in my mesh.
Seeing the same with LED2005R5 bulbs too. I'm using adaptive lighting, but not on the affected bulbs. I'm pretty sure this has only started for me in the last 24h, after an extended power outage to a subset of the bulbs in my mesh.
Followup: actually I gave in and decided to re-pair all the affected lights. This seems to have resolved the problem for now - not sure it's a 'fix', but might be worth a try as a workaround.
Seeing the same with LED2005R5 bulbs too. I'm using adaptive lighting, but not on the affected bulbs. I'm pretty sure this has only started for me in the last 24h, after an extended power outage to a subset of the bulbs in my mesh.
Followup: actually I gave in and decided to re-pair all the affected lights. This seems to have resolved the problem for now - not sure it's a 'fix', but might be worth a try as a workaround.
I've tried this but I still experience issues. For instance when I turn on a LED1925G6 on Home Assistant it's displayed as having full brightness but in reality it turns on at minimum brightness. On LED2003G10 instead when I turn them on they are actually off unless I turn them off and back on or if I manually change their brightness. When this happens I also checked straight on Z2M, to exclude any issues with MQTT and HA, but the status of the bulbs is wrong.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
I can repeat here:
zigbee2mqtt/lamp/set/brightness <-- switch will switch on or off either
and
zigbee2mqtt/lamp/brightness/set <-- switch will not change on or off only the brightness value
On Off works better if I reload the state.
But the brightness doesn't stay at 0 if I send the command 0... It jump back to 1. That confusing me.
If you hit switch off to on the last known set value will be set for brightness. Not full brightness if you choose 50% before. That is important to know that also!
Can someone provide a short as possible debug log of this?
See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable debug logging.
Can someone provide a short as possible debug log of this?
See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable debug logging.
This is a short a log as I could. The devices I was testing were Bedroom Nightstand Hannah (0x94deb8fffeb313b0) andBedroom Nightstand Simone (0x94deb8fffe9dca64). I was simply turning the lights on on Home Assistant without touching their brightness. The lights report max brightness but in reality they turn on at minimum brightness and they stay like that until you force a brightness change. log.txt
@LookedPath thanks, I see the brightness is not set yet. I need to better understand when this exactly happens. Can you do the following sequence, after each command, let me know if the z2m state matches the actual state.
- Publish to
zigbee2mqtt/Bedroom Nightstand Simone/setpayload{"state":"ON", "brightness": 250} - Publish to
zigbee2mqtt/Bedroom Nightstand Simone/setpayload{"state":"OFF"} - Publish to
zigbee2mqtt/Bedroom Nightstand Simone/setpayload{"state":"ON"}
@Koenkk I ran the 3 commands and the state in z2m started matching reality right after the first one. The rest of the commands worked as intended. I noticed that this issue is only present after a while the bulbs have been off.
With the LED2003G10 it's even worse because when you just send an ON command they report to be on but in reality they are not. To have them actually turn on you can:
- Turn them off and then back on and then they'll be at their minimum brightness
- Change their brightness Even with these ones the issue appears only after a while they've been off.