mrmaximas
commented
9 months ago @mrmaximas yes, see #19211 (comment)
I didn't mean through the dev console, but through exposes menu.
Open JudahBella opened 1 year ago
mrmaximas
commented
9 months ago @mrmaximas yes, see #19211 (comment)
I didn't mean through the dev console, but through exposes menu.
danishru
commented
9 months ago I have the same problem with IKEA TRADFRI Driver 30W and TRADFRI TRADFRI bulb E27 WS opal 1000lm.
My setup.
Zigbee2MQTT version - 1.34.0 Coordinator type - zStack3x0 Coordinator version - 20230507
Model TRADFRI Driver 30W - ICPSHC24-30EU-IL-1 Firmware version TRADFRI Driver 30W - 2.3.086 (20211025)
Model TRADFRI bulb E27 WS opal 1000lm - LED1732G11 Firmware version TRADFRI bulb E27 WS opal 1000lm - 2.0.022 (20190308)
I have not used these devices before, so I cannot say when this started, but since the firmware versions of the devices differ greatly, I conclude that it does not depend on this. I ran some tests and came up with a stable dependency problem. After physically turning off the power, the lamp and driver always reset the onOffTransitionTime and onLevel attributes in the LevelCtrl cluster to some of their default settings. onOffTransitionTime always returns to 5, and onLevel always returns to 0. When using direct binding, the switches begin to use exactly these parameters, which leads to turning on at minimum brightness and with the specified Transition, while other attributes are not reset. I also disabled zigbee2mqtt to eliminate its influence, the devices also reset these attributes. Using group or device binding also does not affect behavior in any way.
As a temporary workaround, you can use automations in Home Assistant. But to do this, you need to configure reports for the onLevel and onOffTransitionTime attributes. Automation will catch changes in the values of the specified attributes and send the required attribute values to zigbee2mqtt.
Example of automation via link.
I'm looking forward to solving this problem, as IKEA devices are of very good quality and functional.
pedrolamas
commented
9 months ago I have an IKEA LED1733G7 lamp that has been showing this behavior (I believe since the latest release, before was working ok)
My setup is using the latest Z2M Docker image.
I've tried writing 255 to onLevel and 254 to startUpCurrentLevel:
This is the state for this lamp:
"0xd0cf5efffe311aa5": {
"state": "OFF",
"update_available": false,
"update": {
"state": "idle",
"installed_version": 587814449,
"latest_version": 587814449
},
"color_temp": 338,
"color_mode": "color_temp",
"brightness": 254,
"linkquality": 58,
"level_config": {
"on_level": "previous",
"current_level_startup": 254
},
"power_on_behavior": "previous",
"color_temp_startup": 65535
}Having said that, I have seen a couple of times "on_level": "0" on the above state file, which I find odd as that is AFTER I manually wrote the 254 value...
mrmaximas
commented
9 months ago Having said that, I have seen a couple of times
"on_level": "0"on the above state file, which I find odd as that is AFTER I manually wrote the254value...
Does this lamp belong in any group? I often observe this behaviour with the first or last lamp in a group of four, and have never seen it with the second and third. Only when the mains to this lamps is switched off, on_level & current_level_startup is resets.
pedrolamas
commented
9 months ago Does this lamp belong in any group?
No, this specific lamp is not in any group.
mrmaximas
commented
9 months ago Does this lamp belong in any group?
No, this specific lamp is not in any group.
Okay, I don't have single Ikea gu10 lamps.
baderas
commented
9 months ago This bug is really annoying. As a workaround i'm just writing "onLevel":255 and "onOffTransitionTime":0 once per hour to evey ikea bulb via mqtt. So far this seems to be working quite well (did not see a low brightness bulb on toggle since then) and not damaging anything (also it seems that it does not change anything besides mitigating this bug?). Sadly, at least to my knowledge, onLevel and onOffTransitionTime cannot be received via mqtt automatically, otherwise we could react to the change instead of pushing it evey hour (or so).
danishru
commented
9 months ago This bug is really annoying. As a workaround i'm just writing "onLevel":255 and "onOffTransitionTime":0 once per hour to evey ikea bulb via mqtt. So far this seems to be working quite well (did not see a low brightness bulb on toggle since then) and not damaging anything (also it seems that it does not change anything besides mitigating this bug?). Sadly, at least to my knowledge, onLevel and onOffTransitionTime cannot be received via mqtt automatically, otherwise we could react to the change instead of pushing it evey hour (or so).
You don't have to do this once an hour. You can catch changes in state if you set up a report on these attributes in Z2M, as in the screenshot.
By the way, here's my workaround https://github.com/Koenkk/zigbee2mqtt/issues/19211#issuecomment-1871092838, it works perfectly.
Jabe
commented
9 months ago @Jabe could you give me the herdsman debug logging between step 9 and 13, I don't understand why the level config gets added back to state.json.
@Koenkk I got a log, but it doesn't say much I think. Unless it hides in the frames.
My two lamps here are connected through a switch that I can toggle (it is always on normally).
2024-01-14T15:43:41.175Z zigbee-herdsman:controller:endpoint Command 0x001fee000000642d/1 genOnOff.on({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
2024-01-14T15:43:41.176Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0x001fee000000642d:41618/1 (0,0,1)
2024-01-14T15:43:41.177Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":41618,"destendpoint":1,"srcendpoint":1,"clusterid":6,"transid":121,"options":0,"radius":30,"len":3,"data":{"type":"Buffer","data":[1,90,1]}}
2024-01-14T15:43:41.177Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,13,36,1,146,162,1,1,6,0,121,0,30,3,1,90,1,32]
2024-01-14T15:43:41.189Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
2024-01-14T15:43:41.189Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
2024-01-14T15:43:41.189Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2024-01-14T15:43:41.189Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2024-01-14T15:43:41.190Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2024-01-14T15:43:41.192Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,0,1,121,191]
2024-01-14T15:43:41.192Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,1,121,191]
2024-01-14T15:43:41.193Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,1,121] - 191
2024-01-14T15:43:41.193Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":121}
2024-01-14T15:43:41.194Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2024-01-14T15:43:41.227Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,69,196,146,162,0,178]
2024-01-14T15:43:41.227Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,69,196,146,162,0,178]
2024-01-14T15:43:41.227Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 5 - 196 - [146,162,0] - 178
2024-01-14T15:43:41.228Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - srcRtgInd - {"dstaddr":41618,"relaycount":0,"relaylist":[]}
2024-01-14T15:43:41.228Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2024-01-14T15:43:41.245Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,25,68,129,0,0,6,0,146,162,1,1,0,25,0,39,255,164,0,0,5,24,90,11,1,0,146,162,29,239]
2024-01-14T15:43:41.245Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,25,68,129,0,0,6,0,146,162,1,1,0,25,0,39,255,164,0,0,5,24,90,11,1,0,146,162,29,239]
2024-01-14T15:43:41.245Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 25 - 2 - 4 - 129 - [0,0,6,0,146,162,1,1,0,25,0,39,255,164,0,0,5,24,90,11,1,0,146,162,29] - 239
2024-01-14T15:43:41.245Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":6,"srcaddr":41618,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":25,"securityuse":0,"timestamp":10813223,"transseqnumber":0,"len":5,"data":{"type":"Buffer","data":[24,90,11,1,0]}}
2024-01-14T15:43:41.249Z zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"transactionSequenceNumber":90,"manufacturerCode":null,"commandIdentifier":11},"Payload":{"cmdId":1,"statusCode":0},"Command":{"ID":11,"name":"defaultRsp","parameters":[{"name":"cmdId","type":32},{"name":"statusCode","type":32}]}},"address":41618,"endpoint":1,"linkquality":25,"groupID":0,"wasBroadcast":false,"destinationEndpoint":1}'
Zigbee2MQTT:info 2024-01-14 16:43:41: MQTT publish: topic 'zigbee2mqtt/Diele/Flur Wandschalter', payload '{"configure_device_setup":{"input_actions":[[0,7,3,6,0,2],[0,134,3,5,0,5,11,0,0],[0,198,3,5,0,5,11,0,1],[1,7,4,6,0,2],[1,134,4,5,0,5,6,0,0],[1,198,4,5,0,5,6,0,1]],"input_configurations":[0,0]},"energy":0.87,"last_seen":"2024-01-14T15:43:41.250Z","linkquality":25,"power":0,"power_on_behavior_l1":"on","power_on_behavior_l2":"on","state_l1":"OFF","state_l2":"ON","update":{"installed_version":37749810,"latest_version":37749810,"state":"idle"},"update_available":null}'
2024-01-14T15:43:41.260Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
Zigbee2MQTT:info 2024-01-14 16:43:41: MQTT publish: topic 'zigbee2mqtt/Diele/Flur Wandschalter', payload '{"configure_device_setup":{"input_actions":[[0,7,3,6,0,2],[0,134,3,5,0,5,11,0,0],[0,198,3,5,0,5,11,0,1],[1,7,4,6,0,2],[1,134,4,5,0,5,6,0,0],[1,198,4,5,0,5,6,0,1]],"input_configurations":[0,0]},"energy":0.87,"last_seen":"2024-01-14T15:43:41.250Z","linkquality":25,"power":0,"power_on_behavior_l1":"on","power_on_behavior_l2":"on","state_l1":"ON","state_l2":"ON","update":{"installed_version":37749810,"latest_version":37749810,"state":"idle"},"update_available":null}'
2024-01-14T15:43:41.390Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35]
2024-01-14T15:43:41.391Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35]
2024-01-14T15:43:41.391Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 13 - 2 - 5 - 193 - [193,146,193,146,183,136,70,254,255,87,11,0,142] - 35
2024-01-14T15:43:41.391Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - endDeviceAnnceInd - {"srcaddr":37569,"nwkaddr":37569,"ieeeaddr":"0x000b57fffe4688b7","capabilities":142}
2024-01-14T15:43:41.391Z zigbee-herdsman:controller:log Device announce '0x000b57fffe4688b7'
Zigbee2MQTT:info 2024-01-14 16:43:41: MQTT publish: topic 'zigbee2mqtt/Flur Deckenlampe 2', payload '{"brightness":229,"color":{"x":0.477,"y":0.4137},"color_mode":"color_temp","color_options":null,"color_temp":400,"color_temp_startup":370,"last_seen":"2024-01-14T15:43:41.391Z","level_config":{"on_level":0},"linkquality":14,"power_on_behavior":"off","state":"OFF","update":{"installed_version":587814449,"latest_version":587814449,"state":"idle"},"update_available":null}'
Zigbee2MQTT:info 2024-01-14 16:43:42: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"Flur Deckenlampe 2","ieee_address":"0x000b57fffe4688b7"},"type":"device_announce"}'
2024-01-14T15:43:42.855Z zigbee-herdsman:controller:endpoint ConfigureReporting 0x000b57fffe4688b7/1 genOnOff([{"attribute":"onOff","minimumReportInterval":0,"maximumReportInterval":3600,"reportableChange":0}], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
2024-01-14T15:43:42.856Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0x000b57fffe4688b7:37569/1 (0,0,1)
2024-01-14T15:43:42.856Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":37569,"destendpoint":1,"srcendpoint":1,"clusterid":6,"transid":122,"options":0,"radius":30,"len":11,"data":{"type":"Buffer","data":[16,91,6,0,0,0,16,0,0,16,14]}}
2024-01-14T15:43:42.858Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,21,36,1,193,146,1,1,6,0,122,0,30,11,16,91,6,0,0,0,16,0,0,16,14,73]
2024-01-14T15:43:42.859Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2024-01-14T15:43:42.871Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35,254,13,69,193,231,179,231,179,145,150,70,254,255,87,11,0,142,27,254,3,69,196,231,179,0,214,254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35,254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35]
2024-01-14T15:43:42.871Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35,254,13,69,193,231,179,231,179,145,150,70,254,255,87,11,0,142,27,254,3,69,196,231,179,0,214,254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35,254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35]
2024-01-14T15:43:42.871Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 13 - 2 - 5 - 193 - [193,146,193,146,183,136,70,254,255,87,11,0,142] - 35
2024-01-14T15:43:42.871Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - endDeviceAnnceInd - {"srcaddr":37569,"nwkaddr":37569,"ieeeaddr":"0x000b57fffe4688b7","capabilities":142}
2024-01-14T15:43:42.871Z zigbee-herdsman:controller:log Device announce '0x000b57fffe4688b7'
Zigbee2MQTT:info 2024-01-14 16:43:42: MQTT publish: topic 'zigbee2mqtt/Flur Deckenlampe 2', payload '{"brightness":229,"color":{"x":0.477,"y":0.4137},"color_mode":"color_temp","color_options":null,"color_temp":400,"color_temp_startup":370,"last_seen":"2024-01-14T15:43:42.871Z","level_config":{"on_level":0},"linkquality":14,"power_on_behavior":"off","state":"OFF","update":{"installed_version":587814449,"latest_version":587814449,"state":"idle"},"update_available":null}'
Zigbee2MQTT:info 2024-01-14 16:43:43: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"Flur Deckenlampe 2","ieee_address":"0x000b57fffe4688b7"},"type":"device_announce"}'
2024-01-14T15:43:43.984Z zigbee-herdsman:controller:endpoint ConfigureReporting 0x000b57fffe4688b7/1 genOnOff([{"attribute":"onOff","minimumReportInterval":0,"maximumReportInterval":3600,"reportableChange":0}], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
2024-01-14T15:43:43.985Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,13,69,193,231,179,231,179,145,150,70,254,255,87,11,0,142,27,254,3,69,196,231,179,0,214,254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35,254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35]
2024-01-14T15:43:43.985Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 13 - 2 - 5 - 193 - [231,179,231,179,145,150,70,254,255,87,11,0,142] - 27
2024-01-14T15:43:43.985Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - endDeviceAnnceInd - {"srcaddr":46055,"nwkaddr":46055,"ieeeaddr":"0x000b57fffe469691","capabilities":142}
2024-01-14T15:43:43.985Z zigbee-herdsman:controller:log Device announce '0x000b57fffe469691'
Zigbee2MQTT:info 2024-01-14 16:43:43: MQTT publish: topic 'zigbee2mqtt/Flur Deckenlampe 1', payload '{"brightness":173,"color":{"x":0.477,"y":0.4137},"color_mode":"color_temp","color_options":null,"color_temp":400,"color_temp_startup":370,"last_seen":"2024-01-14T15:43:43.986Z","level_config":{"on_level":"previous","on_off_transition_time":5},"linkquality":105,"power_on_behavior":"off","state":"ON","update":{"installed_version":587814449,"latest_version":587814449,"state":"idle"},"update_available":null}'
Zigbee2MQTT:info 2024-01-14 16:43:45: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"Flur Deckenlampe 1","ieee_address":"0x000b57fffe469691"},"type":"device_announce"}'
2024-01-14T15:43:45.205Z zigbee-herdsman:controller:endpoint ConfigureReporting 0x000b57fffe469691/1 genOnOff([{"attribute":"onOff","minimumReportInterval":0,"maximumReportInterval":3600,"reportableChange":0}], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
2024-01-14T15:43:45.206Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0x000b57fffe469691:46055/1 (0,0,3)
2024-01-14T15:43:45.207Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,69,196,231,179,0,214,254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35,254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35]
2024-01-14T15:43:45.207Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 5 - 196 - [231,179,0] - 214
2024-01-14T15:43:45.207Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - srcRtgInd - {"dstaddr":46055,"relaycount":0,"relaylist":[]}
2024-01-14T15:43:45.208Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35,254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35]
2024-01-14T15:43:45.208Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 13 - 2 - 5 - 193 - [193,146,193,146,183,136,70,254,255,87,11,0,142] - 35
2024-01-14T15:43:45.209Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - endDeviceAnnceInd - {"srcaddr":37569,"nwkaddr":37569,"ieeeaddr":"0x000b57fffe4688b7","capabilities":142}
2024-01-14T15:43:45.209Z zigbee-herdsman:controller:log Device announce '0x000b57fffe4688b7'
Zigbee2MQTT:info 2024-01-14 16:43:45: MQTT publish: topic 'zigbee2mqtt/Flur Deckenlampe 2', payload '{"brightness":229,"color":{"x":0.477,"y":0.4137},"color_mode":"color_temp","color_options":null,"color_temp":400,"color_temp_startup":370,"last_seen":"2024-01-14T15:43:45.209Z","level_config":{"on_level":0},"linkquality":14,"power_on_behavior":"off","state":"OFF","update":{"installed_version":587814449,"latest_version":587814449,"state":"idle"},"update_available":null}'
Zigbee2MQTT:info 2024-01-14 16:43:46: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"Flur Deckenlampe 2","ieee_address":"0x000b57fffe4688b7"},"type":"device_announce"}'
2024-01-14T15:43:46.272Z zigbee-herdsman:controller:endpoint ConfigureReporting 0x000b57fffe4688b7/1 genOnOff([{"attribute":"onOff","minimumReportInterval":0,"maximumReportInterval":3600,"reportableChange":0}], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
2024-01-14T15:43:46.273Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,13,69,193,193,146,193,146,183,136,70,254,255,87,11,0,142,35]
2024-01-14T15:43:46.274Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 13 - 2 - 5 - 193 - [193,146,193,146,183,136,70,254,255,87,11,0,142] - 35
2024-01-14T15:43:46.275Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - endDeviceAnnceInd - {"srcaddr":37569,"nwkaddr":37569,"ieeeaddr":"0x000b57fffe4688b7","capabilities":142}
2024-01-14T15:43:46.275Z zigbee-herdsman:controller:log Device announce '0x000b57fffe4688b7'
Zigbee2MQTT:info 2024-01-14 16:43:46: MQTT publish: topic 'zigbee2mqtt/Flur Deckenlampe 2', payload '{"brightness":229,"color":{"x":0.477,"y":0.4137},"color_mode":"color_temp","color_options":null,"color_temp":400,"color_temp_startup":370,"last_seen":"2024-01-14T15:43:46.276Z","level_config":{"on_level":0},"linkquality":14,"power_on_behavior":"off","state":"OFF","update":{"installed_version":587814449,"latest_version":587814449,"state":"idle"},"update_available":null}'
depau
commented
9 months ago I'm also experiencing the same issue, as I reported in #20783. I tried writing 255 to onLevel and it works, until it randomly goes back to 0.
I wrote a standalone Python script that implements @danishru's workaround, if anyone's interested: https://github.com/depau/ikea-light-fixer
Koenkk
commented
9 months ago That makes Flur Deckenlampe 1 / 2 boot and z2m will announce them.
Z2M doesn't announce them, the bulbs announce themselves. A Device announce is typically sent when a device boots (you should get it when simply power cycling them). If a Device announce is sent without power cycling, they probably crashed which would indicate a bug in the firmware.
mrmaximas
commented
9 months ago I wonder if anyone has contacted ikea with this lamp behaviour problem?
Koenkk
commented
8 months ago @accek implemented a possible fix.
Changes will be available in the dev branch in a few hours from now.
LucidityCrash
commented
8 months ago @Koenkk I'll need to get debug next time it happens but even on the dev branch I just saw this again. I've got 6 of the LED1739R5 GU10's. They are in a group (in zigbee2mqtt) with a STYRBAR remote control (E2001/E2002). The light group is controlled directly over zigbee with that controller ... this allways seems to work correctly. The group is also in a HA automation that uses a Wireless button (SNZB-01) that is not in the zigbee group. The automation toggles the on/off state of the group using a short press. Sometimes this button appears to stop toggling the lights, looking at HA the automation is being triggered and the light group is being set to on ... but the lights do not actually come on, I didn't check just now but the last time this happened (on the production release) the lights were on but at minimum brightness. Repeated use of this sonoff button or toggling the light group in HA makes no difference. However using the directly bound STRYBAR control to turn on the light works perfectly and from then on using HA works again till the next time, alternatevly using HA to set the brightness bact to something other than minimum also effectively fixes the issue ... the bulbs are never powered off.
I've also got a 2nd group (in zigbee) that are toggled by a double press of the same button. This group is not bound to a controller directly, and while this group is used much less often they have not had this issue.
LucidityCrash
commented
8 months ago @Koenkk I only turned debug on at 20:00 last night but I've had this happen again I've attached a log that just has the lights (MBL 1 - 10), the light groups (mb_main_lights, mb_cupboard_lights) , the Ikea remote (MBC 1) and the Sonoff Button (MB Button 1)
The light group mb_main_lights was turned off at 21:35:50 using the Ikea remote directly bound to the group (MBC1) and the group and all the lights (MBL 1-6) had their topics updated with a payload which includes "brightness:127" and "state:off" this all looks good. However not even a second later there is a MQTT publish: topic 'zigbee2mqtt/mb_main_lights' which changes the brightness to 1.
The lights were turned on this morning at 06:29:01 by the Ikea remote and while the debug messages indicate the brightness should be 1 it was in fact the same brightness as it was when it was turned off. It wasn't until I turned the lights off and then back on again using the Sonoff button at 06:56:56/06:56:59 that when they came on the physical brightness of the bulb reflected the mqtt payload brightness of 1.
Something else I've just noticed is that while there is an entry in the log for the Ikea remote turning on the lights this morning : debug 2024-01-31 06:29:04: Received Zigbee message from 'MBC 1', type 'commandOn', cluster 'genOnOff', data '{}' from endpoint 1 with groupID 1 there is not one for me turning the lights off with it last night at 21:35.
There is also a difference on how this is shown in HA.
when there is a zigbee event from the Ikea remote the light group entity logbook in HA shows this :
but for the turn off event last night for which there was no log line in zigbee2mqtt the entity HA logbook shows this:
Koenkk
commented
8 months ago @LucidityCrash are you using a z2m version with this fix (dev branch or tomorrows new release)?
LucidityCrash
commented
8 months ago 1.35.1-dev commit: 0d71628
LucidityCrash
commented
8 months ago It has happened twice more this evening. Its been fine for ages ... unfortunately I can't remember the version I was on prior to this happening. I also updated the coordinator firmware at the same time so it could be that also (using a zzh)
LucidityCrash
commented
8 months ago I'm gonna try reverting to 1.33.0 which by all reports should be before this issue started and see if the problem remains. I want to rule out the coordinator firmware version.
LucidityCrash
commented
8 months ago 24 ish hours after downgrading to 1.33.0 and I've yet to have a repeat of the problem ... not gonna say 100% things are not broken as I think I've had periods longer than a day between the issue appearing but it seems to be looking good. This would suggest the issue is with Zigbee2MQTT (or more likely the herdsman converters) rather than the coordinator firmware. At least for the issue I've been seeing.
LucidityCrash
commented
8 months ago Hmmm Interesting ... I'm still seeing this on 1.33. The visible presentationnis different though. On 1.33 minimum brightness is at least on but on later versions minimum brightness doesntneven illuminate the bulb.
LucidityCrash
commented
8 months ago @Koenkk can this get reopened or should a new ticket be raised ? ... this was definately working till I did updates on 31 December. I've rolled back the zigbee2mqtt docker container to 1.33.0. Unfortunately I can't remember what version of Z2M I was on prior to this problem appearing ... looking at my docker image cache I'm seeing 1.33.2, 1.34.0, 1.35.0 and a dev version dated 27 Jan, so unless I also deleted the image (I can't imagine why I'd then not delete all the unused ones) I'm currently using a version earlier than the last one I had working which through logical deduction I would say would have been 1.34.0
I've tried adding a transition 0 to both the group and all the members of the group as per a previous comment and this hasn't helped.
The only other thing that changed is I updated the coordinator firmware from 20211217 to 20230507. I'm probably going to try downgrading back to that at some point when I get some time
JudahBella
commented
8 months ago Hi all, pleased to report that my bulbs that have the originally stated issue have onLevel at either 0 or 1 and writing 255 to it fixes the issue.
EDIT: I realised much has progressed since this "fix" was published in https://github.com/Koenkk/zigbee2mqtt/issues/19211#issuecomment-1850725742. I cannot yet verify if and when onLevel reverts to 0 or 1 after being set to 255, will report back if it happens. I am now at Z2M 1.35.3.
pedrolamas
commented
8 months ago I too seem to have the issue fixed since the last release!
I can't recall exactly if I did any extra steps to get it working, but I've had the lamps working fine for a while now!
LucidityCrash
commented
8 months ago for me onLevel is 255 (on 1.33.0) ... I've just been repeatedly turning lights on and off and using the debug console and I think I've narrowed it down
Lights on :
Lights turned off using the group control in Home assistant :
So it looks like the way the group switch turns the light off in HA also sets the brightness to 1 ... At least in my case ... weird especially as there is another zigbee group that does not behave like this ... this group is not controlled from a remote though only ever through HA. The lights in this 2nd group are identical but they do not have a level_config section in either mqtt or in state.json
debug log from one of the bulbs affected when I switch off the group using HA :
notice zigbee2mqtt recieves a state update and brighness update immediately after ?
JudahBella
commented
8 months ago Hi guys, I might have found something..
Back in ikea.js, the code to set the onLevel attribute in genLevelCtrl was:
device.endpoints[0].write('genLevelCtrl', {onLevel});However, it seems that all along, it actually did nothing, as the array did not have a corresponding value to the key. Or maybe it wrote onLevel to genLevelCtrl as an object. Anyhow, my guess is that it should have instead been:
device.endpoints[0].write('genLevelCtrl', {'onLevel' : onLevel});And it does make sense, as this issue started occuring after ikea.ts was refactored, where the code became:
device.endpoints[0].write('genLevelCtrl', {onLevel: onLevelRaw});Now, maybe the onLevel attribute in genLevelCtrl is finally being written to, after being left alone all these while, with whatever onLevelRaw was (i.e. genLevelCtrl['onLevel'] = "previous" ).
Or, maybe it will write the value of onLevelRaw to onLevel (i.e. genLevelCtrl[255] = "previous")?
With @accek's merged PR in https://github.com/Koenkk/zigbee-herdsman-converters/pull/6954, the code is now:
device.endpoints[0].write('genLevelCtrl', {onLevel: onLevel});However, just to be sure, should the array key be in quotes too, like so?
device.endpoints[0].write('genLevelCtrl', {'onLevel': onLevel});AFAIK, the refactor to use onLevelRaw was incorrect and that was fixed when it reverted to use onLevel
However, just to be sure, should the array key be in quotes too, like so?
No need, because in JavaScript, all these lines will produce same result:
result = {onLevel};
result = {onLevel: onLevel};
result = {'onLevel': onLevel};You can confirm so by going on this TypeScript Playground and checking the dynamic value that shows on the comment in the last line
marazmarci
commented
8 months ago I have a theory, and sorry if it's too obvious, or you already know it. Disclaimer: I'm far from knowing every detail 😄
So I think that while the incorrect refactor was released for users in "production", the IKEA bulbs got the invalid raw value, which they persisted in their flash memory, and reverting the refactor didn't help, as the bulbs already had the values stored.
The solution may be to release code that writes "the correct" value to the onLevel property. The flag representing that it was already written could be stored in state.json, with a default value of true.
What do you think?
djereg
commented
8 months ago marazmarci
commented
8 months ago I think it would be better for the users if a silently introduced issue would be also fixed silently, in a new release. I mean if we can fix it for everyone, we probably should, right? 🤷🏻♂️
(I didn't want to suggest a workaround, but an actual solution which involves changing the code.)
djereg
commented
8 months ago Yes, I can agree with that. Jogos.
LookedPath
commented
7 months ago I have tried this but it doesn't work. I have Z2M Edge installed (1.36.0-dev commit: 0e0eccb ) but unless I set transition time to 0 all my Ikea bulbs reset to a brightness of 1 when turning them on. Is there something else that needs to be done that I'm missing?
LucidityCrash
commented
7 months ago I have tried this but it doesn't work. I have Z2M Edge installed (1.36.0-dev commit: 0e0eccb ) but unless I set transition time to 0 all my Ikea bulbs reset to a brightness of 1 when turning them on. Is there something else that needs to be done that I'm missing?
Where do you set the transition time to 0 ... I've set it in the group (I think) but that doesn't seem to help ... of note when I turn on the lights there seems to be not transition but turning them off either by the remote or via z2m (either Web, direct mqtt message, or via HA) the lights fade to off, pretty quickly but definitely a fade unlike when they turn on
LookedPath
commented
7 months ago I have tried this but it doesn't work. I have Z2M Edge installed (1.36.0-dev commit: 0e0eccb ) but unless I set transition time to 0 all my Ikea bulbs reset to a brightness of 1 when turning them on. Is there something else that needs to be done that I'm missing?
Where do you set the transition time to 0 ... I've set it in the group (I think) but that doesn't seem to help ... of note when I turn on the lights there seems to be not transition but turning them off either by the remote or via z2m (either Web, direct mqtt message, or via HA) the lights fade to off, pretty quickly but definitely a fade unlike when they turn on
I set it in the Settings(specific) tab of each device in Z2M.
LucidityCrash
commented
7 months ago I've done some digging ... initially I thought it might be because there wasn't a turnsOffAtBrightness1: true in the ikea.ts but I tried hacking that in and it didn't seem to make much difference. But I think I've got something.
If I send state: off to the zigbee2mqtt/
debug 2024-03-22 15:18:09Received MQTT message on 'zigbee2mqtt/mb_main_lights/set' with data '{ "state": "OFF" }'
debug 2024-03-22 15:18:09Publishing 'set' 'state' to 'mb_main_lights'
info 2024-03-22 15:18:09MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":254,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"OFF"}'
info 2024-03-22 15:18:09MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":1,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"OFF"}'
info 2024-03-22 15:18:09MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":1,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"OFF"}'
info 2024-03-22 15:18:09MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":1,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"OFF"}'
info 2024-03-22 15:18:09MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":1,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"OFF"}'
info 2024-03-22 15:18:09MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":1,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"OFF"}'
info 2024-03-22 15:18:09MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":1,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"OFF"}'
info 2024-03-22 15:18:09MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":1,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"OFF"}'
info 2024-03-22 15:18:09MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":1,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"OFF"}'then sending state: on to the same topic :
debug 2024-03-22 15:20:00Received MQTT message on 'zigbee2mqtt/mb_main_lights/set' with data '{ "state": "ON" }'
debug 2024-03-22 15:20:00Publishing 'set' 'state' to 'mb_main_lights'
info 2024-03-22 15:20:01MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":254,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"ON"}'
info 2024-03-22 15:20:01MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":254,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"ON"}'
info 2024-03-22 15:20:01MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":254,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"ON"}'
info 2024-03-22 15:20:01MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":254,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"ON"}'
info 2024-03-22 15:20:01MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":254,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"ON"}'
info 2024-03-22 15:20:01MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":254,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"ON"}'
info 2024-03-22 15:20:01MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":254,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"ON"}'but if I use the remote to turn the group on after using MQTT to turn them off I see :
info 2024-03-22 15:21:16MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":1,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"ON"}'and turning the group off using the remote I'm seeing :
info 2024-03-22 15:23:10MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":254,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"OFF"}'
info 2024-03-22 15:23:11MQTT publish: topic 'zigbee2mqtt/mb_main_lights', payload '{"brightness":254,"color":{"h":34,"hue":34,"s":78,"saturation":78,"x":0.4558,"y":0.4096},"color_mode":"color_temp","color_temp":366,"state":"OFF"}'And I think I've cracked it :) ... I had a 2nd group that I do not use with a remote only HA, and it doesn't exhibit any issues ... and for some reason I decided to look at the MQTT topics when I set the state to off by publishing to the topic. This 2nd group didn't set the brightness to 1. When this first started happening I'd put transition: 0 in the 1st groups definition, this entry wasn't in the 2nd groups, so I removed it from the 1st groups definition again, restarted Z2M and bang, so far every combination of off/on has worked.
LucidityCrash
commented
7 months ago I hit the problem again but I think it was because the automation that I'd used to turn off the light group with a secondary zigbee button also had a transition time of 0 set ... so far I've used both the button and the remote to turn on and off the light group multiple time and it's not happened again. fingers crossed this is really it this time.
LookedPath
commented
7 months ago @LucidityCrash the thing is that for me the issue is present even on bulbs that are not part of a group and that are not bound to external buttons. All my buttons only trigger automations on Home Assistant and the issue is present when I turn the lights on even through the HA app. I've tried experimenting with the transition on Z2M by setting it to 0, 1 and also leaving the field empty but it doesn't seem to have an effect. The only Ikea light that works properly after setting the transition time to 0 is the ICPSHC24-10EU-IL-1 where if the transition time is 1 or empty the light always turns on at minimum brightness.
LucidityCrash
commented
7 months ago I did try moving a single bulb outside a group and controlling that using HA ... that bulb (and all the others) have a transition set to 0 in their specific settings. This worked fine for me and was what pointed me to the fact that it was the group being turned off via mqtt was the thing that was causing the brightness to be set to 1. Looks like my issue and yours may be related. I take it the turning on at min brightness happens every time not just randomly ?
LookedPath
commented
7 months ago I take it the turning on at min brightness happens every time not just randomly ?
If I turn on a light after it had been off for a while it turns on at minimum brightness. If the light was on at max brightness, I turn it off and immediately turn it back on it keeps the correct brightness instead of reverting to 1. The issue seems to be triggered by time but I'm not sure after how long.
monks600
commented
5 months ago I'm suffering with this issue even whilst on z2m version 1.37.0 Tried all the above tweaks/fixes without any resolution in sight. I'm constantly seeing a mixture of ikea bulbs come on at 1%.
Bulbs are not in groups either, never have been. Working as stand alone devices with a few automations attached to each in HA.
Bulb models consist of the following:
LED1936G5 LED2003G10 LED1836G9 T2035
monks600
commented
5 months ago Just updated to 1.37.1 and unfortunately the problem still persists. Completely reset Z2M and started from scratch and rejoined all my zigbee devices, including the Ikea branded bulbs.
All other devices work flawlessly, just seems to be the Ikea bulbs. It’s very random, I can get sometimes a few hours of no issues, few days or every single one playing up.
anyone have any ideas? This is driving me nuts.
ambarusa
commented
5 months ago Yeah, same here @monks600
LookedPath
commented
5 months ago Same for me, I even tried switching to the new ember driver but it didn't solve anything. The issue has been driving me insane for months.
monks600
commented
5 months ago Glad I’m not the only one experiencing this issue. It’s really random as well this time round. I don’t have any lights in groups and none of the fixes mentioned above work at all. I’m using the Sonos usb 3.0 zigbee co-ordinator with the latest firmware and the most recent version of z2m. I’ve even gone down the route of removing and re-adding every single device in z2m.
what’s interesting, this bug doesn’t appear to happen in ZHA on a test instance I setup. It must be related to something in z2m, I haven’t a clue where to start with this as I think all avenues have previously been covered.
@Koenkk any ideas please or could this issue be re-opened or re-evaluated?
GoodnessJSON
commented
4 months ago Possible solution here - https://www.reddit.com/r/homeassistant/s/Fh6fT9m4IM
Could be HOAS/Z2M not handling this or sending double attributes/states?
monks600
commented
4 months ago Possible solution here - https://www.reddit.com/r/homeassistant/s/Fh6fT9m4IM
Could be HOAS/Z2M not handling this or sending double attributes/states?
Thanks, going to give this a go and see how i get along. One thing i've noted, after a HA update/Reboot of the instance. All the lights seem to do the 1% thing when attempting to turn on a light? It's like the lights are forgetting there states as mentioned in that reddit post.
alex3305
commented
4 months ago Possible solution here - https://www.reddit.com/r/homeassistant/s/Fh6fT9m4IM
No solution, but rather a workaround. However this just isn't the case for me. I can send turn off command all day long, and the light still retains the brightness setting.
The only thing that affected me was using Zigbee groups, as mentioned by the first Reddit comment. I stopped using Zigbee groups months ago and I haven't had this issue since. The main downside is that Home Assistant groups are way slower to respond. Still in the sub-second to second range, but vastly slower than with Zigbee groups.
ipha
commented
3 months ago After updating my LED1949C5 bulbs from 1.1.003 to 1.1.20 I've started experiencing this issue.
I've been trying to downgrade them, but so far I've been unsuccessful.
monks600
commented
3 months ago Update; just installed the latest z2m and decide to update my STYRBAR remotes to the latest firmware also. I’m now experiencing an even more strange behaviour than before..
I no longer experience the 1% brightness issue when using the wall switch, commands or HA switches. The only time this is now triggered is when using the STYRBAR remote which is binded to that particular bulb. Pressing the up button turns the bulb on at 1% every time. Further testing shows that this scenario only happens if I ask Alexa to turn off the lights. Until that is done, the lights and remote work as expected.
so it seems, if another intervention turns the lights off, then the up button on the remote will bring the light on at 1%. Holding the up button takes it back up to 100%. If I don’t use voice commands via Alexa intervention, the light functions on a single button press perfectly without turning on at 1%.
I’m rather confused now, doesn’t seem to follow any logic at all.
What happened?
Some of our IKEA bulbs are switching on to the lowest brightness setting when toggled. Across all the UIs (HK, HA, Z2M) the brightness value still shows as the brightness that the bulb is supposed to be at, but the bulb itself will be very dim. This happened suddenly after Z2M autoupdated to 1.33.1, and it has never happened before. No OTA was done on the bulbs either, so there was no other change.
I first encountered this issue with the ICPSHC24-10EU-IL-1 bulb. I found that setting the transition option to a numerical value instead of leaving it blank solves the issue. I have since set transitions for all bulbs to 1.
However, the above solution does not work for bulbs in groups. Certain bulbs in groups still power on to to a very dim setting on toggle. The odd thing is, (EDIT: when transition is set) toggling the bulb directly will bring the bulb back to its intended brightness, but toggling the entire group would cause the certain bulb to power on dimly. Not all bulbs are affected, only some are, and they all happen to be LED1537R6/LED1739R5 bulbs.
What did you expect to happen?
The bulb should turn on to the last brightness setting when toggling from off to on
How to reproduce it (minimal and precise)
Zigbee2MQTT version
1.33.1
Adapter firmware version
20230507
Adapter
tubeszb-cc2652-eth
Debug log
I'm running HAOS and can't SSH into the host so I'm trying my best here to copy and paste from the addon's logs tab.
Setting
Common Toilet Lightsto 100% causes all bulbs in the group to be at 100%:Toggling
Common Toilet Lightsgroup OFF:Toggling
Common Toilet Lightsgroup ON causesCommon Toilet Ceilingto be dim:Toggling
Common Toilet CeilingOFF directly:Toggling
Common Toilet CeilingON directly withtransitionvalue indevices.yamldeleted, bulb turns on but is dim:Setting
transitionto1and togglingCommon Toilet CeilingON directly causes bulb to turn on to the correct previous brightness:It seems that when the
transitionoption is set, togglingCommon Toilet CeilingON directly will causegenLevelCtrl.moveToLevelWithOnOff({"level":254,"transtime":10}to be sent andCommon Toilet Ceilingwill turn on to the correct previous value. With thetransitionoption cleared,genOnOff.onis sent instead, causingCommon Toilet Ceilingto be dim.Regardless, toggling the group ON always always causes
genOnOff.onto be sent, causingCommon Toilet Ceilingto be dim. Only if I turn on the group by swiping to the brightness in the UI willgenLevelCtrl.moveToLevelWithOnOff({"level":254,"transtime":0})be sent.