Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IKEA lamps turn off always with default transition in Z2M 1.40.0 #23825

Closed
GioMez opened this issue Sep 3, 2024 · 32 comments
Closed

IKEA lamps turn off always with default transition in Z2M 1.40.0 #23825

GioMez opened this issue Sep 3, 2024 · 32 comments
Labels
problem Something isn't working

Comments

@GioMez
Copy link

GioMez commented Sep 3, 2024

What happened?

Since Z2M 1.40.0, all my Ikea lamps turn off with default transition of 1s. Changing the value of the transition has no effect.
In the debug logs (below) there is the line: Supressing OFF transition since entity has noOffTransition=true

What did you expect to happen?

Lamps should turn off with the desired transition time.

How to reproduce it (minimal and precise)

Turn on an Ikea lamp and it will turn on with the desired time in second. Turn off the light: it will turn off with a transition of (approximately) 1 second, whatever value is set

Zigbee2MQTT version

1.40.0

Adapter firmware version

7.4.4 [GA]

Adapter

ember

Setup

Add-on on Home Assistant OS

Debug log

[2024-09-03 09:56:21] debug: z2m:mqtt: Received MQTT message on 'zigbee2mqtt/0x3c2ef5fffeeee469/set' with data '{"state":"ON","transition":10.0,"brightness":223}'
[2024-09-03 09:56:21] debug: z2m: Publishing 'set' 'brightness' to '0x3c2ef5fffeeee469'
[2024-09-03 09:56:21] debug: zh:controller:endpoint: ZCL command 0x3c2ef5fffeeee469/1 genLevelCtrl.moveToLevelWithOnOff({"level":223,"transtime":100}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false})
[2024-09-03 09:56:21] debug: zh:ember: ~~~> [ZCL to=27191 apsFrame={"profileId":260,"clusterId":8,"sourceEndpoint":1,"destinationEndpoint":1,"options":4416,"groupId":0,"sequence":0} header={"frameControl":{"reservedBits":0,"frameType":1,"direction":0,"disableDefaultResponse":false,"manufacturerSpecific":false},"transactionSequenceNumber":10,"commandIdentifier":4}]
[2024-09-03 09:56:21] debug: zh:ember:ezsp: ===> [FRAME: ID=52:"SEND_UNICAST" Seq=64 Len=27]
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: ---> FRAME type=DATA frmTx=0 frmRx=0
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=1](ackRx=0 frmTx=1)
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- FRAME type=DATA ackNum=1 frmNum=0 Added to rxQueue
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: ---> FRAME type=ACK frmRx=1
[2024-09-03 09:56:21] debug: zh:ember:ezsp: <=== [FRAME: ID=52:"SEND_UNICAST" Seq=64 Len=7]
[2024-09-03 09:56:21] debug: zh:ember:ezsp: ~~~> [SENT type=DIRECT apsSequence=45 messageTag=27 status=OK]
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=1](ackRx=1 frmTx=1)
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- FRAME type=DATA ackNum=1 frmNum=1 Added to rxQueue
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: ---> FRAME type=ACK frmRx=2
[2024-09-03 09:56:21] debug: zh:ember:ezsp: <=== [CBFRAME: ID=89:"INCOMING_ROUTE_RECORD_HANDLER" Seq=64 Len=20]
[2024-09-03 09:56:21] debug: zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=27191], [sourceEui=0x3c2ef5fffeeee469], [lastHopLqi=120], [lastHopRssi=-70], [relayCount=1], [relayList=19473]
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=1](ackRx=1 frmTx=1)
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- FRAME type=DATA ackNum=1 frmNum=2 Added to rxQueue
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: ---> FRAME type=ACK frmRx=3
[2024-09-03 09:56:21] debug: zh:ember:ezsp: <=== [CBFRAME: ID=89:"INCOMING_ROUTE_RECORD_HANDLER" Seq=64 Len=20]
[2024-09-03 09:56:21] debug: zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=27191], [sourceEui=0x3c2ef5fffeeee469], [lastHopLqi=120], [lastHopRssi=-70], [relayCount=1], [relayList=19473]
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=1](ackRx=1 frmTx=1)
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- FRAME type=DATA ackNum=1 frmNum=3 Added to rxQueue
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: ---> FRAME type=ACK frmRx=4
[2024-09-03 09:56:21] debug: zh:ember:ezsp: <=== [CBFRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=64 Len=30]
[2024-09-03 09:56:21] debug: zh:ember:ezsp: ezspIncomingMessageHandler(): callback called with: [type=UNICAST], [apsFrame={"profileId":260,"clusterId":8,"sourceEndpoint":1,"destinationEndpoint":1,"options":320,"groupId":0,"sequence":55}], [packetInfo:{"senderShortId":27191,"senderLongId":"0xFFFFFFFFFFFFFFFF","bindingIndex":255,"addressIndex":255,"lastHopLqi":116,"lastHopRssi":-71,"lastHopTimestamp":0}], [messageContents=080a0b0400]
[2024-09-03 09:56:21] debug: zh:controller: Received payload: clusterID=8, address=27191, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=116, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":10,"commandIdentifier":11},"payload":{"cmdId":4,"statusCode":0},"command":{"ID":11,"name":"defaultRsp","parameters":[{"name":"cmdId","type":32},{"name":"statusCode","type":32}]}}
[2024-09-03 09:56:21] debug: z2m: Publishing 'set' 'transition' to '0x3c2ef5fffeeee469'
[2024-09-03 09:56:21] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/0x3c2ef5fffeeee469', payload '{"brightness":223,"color":{"x":0.3804,"y":0.3767},"color_mode":"color_temp","color_options":null,"color_temp":250,"color_temp_startup":65535,"level_config":{"on_level":"previous"},"linkquality":116,"power_on_behavior":"previous","state":"ON","update":{"installed_version":16777272,"latest_version":16777272,"state":"idle"},"update_available":false}'
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=1](ackRx=1 frmTx=1)
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: <--- FRAME type=DATA ackNum=1 frmNum=4 Added to rxQueue
[2024-09-03 09:56:21] debug: zh:ember:uart:ash: ---> FRAME type=ACK frmRx=5
[2024-09-03 09:56:21] debug: zh:ember:ezsp: <=== [CBFRAME: ID=63:"MESSAGE_SENT_HANDLER" Seq=64 Len=22]
[2024-09-03 09:56:21] debug: zh:ember:ezsp: ezspMessageSentHandler(): callback called with: [status=OK], [type=DIRECT], [indexOrDestination=27191], [apsFrame={"profileId":260,"clusterId":8,"sourceEndpoint":1,"destinationEndpoint":1,"options":4416,"groupId":0,"sequence":45}], [messageTag=27]

