search

Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.88k stars 1.66k forks source link

IKEA Bulbs doesn't seem to have correct state to reality #16388

Open samip5 opened 1 year ago

samip5 commented 1 year ago

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:

LED1624G9 LED1732G11

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

log1.txt

merlinschumacher commented 1 year ago

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!

merlinschumacher commented 1 year ago

16484 seems to be a similar issue

samip5 commented 1 year ago

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

TB-SE commented 1 year ago

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

merlinschumacher commented 1 year ago

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.

samip5 commented 1 year ago

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}'
github-actions[bot] commented 1 year ago

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

samip5 commented 1 year ago

It's still an issue that probably would need to be looked at.

LookedPath commented 1 year ago

I have this issue too and it has been happening only with Ikea bulbs, I have:

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?

github-actions[bot] commented 1 year ago

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

LookedPath commented 1 year ago

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.

Gizzje commented 1 year ago

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.

Mr-Quin commented 1 year ago

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"

Gizzje commented 1 year ago

@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.

LookedPath commented 1 year ago

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.

samip5 commented 1 year ago

I also don't use adaptive lightning.

github-actions[bot] commented 1 year ago

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

rnorth commented 1 year ago

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.

rnorth commented 1 year ago

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.

LookedPath commented 1 year ago

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.

github-actions[bot] commented 1 year ago

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

merlinschumacher commented 1 year ago

Still an issue. Commenting for the bot

github-actions[bot] commented 1 year ago

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

merlinschumacher commented 1 year ago

Still an issue, dear bot.

legalgig commented 1 year ago

I'm experiencing the same issue with LED2004G8

Wikibear commented 1 year ago

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!

Koenkk commented 1 year ago

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.

LookedPath commented 12 months ago

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

Koenkk commented 12 months ago

@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.

LookedPath commented 12 months ago

@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:

Koenkk commented 12 months ago

So what is the sequence to trigger the issue?

LookedPath commented 12 months ago

Correct, the sequence is exactly like the one you outlined. I'm not sure on how long you need to wait before the problem starts showing up but I can try finding out.

Koenkk commented 12 months ago

but I can try finding out.

Please do, it would be very strange if only the change in time causes this.

legalgig commented 11 months ago

I tried to investigate this issue a little further and found out one thing. After setting report option to true in advanced settings the bulb changes it's state from off to on after exactly 5mins. Zigbee2mqtt is showing that the state change came from one of the bulbs.

Received Zigbee message from 'dummy-bulb-2', type 'attributeReport', cluster 'genOnOff', data '{"onOff":1}' from endpoint 1 with groupID 0

btw. I have two same bulbs in one group Bulbs model: LED2004G8

MRobi1 commented 10 months ago

Just chiming in to say I've got the same issue with 3 LED2003G10 bulbs.

For me I've got a motion automation in HA that turns the lights on/off. They turn on reliably, however the light itself often stays on while reporting a state of off in both HA and Z2M. I say often because I'd say roughly 50% of the time it works properly.

davidorlea commented 10 months ago

Just to provide some context since some of you mentioned the Adaptive Lighting component of Home Assistant: IKEA Tradfri lights might be unresponsive and report erroneous states due to dropped commands during ongoing (color) transitions!

For reference: https://github.com/basnijholt/adaptive-lighting#bulb-bulb-specific-issues

MRobi1 commented 10 months ago

Great data point. However I don't think it's the root cause of the issue. I was a few days before setting up adaptive lighting in this area and had the issue right from adding the bulbs onto the network. There are also a few above who aren't using it at all. However I will hapilly implement these recommendations and see if it makes any difference!

Stooovie commented 10 months ago

Same issue, IKEA LED2003G10 - state not correctly reflected in dashboard and bulbs turning on by binding even when only LevelCtrl is bound.

MRobi1 commented 10 months ago

For reference: https://github.com/basnijholt/adaptive-lighting#bulb-bulb-specific-issues I made these adjustments to my adaptive lighting config. It did not completely solve the issue, but I've gone from working properly about 50% of the time to probably around 98% of the time. I've only noticed the lights staying on while in the wrong state maybe once or twice in the past week. It's been a significant and noticeable improvement.

yschen5812 commented 9 months ago

Same with my ikea L1529 panels, the dashboard doesn't reflect the states of them. I have two of them and behave the same. Plus some other problems that the lights are randomly triggered, and when that happened I couldn't find anything in the logs regarding that event. I assume it's some zigbee binding that is not accessible via the zigbee2mqtt dashboard. I have a couple aqara motion sensors around so maybe there are some unwanted binding.

legalgig commented 9 months ago

After reading of some other issues with IKEA bulbs I think I've found the issue! I have 2x LED2004G8 which were grouped in zigbee2mqtt. I've removed that group and set Transition to 0 for all bulbs (I've grouped them in Home Assistant). It seems to be working reliably for the past 4 days

psi-4ward commented 6 months ago

Similar problem here with L1528 v2.3.087

Switched the panel off and update the state: receives on but is actually off

Debug 2024-04-03 19:03:32Received MQTT message on 'z2m/Küche Decke/get' with data '{"state":""}'
Debug 2024-04-03 19:03:32Publishing get 'get' 'state' to 'Küche Decke'
Debug 2024-04-03 19:03:32Received Zigbee message from 'Küche Decke', type 'readResponse', cluster 'genOnOff', data '{"onOff":1}' from endpoint 1 with groupID 0
Info 2024-04-03 19:03:32MQTT publish: topic 'z2m/Küche Decke', payload '{"brightness":254,"color_mode":"color_temp","color_options":null,"color_temp":250,"last_seen":"2024-04-03T19:03:32+02:00","level_config":{"on_level":"previous"},"linkquality":120,"power_on_behavior":"off","state":"ON","update":{"installed_version":587757105,"latest_version":587757105,"state":"idle"},"update_available":null}'
Info 2024-04-03 19:03:32MQTT publish: topic 'z2m/Küche Decke/color_mode', payload 'color_temp'
Info 2024-04-03 19:03:32MQTT publish: topic 'z2m/Küche Decke/state', payload 'ON'
github-actions[bot] commented 3 days ago

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days