IKEA Tradfri (LED2103G5) turns on when receiving off command if already off

[ianmtaylor1]

What happened?

Sorry for the grammatically confusing title, hopefully it will be clear below.

Sometimes I will send an "off" command to my bulb when the bulb is already off. This happens, for example, in home assistant scripts that turn off all the lights in a room when some lights are on but others are off, or if I press a smart button twice that turns off the light.

What did you expect to happen?

If the IKEA bulb is off, and I publish {"state": "OFF"} to zigbee2mqtt/My-Bulb-Name/set, the light will remain off.

How to reproduce it (minimal and precise)

1. Add IKEA Tradfri bulb (LED2103G5) to Zigbee2MQTT.
2. Update firmware to version 16777270 (Not sure if this is necessary or if this bug exists on old firmware.)
3. Turn bulb on.
4. Publish {"state": "OFF"} to zigbee2mqtt/My-Bulb-Name/set. Bulb turns off as expected.
5. Repeat step 4, publish another off message while bulb is already off. Bulb does not remain off, instead, it turns on at very low brightness.

Zigbee2MQTT version

1.36.0 commit: 86ed71c

Adapter firmware version

20210708

Adapter

SONOFF Zigbee 3.0 USB Dongle Plus ZBDongle-P

Setup

Official docker image on Raspberry Pi 3B+

Debug log

No response

[efab2022]

+1 I came to report the exact same behaviour for this other IKEA device LED2005R5_LED2106R3.

This issue also occurs when sending {"brightness": 0} repeatedly (the bulb toggles between off and on at low power). This issue also occurs when sending {"brightness": 1} repeatedly (the bulb toggles between off and on at low power). This issue does not occur for brightness 2 or greater (the bulb stays on)

In some circumstances, doing this repeatedly

tx ianmtaylor1

My setup

Zigbee2MQTT version

1.36.0-1

Adapter

ZigBee CC1352P-2

[ianmtaylor1]

I want to determine whether this is a bug with zigbee2mqtt or the IKEA devices themselves. I could pair the lightbulb with an IKEA hub coordinator, but I don't own one. I do have an IKEA somfrig button. Would binding those two devices bypass zigbee2mqtt and allow me to test whether the same problem exists when hitting the off button twice?

(Apologies if I'm using the terminology wrong, I'm new to zigbee)

[ianmtaylor1]

I have one non-update and one semi-update to this topic:

The non-update: I haven't had any luck binding my button to my bulb so I haven't been able to determine if the issue is with Zigbee2MQTT or with the bulb. I suspect if I had a Tradfri button instead of a Somrig button it would work better. If anyone else could test this kind of bulb outside of Zigbee2MQTT to see if the problem persists, that would be greatly appreciated.

The semi-update

While I haven't been able to resolve the issue, I have resolved an associated issue that has helped in my specific circumstances. In my case, these double-off messages were mostly occurring from an automation in Home Assistant triggered by my Somrig button, which for some reason was firing twice when pressed. I found out this was due to my having configured

advanced:
  output: 'attribute_and_json'

in Z2M's configuration.yaml. This was colliding device automations published to zigbee2mqtt/my-button/action with states, which, thanks to that configuration, were also being published to the same topic. I have set this option back to 'json' and my double-firing automation is fixed. I wish this conflict between attribute publishing and device_automations was better documented.

To be clear, though, the underlying problem with the bulb is still there. Following the steps outlined in this issue's first post will still result in the bulb turning back on at low brightness, contrary to expectation. I've just found a mitigation for my particular main use case.

[Furegato]