[2024-09-03 09:57:37] debug: z2m:mqtt: Received MQTT message on 'zigbee2mqtt/0x3c2ef5fffeeee469/set' with data '{"state":"OFF","transition":10.0}'
[2024-09-03 09:57:37] debug: z2m: Publishing 'set' 'transition' to '0x3c2ef5fffeeee469'
[2024-09-03 09:57:37] debug: z2m: Publishing 'set' 'state' to '0x3c2ef5fffeeee469'
[2024-09-03 09:57:37] debug: zhc:tz: Supressing OFF transition since entity has noOffTransition=true
[2024-09-03 09:57:37] debug: zh:controller:endpoint: ZCL command 0x3c2ef5fffeeee469/1 genOnOff.off({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false})
[2024-09-03 09:57:37] debug: zh:ember: ~~~> [ZCL to=27191 apsFrame={"profileId":260,"clusterId":6,"sourceEndpoint":1,"destinationEndpoint":1,"options":4416,"groupId":0,"sequence":0} header={"frameControl":{"reservedBits":0,"frameType":1,"direction":0,"disableDefaultResponse":false,"manufacturerSpecific":false},"transactionSequenceNumber":11,"commandIdentifier":0}]
[2024-09-03 09:57:37] debug: zh:ember:ezsp: ===> [FRAME: ID=52:"SEND_UNICAST" Seq=68 Len=24]
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: ---> FRAME type=DATA frmTx=4 frmRx=3
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=5](ackRx=4 frmTx=5)
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- FRAME type=DATA ackNum=5 frmNum=3 Added to rxQueue
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: ---> FRAME type=ACK frmRx=4
[2024-09-03 09:57:37] debug: zh:ember:ezsp: <=== [FRAME: ID=52:"SEND_UNICAST" Seq=68 Len=7]
[2024-09-03 09:57:37] debug: zh:ember:ezsp: ~~~> [SENT type=DIRECT apsSequence=49 messageTag=31 status=OK]
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=5](ackRx=5 frmTx=5)
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- FRAME type=DATA ackNum=5 frmNum=4 Added to rxQueue
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: ---> FRAME type=ACK frmRx=5
[2024-09-03 09:57:37] debug: zh:ember:ezsp: <=== [CBFRAME: ID=89:"INCOMING_ROUTE_RECORD_HANDLER" Seq=68 Len=20]
[2024-09-03 09:57:37] debug: zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=27191], [sourceEui=0x3c2ef5fffeeee469], [lastHopLqi=224], [lastHopRssi=-44], [relayCount=1], [relayList=17926]
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=5](ackRx=5 frmTx=5)
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- FRAME type=DATA ackNum=5 frmNum=5 Added to rxQueue
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: ---> FRAME type=ACK frmRx=6
[2024-09-03 09:57:37] debug: zh:ember:ezsp: <=== [CBFRAME: ID=89:"INCOMING_ROUTE_RECORD_HANDLER" Seq=68 Len=20]
[2024-09-03 09:57:37] debug: zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=27191], [sourceEui=0x3c2ef5fffeeee469], [lastHopLqi=224], [lastHopRssi=-44], [relayCount=1], [relayList=17926]
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=5](ackRx=5 frmTx=5)
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- FRAME type=DATA ackNum=5 frmNum=6 Added to rxQueue
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: ---> FRAME type=ACK frmRx=7
[2024-09-03 09:57:37] debug: zh:ember:ezsp: <=== [CBFRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=68 Len=30]
[2024-09-03 09:57:37] debug: zh:ember:ezsp: ezspIncomingMessageHandler(): callback called with: [type=UNICAST], [apsFrame={"profileId":260,"clusterId":6,"sourceEndpoint":1,"destinationEndpoint":1,"options":320,"groupId":0,"sequence":56}], [packetInfo:{"senderShortId":27191,"senderLongId":"0xFFFFFFFFFFFFFFFF","bindingIndex":255,"addressIndex":255,"lastHopLqi":224,"lastHopRssi":-44,"lastHopTimestamp":0}], [messageContents=080b0b0000]
[2024-09-03 09:57:37] debug: zh:controller: Received payload: clusterID=6, address=27191, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=224, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":11,"commandIdentifier":11},"payload":{"cmdId":0,"statusCode":0},"command":{"ID":11,"name":"defaultRsp","parameters":[{"name":"cmdId","type":32},{"name":"statusCode","type":32}]}}
[2024-09-03 09:57:37] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/0x3c2ef5fffeeee469', payload '{"brightness":223,"color":{"x":0.3804,"y":0.3767},"color_mode":"color_temp","color_options":null,"color_temp":250,"color_temp_startup":65535,"level_config":{"on_level":"previous"},"linkquality":224,"power_on_behavior":"previous","state":"OFF","update":{"installed_version":16777272,"latest_version":16777272,"state":"idle"},"update_available":false}'
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=5](ackRx=5 frmTx=5)
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: <--- FRAME type=DATA ackNum=5 frmNum=7 Added to rxQueue
[2024-09-03 09:57:37] debug: zh:ember:uart:ash: ---> FRAME type=ACK frmRx=0
[2024-09-03 09:57:37] debug: zh:ember:ezsp: <=== [CBFRAME: ID=63:"MESSAGE_SENT_HANDLER" Seq=68 Len=22]
[2024-09-03 09:57:37] debug: zh:ember:ezsp: ezspMessageSentHandler(): callback called with: [status=OK], [type=DIRECT], [indexOrDestination=27191], [apsFrame={"profileId":260,"clusterId":6,"sourceEndpoint":1,"destinationEndpoint":1,"options":4416,"groupId":0,"sequence":49}], [messageTag=31]