I'm having the same problem, but with IKEA's LED2111G6. (E14, RGB light bulb) For the past month or so whenever I got back home I would found that the two LED2111G6 bulbs I have were turned on at 1% brightness. It was hard to track what happened because it was showing that their state were off ... But after some digging I found out that my "Away from Home' automation was sending a "turn off" command which was triggering the problem you mention as well. Basically, yes, if I send a "turn lights off" command while they are off, they will turn back on at 1% brightness. One small finding... It will happen only once on a sequence of repeatedly "turn off" commands. For example: if I send another "turn off" while it is in this weird off-but-on state, it will turn it off and if I then send yet another "turn off" command, it will not present the same problem again. I know that sending 3 times a command to the light is not a viable workaround, but it might be a clue to what is happening. I hope someone with the skills can figure it out. It's really annoying not to be sure if you really turned off the lights. It kinda of defeats one of the most important features of a smart light. Cheers.

[GoodnessJSON]

I have this EXACT issue and it's driving me nuts. I can repeatedly send a Turn off Service call and toggle the bulb between off and 1%.

These bulbs are unusable in a bedroom setting because of this issue.

[TEF2one]

Same issue, was wondering why they would randomly turn on yet not show as turned on and finally noticed the relation with the off command waking them up... such a annoying issue after having replace all my light with these, I hope to find a solution.

[TEF2one]

Responding to a previous comment about using script to only sent the off command to lights turned on, isn't pratical: Yes I did think of that, but that won't work for groups, all my lights are in groups, I even have a global group in HA, so when I leave lights all turn off...

---