@GioMez GioMez added the problem Something isn't working label Sep 3, 2024
@Koenkk
Copy link
Owner

Koenkk commented Sep 3, 2024

  • Did this work pre 1.40.0?
  • Could you provide a screenshot of the device about page?

@GioMez
Copy link
Author

GioMez commented Sep 3, 2024

  • Did this work pre 1.40.0?

Yes, the issue appeared after I updated Z2M two days ago. Could it be related to ##22030 ?

  • Could you provide a screenshot of the device about page?

image
image
EDIT 05/09/24: Removed wrong screenshot

I also have Philips Hue bulbs, which are not affected by this problem. Unless they are in a group with Ikea ones: in that case every lamp turns off with default settings, ignoring custom transitions given through MQTT set.

@Koenkk
Copy link
Owner

Koenkk commented Sep 4, 2024

@heyiswas in #22030 (comment) you commented you also have this issue with LED2201G8, could you provide a screenshot of the device about page? I'm trying to figure out why the off transition doesn't work on your LED2201G8 but works on the LED2201G8 from @GioMez

@heyiswas
Copy link

heyiswas commented Sep 4, 2024

@heyiswas in #22030 (comment) you commented you also have this issue with LED2201G8, could you provide a screenshot of the device about page? I'm trying to figure out why the off transition doesn't work on your LED2201G8 but works on the LED2201G8 from @GioMez