From: GoodnessJSON @.> Sent: 28 May 2024 23:49 To: Koenkk/zigbee2mqtt @.> Cc: TEF2one @.>; Manual @.> Subject: Re: [Koenkk/zigbee2mqtt] IKEA Tradfri (LED2103G5) turns on when receiving off command if already off (Issue #22030)

Same issue, was wondering why they would randomly turn on yet not show as turned on and finally noticed the relation with the off command waking them up... such a annoying issue after having replace all my light with these, I hope to find a solution.

I figured out that this happens if you ever turn a light off twice. On the second time around, it will be set to 1%.

This happens if you use Apple HomeKit scenes as it will send a turn off command even if the device is already off.

I swapped to HomeAssistant scripts (better than scenes) and put in an if condition to check if the light is on before triggering an off.

This solved my issue and I haven't had any issues since.

— Reply to this email directly, view it on GitHubhttps://github.com/Koenkk/zigbee2mqtt/issues/22030#issuecomment-2136232235, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEYWUKAAGEXFU4H3UZY2IDLZEUCY7AVCNFSM6AAAAABFSQ47HSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZWGIZTEMRTGU. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[heyiswas]

Exact same issue with LED2201G8.

[TEF2one]

FYI, I returned mine to IKEA, they are good with that... Instead I baught back some LEDVANCE SMART+ Classic A60 E27 Tunable white

[Koenkk]

@ianmtaylor1 could you provide the debug log of this with z2m 1.38.0?

See this on how to enable debug logging.

[ianmtaylor1]

@Koenkk Thanks for your reply. I've attached a snip of the debug log file while experiencing the issue. Please let me know if I've omitted anything or if you need any other information.

Z2m Version: 1.38.0 commit fe048e6 Tradfri firmware version: 1.0.36, build date 20230918 Device name: Ian's Bedside Lamp

Logs start with a command to turn the light on (line 1, [2024-06-15 12:23:55]), followed by a command to turn the light off which works as expected (line 30, [2024-06-15 12:24:07]), then a second command to turn the light off which reproduces the issue (line 81, [2024-06-15 12:24:11]).

Hope this helps!

debug_log_snip.txt

[ianmtaylor1]

One small finding... It will happen only once on a sequence of repeatedly "turn off" commands. For example: if I send another "turn off" while it is in this weird off-but-on state, it will turn it off and if I then send yet another "turn off" command, it will not present the same problem again.

This is interesting, and different from the behavior of my Tradfri bulb. If I send repeated off commands, the bulb will alternate off, 1%, off, 1%, ... etc. repeatedly.

[GoodnessJSON]

One small finding... It will happen only once on a sequence of repeatedly "turn off" commands. For example: if I send another "turn off" while it is in this weird off-but-on state, it will turn it off and if I then send yet another "turn off" command, it will not present the same problem again.

This is interesting, and different from the behavior of my Tradfri bulb. If I send repeated off commands, the bulb will alternate off, 1%, off, 1%, ... etc. repeatedly.

What you're describing is exactly what is described here - https://www.reddit.com/r/homeassistant/s/6eyx8rcTfA

The fix was to add an if check to detect if the bulb is ON, before sending a turn off command.

[Furegato]

Unfortunately, your suggestion is not a real solution.... The problem is, let's say you are going to sleep and want to make sure all lights are off... You would say to Google Home/Alexa/Siri... "Turn all lights off"... Then those pesky lights would actually turn on and worst of all, it does not show on their status... So you would have them on the whole night. Or in case(like me) you have a presence automation by an "external" assistant to when you leave home... You would have to treat those lights independently. Anyway, a complete unnecessary nuisance to have to deal.

On Mon, 17 Jun 2024, 01:23 GoodnessJSON, @.***> wrote:

One small finding... It will happen only once on a sequence of repeatedly "turn off" commands. For example: if I send another "turn off" while it is in this weird off-but-on state, it will turn it off and if I then send yet another "turn off" command, it will not present the same problem again.

This is interesting, and different from the behavior of my Tradfri bulb. If I send repeated off commands, the bulb will alternate off, 1%, off, 1%, ... etc. repeatedly.

What you're describing is exactly what is described here - https://www.reddit.com/r/homeassistant/s/6eyx8rcTfA

The fix was to add an if check to detect if the bulb is ON, before sending a turn off command.

— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/22030#issuecomment-2171959470, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJF5HJIOU7ETIPZFFVXL5EDZHYUBXAVCNFSM6AAAAABFSQ47HSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZRHE2TSNBXGA . You are receiving this because you commented.Message ID: @.***>

[GoodnessJSON]

Unfortunately, your suggestion is not a real solution....

I completely agree and I'd like a full fix too. What you've described for non-status aware processes is something I've run into as well.

I'm just saying that it's related to sending two OFF commands consecutively to the globe.

It's a bug seemingly in the bulbs firmware, but I'm wondering if Z2M can somehow handle it.

[tungmeister]

also seeing this behavior, it's really annoying as I've 10 GU10 bulbs that come on differently depending on whats happening in the room so I'll often find half of them on at 1% when they're meant to be all off.

[legsim]

Can confirm it happens with LED2111G6.

It seems that it only happens when a custom transition time is set in device settings. Maybe some firmware issue when handling genLevelCtrl.moveToLevelWithOnOff?

[Koenkk]

In your configuration.yaml (or devices.yaml if present), do you have a transition set for this device?

[GoodnessJSON]

In your configuration.yaml (or devices.yaml if present), do you have a transition set for this device?

I set mine to 0 seconds in Z2M UI Settings page since this apparently is meant to help, but it made no difference.

The only fix I've had for this issue is checking if the light is ON, before triggering an OFF. If I send a 'Turn Off' twice, then it will be stuck in a semi on state.

Here's an example image from Reddit that also shows it. It would be super appreciated if a fix could be put in for this. It's extremely annoying and breaks a lot of the ease of use of these lights in HA.

[Koenkk]

Can you try to completely remove it? (stop z2m, remove transition from the configuration.yaml, start z2m)

[ianmtaylor1]

In your configuration.yaml (or devices.yaml if present), do you have a transition set for this device?

Can you try to completely remove it? (stop z2m, remove transition from the configuration.yaml, start z2m)

I had transition: 0 set in my devices.yaml for this device. I removed it, following your instructions, and the problem is no longer there. Publishing {"state": "off"} twice in a row to zigbee2mqtt/Ian's Bedside Lamp/set leaves the light off as expected.

Just FYI, now the light transitions for ~1sec between the on and off states (default transition time?). This is very minor and acceptable to me because it fixes the other problem.

[Furegato]

Can you try to completely remove it? (stop z2m, remove transition from the configuration.yaml, start z2m)

That actually worked for me as well! Thanks for the suggestion! Just setting the transition to 0 was making it even worse, but by deleting it completely from z2mqtt devices.yaml worked like a charm!

[GoodnessJSON]

Can you try to completely remove it? (stop z2m, remove transition from the configuration.yaml, start z2m)

Can confirm, this worked for me too! No more 1%. Fantastic!

[heyiswas]

Can you try to completely remove it? (stop z2m, remove transition from the configuration.yaml, start z2m)

Works for LED2201G8. Thanks :)

[GoodnessJSON]

Can you try to completely remove it? (stop z2m, remove transition from the configuration.yaml, start z2m)

@Koenkk could we formally include this in a fix to Z2M? As it may not be immediately obvious that this is the solution to this problem.

Thanks for such a great suggestion, everything has been great since!

[tungmeister]

Unfortunately, this isn't a proper fix. I'm using the transition value within my groups.yaml, without defining it here groups hard cut on/off. Looking through the posts this appears to be affecting multiple ikea models and FW versions (I'm on 3.0.10 and I've seen mention of 1.0.36). I'm guessing this is down to the new variants that have been introduced over the last 6 months or so, I'm seeing this with LED2106R3 but not LED2005R5. I've had the latter for a couple of years now without issue, the problem is only present on LED2106R3, the new version of this bulb. @Koenkk could this be a converter issue?

[Koenkk]

This is not a converter issue but a bug in the bulbs firmware, it seems to turn on when receiving a "move to brightness 0 twice"

[GoodnessJSON]

This is not a converter issue but a bug in the bulbs firmware, it seems to turn on when receiving a "move to brightness 0 twice"

Can I ask why removing the transition fields worked to fix the issue then? @Koenkk

[Koenkk]

If you remove the transition, instead of a "move to brightness 0 with transition 0", it will send the native off command

[ianmtaylor1]

Thanks for clarifying! Do you think a note about this side-effect should be included in the documentation page for each affected device (i.e., here)?

If so, could you clarify the default value for transition? It's stated that it's zero. I don't know if that's true, though, because the behavior with transition: 0 is different than with transition unspecified, and with transition unspecified there is a noticeable transition time.

I'd be happy to make a pull request.

As an aside, I performed a few more tests that others are welcome to also replicate:

• The bug also occurs with no transition set in devices.yaml, but with publishing {"state":"off", "transition":0}.
• Nonzero transition times also exhibit the bug, but slightly differently. My bulb will only unexpectedly turn on once, with repeated {"state":"off"} commands sent. With a 0 second transition, my bulb would repeatedly cycle on and off.

[GoodnessJSON]

As an aside, I performed a few more tests that others are welcome to also replicate:

This is the same bug described isn't it? Whether you set the transition at the device, group or the action level it will have the same result and trigger the bug.

You can't have a transition set for turn OFF actions. Turn ON transitions are fine however.

[Koenkk]

Does it work when leaving the transition empty in the frontend? e.g.

[Midifreakz]

@Koenkk leaving it blank in the frontend does not help. there is no entry in config.yaml when i leave it blanc, but the lights still seem to respond to my previously set delay.

[Furegato]

Does it work when leaving the transition empty in the frontend? e.g.

Yes! I can confirm that leaving the "transition" field empty and confirming it fixes the problem since it completely removes the "transition=X" line from the devices.yaml Cheers!

[Midifreakz]

Maybe some extra information. I only seem to have this problem wen utilising the off command in the scope of a larger automation. When I just send the one command twice. The lights just stay off.

[Furegato]

Just to be sure, I've double-checked it and it seems to fix it on my side if I leave the device's zigbee2mqtt transition field empty. With transition=0 and 1 I had the erroneous behaviour, with the transition field empty the problem is gone either by calling "lights off" individually or in a group. It only causes problems if I send a "lights off" command with any transition value data, as other people have already mentioned. Model: LED2111G6