image

Seems to be the same bulb. I also installed the latest zigbee2mqtt update 1.40.0 and setting a transition doesn't affect the bulbs off state anymore. 🙂

@Koenkk
Copy link
Owner

Koenkk commented Sep 5, 2024

@GioMez can you double check that Lampada Esterna Balcone does not have the off transition bug with z2m 1.39.1? It's very strange that this worked for you while it doesn't for others.

@maleadt
Copy link

maleadt commented Sep 5, 2024

I'm having the same issue; recently the following bulb started to ignore transitions, with the same Supressing OFF transition since entity has noOffTransition=true in the logs:

image

I haven't been able to check whether it's the exact upgrade to 1.40 that broke this (downgrading to 1.39 breaks on start-up during AdapterBackup.getStoredBackup with an out-of-bounds read).

Koenkk added a commit to Koenkk/zigbee-herdsman-converters that referenced this issue Sep 5, 2024
@Koenkk
Copy link
Owner

Koenkk commented Sep 5, 2024

@maleadt fixed it for this bulb (previously transition where ignored for 1.0.012 +, now for 1.0.021+

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

@maleadt
Copy link

maleadt commented Sep 5, 2024

Thanks!

Reading through the issue that prompted that change in the first place, I guess it's better to implement my off transition in two steps, first transitioning to the lowest brightness, and then turning the bulb off without a transition?

@Koenkk
Copy link
Owner

Koenkk commented Sep 5, 2024

@maleadt no because the issue is not present on 1.x firmwares it seems.

@supaeasy
Copy link

supaeasy commented Sep 5, 2024

When will changes from dev make it into the stable release?

@GioMez
Copy link
Author

GioMez commented Sep 5, 2024

@GioMez can you double check that Lampada Esterna Balcone does not have the off transition bug with z2m 1.39.1? It's very strange that this worked for you while it doesn't for others.

I'm sorry, my mistake! I took a screenshot of the wrong device... the correct one was Lampada Scale (pianerottolo), completely identical to Lampada Scale (primo piano) (LED1836G9).

About LED2201G8 honeslty I don't remember ever turning off that bulb twice in a row, so I can't say that there was the problem reported in #22030, but there surely was in LED2109G6 (Lampada Sala TV) and with 1.40.0 has been fixed.

@Koenkk
Copy link
Owner

Koenkk commented Sep 5, 2024

@GioMez so all of your Ikea bulbs on which the off transition works are on firmware 1.x.x or 2.x.x? If yes, then I will only disable the onoff transition for 3.x.x

@GioMez
Copy link
Author

GioMez commented Sep 5, 2024

@GioMez so all of your Ikea bulbs on which the off transition works are on firmware 1.x.x or 2.x.x? If yes, then I will only disable the onoff transition for 3.x.x

Sorry for the delay. I've checked and, sadly, the same issue happens also in LED2201G8 with 3.0.22: it turns on with a transition of X seconds (depending on what you send in set command), but turns off always almost instantly.

To sum up:

Before 1.40.0

After 1.40.0

@Koenkk
Copy link
Owner

Koenkk commented Sep 6, 2024

Issue #22030 present AT LEAST on LED2109G6 with 1.0.38 firmware.

On what other bulbs is this issue also present? Note that we cannot fix both the off transition and the bulbs turning on again when sending off twice.

@Toph92
Copy link

Toph92 commented Sep 7, 2024

Same problem (no transition during turn off) here with 1.40.0, 1.40.1 and latest-dev on docker.
Affected bulbs:
IKEA LED2107C4 firm 3.0.21
IKEA LED1623G12 firm 2.3.094
IKEA LED1736G9 firm 2.3.087

Ok with Philips 9290024693

Works on my old server:
[2024-08-30 13:08:52] info: z2m: Starting Zigbee2MQTT version 1.37.1 (commit #cda867a3)
[2024-08-30 13:08:52] info: z2m: Starting zigbee-herdsman (0.46.6)

Thanks.

@GioMez
Copy link
Author

GioMez commented Sep 8, 2024

Issue #22030 present AT LEAST on LED2109G6 with 1.0.38 firmware.

LED2109G6 was the only in which I saw the issue #22030 (now fixed with 1.40.0+).

Note that we cannot fix both the off transition and the bulbs turning on again when sending off twice.

Yes, I know. I hope someone at Ikea fixes the double turn off bug in the firmware, since the original problem is there.
I'm modifying all the automations to make them fade out the lamps up to 1% and then turn them off (thanks @maleadt for the idea!).
Could it be functional to let the user have the option to enable/disable noOffTransition via GUI/config file?

@muddy79
Copy link

muddy79 commented Sep 10, 2024

I'm sorry, but I've never experienced "original" issue with lights switching on after double off command, while all the fixes have broken most of my nicely crafted scenes with a lot of different IKEA lights and long OFF transitions. Please note the firmware versions are NOT linear: some older generation bulbs have software number 2.3.086 or 2.3.093, while the firmware is much older than 1.0.012 etc. So, relying on version number comparison being greater than X is NOT the right solution.
I believe this should be precisely enabled for REALLY affected devices. The best solution would be to allow this option to be enabled for those, who experience this issue.

@supaeasy
Copy link

I have the issue of the Bulb randomly turning on at the lowest level. But I am 100% sure that I do not send off commands while it is off.

@JBS5
Copy link

JBS5 commented Sep 16, 2024

Still ignoring transition time when turning off in 1.40.1 unless a fix for this transition bug is mentioned in the changelog.

https://github.com/Koenkk/zigbee2mqtt/releases/tag/1.40.1

#23825 Don't ignore off transition for TRADFRI bulbs with firmware 1.0.021 (@Koenkk)

@fnordson
Copy link

fnordson commented Sep 18, 2024

I may have a related issue.
This is what I got:

grafik

I've set the transition in z2m to 4 seconds when I bought the light, and it would transition on and off in 4 sec.
I've been out of country for a few weeks and when I came back, I updated everything, now it transitions for those 4 sec when I turn it on, but it won't when I turn it off. It just instantly turns off.

I've played around with the transition time. Making it longer, shorter, turning it off.
The same issue.
It also happens to other IKEA bulbs I bought and connected afterward.

@muddy79
Copy link

muddy79 commented Sep 18, 2024

@fnordson the "off" transition feature has been disabled for most of the IKEA devices, as a workaround for firmware bug: switching it on to a low dim after sending two consecutive OFF commands with transition set. Unfortunately, there are multiple issues related to this workaround:

  1. Nearly ALL Ikea devices are covered by it, since there is only a check of a firmware version (if greater than 1.0.021, ignore transition), BUT the firmware versioning is NOT linear: some very old devices are already on firmware 2.0.xx or 3.0.xx while the firmware date is much older (2019-2022). These devices' feature has now been removed: not possible to set off transition, while they do not need the workaround - the bug is only confirmed for version 1.0.38 released in 2023 (as far as I know).
  2. Even if the bug exists, not everyone was even aware of it: for example, I have 8 bulbs with this firmware and I've never observed it, so disabling a feature to provide a workaround is probably not the best idea (please note: switching it off with transition while in on state works just fine: you are only affected if the bulb is already at off state).
  3. In my opinion, this workaround should be removed: there might be different solution:
  • easiest: pinpoint ignoring off transition time for specific devices and specific firmware versions and date: not ideal, since I still like to use off transition for these bulbs: my automations and settings are not affected
  • a bit more work: like above, but add global configuration option to disable this workaround
  • add device specific configuration to disable off transition to the selected devices
  • most complex: detect the device state before sending off command and send it only when device is in on state

@Koenkk I'd be grateful for your comment.

@Koenkk
Copy link
Owner

Koenkk commented Sep 18, 2024

most complex: detect the device state before sending off command and send it only when device is in on state

This was actually quite easy to implement, the transition will now only be skipped when the bulb is already OFF.

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

@fnordson
Copy link

This is perfect. Thank you very much for the incredibly fast response.

@GioMez
Copy link
Author

GioMez commented Oct 2, 2024

Just updated to 1.40.2 and it works flawlessly! Transitions are back and, if I turn OFF the lamps twice, there is no sign of #22030. I tested single bulbs and in groups (also with other brands). Marking as closed. Thank you!

@GioMez GioMez closed this as completed Oct 2, 2024
@supaeasy
Copy link

supaeasy commented Oct 2, 2024

Cannot confirm. Problem persists.

@GioMez
Copy link
Author

GioMez commented Oct 2, 2024

Cannot confirm. Problem persists.

Which one? No transitions when turning off or #22030 ?

@supaeasy
Copy link

supaeasy commented Oct 2, 2024

This: #23825 (comment)
It is really frustrating.

@fnordson
Copy link

fnordson commented Oct 2, 2024

I can confirm that it works here.
Updated, reloaded HA.

My System:

Core 2024.9.3
Supervisor 2024.09.1
Operating System 13.1
Frontend 20240909.1

Z2M: Current version: 1.40.2-1

Thank you very much.

@Toph92
Copy link

Toph92 commented Oct 2, 2024

Yes, it works here too with lastest docker. THANKS a lot

@tungmeister
Copy link

This: #23825 (comment) It is really frustrating.

I'm seeing this as well with my GU10 LED2005R5/LED2106R3 on fw 3.0.21. They were behaving with the previous release however since updating to 1.40.2 they've been on when they should have been off a few times. @Koenkk any ideas?

@supaeasy
Copy link

supaeasy commented Oct 3, 2024

I have come to believe it is an IKEA Firmware problem. Everything started when I upgraded it. There is no way to downgrade or is it?

@fnordson
Copy link

fnordson commented Oct 3, 2024

I have come to believe it is an IKEA Firmware problem. Everything started when I upgraded it. There is no way to downgrade or is it?

At least for my issue, it surely wasn't the firmware.
I had the firmware updated before I left and it broke with the z2m update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
problem Something isn't working
Projects
None yet
Development

No branches or pull requests

10 participants