[Midifreakz]

I am not able to remove the transition even though the field in config.yaml is gone. If anyone is using Z2M in Home Assistant, creating an automation like the screenshot below is a good temp fix that ensures your light is always off until this issue is resolved.

[tungmeister]

My bulbs are all showing an update, currently doing he OTA, will see if it makes any difference.

[GoodnessJSON]

My bulbs are all showing an update, currently doing he OTA, will see if it makes any difference.

I see it as well, would love to know! IKEA release notes say it's to 'Update to support new product revisions'.

My older IKEA bulbs don't have this update, just the version with the issue. Fingers crossed, let us know how you go!

[GoodnessJSON]

I can confirm that the latest firmware 3.0.21 does NOT fix the issue. If you turn off the light with a transition set, it will trigger the 1% brightness bug.

[alex3305]

I also experience this as mentioned by @Koenkk in the referenced (and now closed) issue with IKEA LED1842G3 after updating to the newest 1.1.4 firmware. Ironically I had set a numerical value for transition to mitigate or workaround #19211.

[stevelee916a]

Seems like this has been a small but recurring issue for years? Skimming through the threads, it’s not clear to me whether this is a homebridge, ha, or z2mqtt issue

Homebridge bug thread (closed but not resolved): https://github.com/homebridge/homebridge/issues/3073

homebridge-z2mqtt bug thread (also closed but not resolved): https://github.com/itavero/homebridge-z2m/issues/383

zigbee2mqtt bug thread (closed but not resolved): https://github.com/Koenkk/zigbee2mqtt/issues/10409

home assistant thread: https://github.com/home-assistant/core/issues/104643

[GoodnessJSON]

Seems like this has been a small but recurring issue for years? Skimming through the threads, it’s not clear to me whether this is a homebridge, ha, or z2mqtt issue

I would say this is on the Z2M side, as I get the issue when managing the lights from Z2M directly, before they are even added to Homebridge.

This is without any involvement from HA, Homebridge or anything else. If you manage them directly from Z2M you get the issue when transition is set (even if 0).

[Koenkk]

@GoodnessJSON

If you manage them directly from Z2M you get the issue when transition is set (even if 0).

You should not set any transition (with 0 you will get this issue)

[GoodnessJSON]

@GoodnessJSON

If you manage them directly from Z2M you get the issue when transition is set (even if 0).

You should not set any transition (with 0 you will get this issue)

Yes correct, and it now works for me. Thanks for pointing that out a few comments up.

In my opinion though the transition setting should be removed for 2201XX and 2203XX models as it's broken and potentially misleading.

It's not very evident that it's the source of the issue and therefore how to fix it.

If it can't be set at all without glitching the globes, it should be removed until the firmware is patched.

[Koenkk]

I've fixed the issue, the transition will now always be ignored for the following models: LED2103G5, LED1842G3 and LED2201G8 (let me know if this fix should be applied to more)

Changes will be available in the dev branch in a few hours from now.

[ipha]

I've fixed the issue, the transition will now always be ignored for the following models: LED2103G5, LED1842G3 and LED2201G8 (let me know if this fix should be applied to more)

Changes will be available in the dev branch in a few hours from now.

LED2107C4 and LED1949C5 (on fw 1.1.20 but not 1.1.003.) have the same issue.

[GoodnessJSON]

I've fixed the issue, the transition will now always be ignored for the following models: LED2103G5, LED1842G3 and LED2201G8 (let me know if this fix should be applied to more)

Amazing, thanks for setting this. I also had the issue with LED1925G6 and confirmed the transition fix when manually removing it.

Appreciate you looking at this.

[Midifreakz]

Hi Koen,

The issue is also happening on the GU10 bulbs. I can testify for the newer models

LED1923R5 LED2005R5/LED2106R3 LED2104R3

[Koenkk]

Added!

Changes will be available in the dev branch in a few hours from now.