Open mrJudahBella opened 1 year ago
Referencing https://github.com/Koenkk/zigbee2mqtt/issues/3333, I decided to try adding transition: 1
to groups.yaml
. Strangely enough, genLevelCtrl.moveToLevelWithOnOff({"level":254,"transtime":10})
is sent and all bulbs in the group turn on to the correct previous brightness:
Zigbee2MQTT:debug 2023-10-08 18:40:59: Received MQTT message on 'zigbee2mqtt/Common Toilet Lights/set' with data '{"state":"ON"}'
Zigbee2MQTT:debug 2023-10-08 18:40:59: Publishing 'set' 'state' to 'Common Toilet Lights'
2023-10-08T10:40:59.670Z zigbee-herdsman:controller:database:log Writing database to '/config/zigbee2mqtt/database.db'
2023-10-08T10:40:59.698Z zigbee-herdsman:controller:group Command 11 genLevelCtrl.moveToLevelWithOnOff({"level":254,"transtime":10})
2023-10-08T10:40:59.700Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequestExt - {"dstaddrmode":1,"dstaddr":"0x000000000000000b","destendpoint":255,"dstpanid":0,"srcendpoint":1,"clusterid":8,"transid":29,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[17,10,4,254,10,0]}}
2023-10-08T10:40:59.702Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,26,36,2,1,11,0,0,0,0,0,0,0,255,0,0,1,8,0,29,0,30,6,0,17,10,4,254,10,0,46]
2023-10-08T10:40:59.736Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,2,0,103]
2023-10-08T10:40:59.736Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,2,0,103]
2023-10-08T10:40:59.736Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 2 - [0] - 103
2023-10-08T10:40:59.737Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequestExt - {"status":0}
2023-10-08T10:40:59.737Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2023-10-08T10:40:59.752Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,0,1,29,219]
2023-10-08T10:40:59.753Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,1,29,219]
2023-10-08T10:40:59.753Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,1,29] - 219
2023-10-08T10:40:59.753Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":29}
2023-10-08T10:40:59.754Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
Zigbee2MQTT:info 2023-10-08 18:40:59: MQTT publish: topic 'zigbee2mqtt/Common Toilet Ceiling', payload '{"brightness":254,"color":{"x":0.4599,"y":0.4106},"color_mode":"color_temp","color_options":{"execute_if_off":false},"color_temp":370,"color_temp_startup":370,"level_config":{"on_level":0},"linkquality":25,"power_on_behavior":"on","state":"ON","update":{"installed_version":-1,"latest_version":-1,"state":"available"},"update_available":true}'
Zigbee2MQTT:info 2023-10-08 18:40:59: MQTT publish: topic 'zigbee2mqtt/Common Toilet Lights', payload '{"brightness":254,"color":{"x":0.4599,"y":0.4106},"color_mode":"color_temp","color_temp":370,"state":"ON"}'
Zigbee2MQTT:info 2023-10-08 18:40:59: MQTT publish: topic 'zigbee2mqtt/Common Toilet Counter', payload '{"brightness":254,"level_config":{"on_level":"previous"},"linkquality":25,"power_on_behavior":null,"state":"ON","update":{"installed_version":-1,"latest_version":-1,"state":"idle"},"update_available":false}'
Zigbee2MQTT:info 2023-10-08 18:40:59: MQTT publish: topic 'zigbee2mqtt/Common Toilet Cove', payload '{"brightness":254,"linkquality":98,"state":"ON"}'
Zigbee2MQTT:info 2023-10-08 18:40:59: MQTT publish: topic 'zigbee2mqtt/Ceiling Lights', payload '{"brightness":254,"color":{"x":0.4607,"y":0.4108},"color_mode":"color_temp","color_temp":371,"state":"ON"}'
@Koenkk please advise if this is a bug or expected behaviour, and should I be adding transition
to all my groups now? The transition
variable is not available to be set in the UI for groups at this point.
Im experiencing the same issue for a couple of days on one group probably since the update to 1.33.1. Switching the group/lights on, through a bound remote or directly, turns them on at 1%. Adding transition: 1
to that group seems to fix it for now...
This looks similar to https://github.com/Koenkk/zigbee2mqtt/issues/16388#issuecomment-1749489713 and at first glance looks to be a bug of the bulb (off -> on should give the same state back).
transition: 0
also work?
- Does
transition: 0
also work?
I can confirm that the bug is also present for a group of LED2005R5 (IKEA Tradfri GU10) and that adding transition: 0
or transition: 1
to the group configuration leads to a correct brightness value after powering on. If only the transition time is added to the lightbulb configuration, the standalone switching is correct, but the group switching behavior is still wrong.
Before the zigbee2mqtt update, the lightbulbs (either standalone or as a group) behaved completely normal for several months. Hence, the bug may be introduced with some of the last zigbee2mqtt updates. Unfortunately, I cannot name the last working version from my side.
This looks similar to #16388 (comment) and at first glance looks to be a bug of the bulb (off -> on should give the same state back).
- I find it interesting that this happens only with z2m 1.33.1, what was the last known working z2m version?
- Does
transition: 0
also work?
Last known working is 1.33.0. I havenโt tried transition: 0
yet but I think https://github.com/Koenkk/zigbee2mqtt/issues/19211#issuecomment-1763364246 response should be sufficient!
Since posting the issue I have added transition: 1
to all IKEA bulbs and groups with IKEA bulbs in them. All bulbs toggle to the correct brightness.
I have some bulbs that are 1% brightness when โoffโ and 100% when โonโ, after sunset. A neat side effect of setting transition: 1
for everything is that they now fade nicely from 1% to 100% and back. These are standalone bulbs, and they used to snap between the brightness levels instead of fading. However, bulbs in groups have always faded, and Iโve always accepted this discrepancy in behaviour. I have never set the transition
variable anywhere before this.
Also, setting the transition
variable now causes standalone IKEA bulbs to fade more smoothly than previously. Previously, without the variable set, it seemed like the brightness levels were stepped through instead of a smooth fade.
Seems like it might be related to https://github.com/Koenkk/zigbee2mqtt/issues/3333#issuecomment-641767991?
I'm wondering what caused this issue, @JudahBella how are you running z2m? Then I can provide some instructions to downgrade zigbee-herdsman-converters (which is responsible for the device control)
I'm wondering what caused this issue, @JudahBella how are you running z2m? Then I can provide some instructions to downgrade zigbee-herdsman-converters (which is responsible for the device control)
I'm running z2m as a HA addon. I'm not in a hurry to fix this, as setting transition
makes it work normally again.
@JudahBella can you ssh into your system and execute:
# Enter z2m container
docker exec -it $(docker ps | grep zigbee2mqtt | cut -d" " -f 1) /bin/bash
cd app
# Install zigbee-herdsman-converters version that with z2m 1.33.0
npm install zigbee-herdsman-converters@15.67.1
exit
# Restart z2m container
docker restart $(docker ps | grep zigbee2mqtt | cut -d" " -f 1)
check if it works now
@JudahBella can you ssh into your system and execute:
# Enter z2m container docker exec -it $(docker ps | grep zigbee2mqtt | cut -d" " -f 1) /bin/bash cd app # Install zigbee-herdsman-converters version that with z2m 1.33.0 npm install zigbee-herdsman-converters@15.67.1 exit # Restart z2m container docker restart $(docker ps | grep zigbee2mqtt | cut -d" " -f 1)
check if it works now
I'm running HAOS on a VM and don't have any way to SSH into the OS layer at the moment, but let me see what I can do..
I've got a console, bashed in but no app directory:
pwd tells me I'm already in /app
so I'm gonna skip that line and try the rest
Nope, stuck
Don't mind me poking around, but it seems like between 1.33.0 and 1.33.1, ikea.js was refactored to ikea.ts. Could the refactor have caused anything?
I notice that in ikea.js, bulbOnEvent
tested for undefined
quite aggressively:
if (state !== undefined && state.color_options !== undefined && state.color_options.execute_if_off === true) {
device.endpoints[0].write('lightingColorCtrl', {'options': 1});
}
if (state !== undefined && state.level_config !== undefined && state.level_config.execute_if_off === true) {
device.endpoints[0].write('genLevelCtrl', {'options': 1});
}
if (state !== undefined && state.level_config !== undefined && state.level_config.on_level !== undefined) {
let onLevel = state.level_config.on_level;
if (typeof onLevel === 'string' && onLevel.toLowerCase() == 'previous') {
onLevel = 255;
} else {
onLevel = Number(onLevel);
}
if (onLevel > 255) onLevel = 254;
if (onLevel < 1) onLevel = 1;
device.endpoints[0].write('genLevelCtrl', {onLevel});
}
whereas in ikea.ts it seems to have all but disappeared:
const colorOptions = state.color_options as KeyValue;
if (colorOptions?.execute_if_off === true) {
device.endpoints[0].write('lightingColorCtrl', {'options': 1});
}
const levelConfig = state.level_config as KeyValue;
if (levelConfig?.execute_if_off === true) {
device.endpoints[0].write('genLevelCtrl', {'options': 1});
}
if (levelConfig?.on_level !== undefined) {
const onLevelRaw = levelConfig.on_level;
let onLevel: number;
if (typeof onLevelRaw === 'string' && onLevelRaw.toLowerCase() == 'previous') {
onLevel = 255;
} else {
onLevel = Number(onLevelRaw);
}
if (onLevel > 255) onLevel = 254;
if (onLevel < 1) onLevel = 1;
device.endpoints[0].write('genLevelCtrl', {onLevel: onLevelRaw});
}
I do notice that now in the UI, if the transition
variable is blank and I click on it but not enter any value and click away, it saves:
but when I try to turn it on or off afterwards, the following error occurs:
I will then have to enter a number into transition
before the bulb will work again. It likely has nothing to do with this issue but just thought to let you know.
Also, from my very limited understanding, bulbs seem like they should be turned on with the genLevelCtrl
command via bulbOnEvent
, yet without transition
set, the logs stated that genOnOff
was being sent instead. I'm trying to hunt down where and how a bulb would be sent genOnOff
but I can't find it.
apk add nodejs
before executing the npm
command?transition: ''
with z2m 1.33.0?Just to chime in, i had all my groups configured without transition
at all. setting transition: 1
actually didn't help with it.
docker compose exec zigbee2mqtt sh
apk add nodejs npm
npm install zigbee-herdsman-converters@15.67.1
exit
docker compose restart zigbee2mqtt
groups:
...
'2':
friendly_name: Deckenleuchte Wohnzimmer
devices:
- 0xd0cf5efffeec790b/1
- 0xbc33acfffe16bc4c/1
- 0xd0cf5efffef15440/1
Had no effect. Still turning on with 0% brightness.
- Can you do a
apk add nodejs
before executing thenpm
command?
Ok will try again when I have time
- Could it be that you had a
transition: ''
with z2m 1.33.0?
Not sure for devices.yaml
(likely not) but definitely not for groups.yaml
I am having the same issue with my IKEA ICPSHC24-30EU-IL-1. After turning on the brightness is on 1. HASS still has 255 as value.
I use Docker with 1.33.1 running.
strangely, it only affects one group, other groups behave correctly.
tried a bit with different versions of z2m. defenitly not a version issue. when turning on, it still gets brightness 1. but if i turn it on with an brightness value, the value is correct.
maybe use the known value as attribute while turning on?
Over the past few weeks more and more IKEA devices started acting up. Starting at the lowest brightness when turning on. Also Zigbee2MQTT was complaining about not having a valid transition
property:
Error 2023-11-06 11:52:57 Publish 'set' 'state' to 'Closet Bulb 2' failed: 'Error: 'transition' is not a number, got string ()'
Which I didn't even touch. I have set the transition
property on all my devices to 0 now. I hope this keeps working ๐.
But what I also noticed is that this behavior only happens when toggling a light from a Zigbee group. Whenever I toggle the light independently, it just works ๐คท. I also tried downgrading from 1.33.1 to 1.33.0 but to no avail.
So for now I just created the same groups within Home Assistant. Which is AFAIK not ideal for my Zigbee network. But as a workaround would be sufficient for now, I guess.
Hello I just seen I have the Same issue. I have same 5 Ikea LED1837R5 and issue happen on 2 of them. It happens when switching them on individually if transition value is blank. If transition is set to 0 then it works.
Looks like it have start happening after I upgrade from 1.33.0 to 1.33.2
A few weeks ago this problem started for 1 of 3 lamps (IKEA T2037 v1.0.006) in a group. Fast forward, 2/3 lamps have this problem, then all of them. I usually use a Ubisys S2 bound to toggle the group with the lamps (using zigbee; they stay powered on). On each transition from OFF to ON the brightness is reset to 1. I set up reporting for "brightness" so that's easy to verify. This happens all the time when using the switch. Keep in mind that the switch only sends toggle to the OnOff cluster.
It also happens when I toggle the group using MQTT directly (simulating the switch) unless I specify "transition: 0".
{"state": "ON", "brightness":200} // Reset
{"state": "OFF"}
{"state": "ON"} // Brightness = 1
{"state": "ON", "brightness":200} // Reset
{"state": "OFF"}
{"state": "ON", "transition":0} // Brightness = 200
The switch triggers this behavior even when z2m is stopped (so it can't possibly inject a message). I actually suspect a volatile bug in the firmware because I was able to temporarily fix the issue by powering down the devices (for a good while!). But the behavior quickly reappears unfortunately.
My (very weak) guess is that some recent change to z2m triggers this bug in the firmware that breaks until powered down.
Looking at the ZCL it states under "3.10.2.1.1 Effect of On/Off Commands on the CurrentLevel Attribute":
For ON:
Temporarily store CurrentLevel. Set CurrentLevel to the minimum level allowed for the device. Move CurrentLevel to OnLevel, or to the stored level if OnLevel is not defined, over the time period OnOffTransitionTime.
So it appears as if the last step simply fails. The big question is: why now? And how could z2m trigger this bug.
@Jabe I've compared to toZigbee code in 1.33.0 vs 1.33.2, but there are not differences regarding this. Do you know from which version this bug starts occurring?
I'm afraid I also cannot offer more insight except that for me the problem occurred the upgrade to koenkk/zigbee2mqtt:1.33.2, whereas downgrading to koenkk/zigbee2mqtt:1.33.1 seems to have fixed the problem. Symptoms that occurred are the lowest brightness issue here in the thread, as well as repeated connectivity issues (6000ms or 10000ms timeouts, sadly don't remember exactly) after 24-48h.
After the downgrade, all problems vanished "magically" without any change in config etc.
I am also having this issue since a few versions now. If I can help with debugging let me know, I have a bunch of IKEA light bulbs and they are all having the brightness problem.
For me if I kill the power to the lights while they are turned off from HA, then when I turn the power on again the brightness is set to a minimum even though if I check HA the brightness is reported as maximum.
Having the same issue suddenly since a few days, sadly downgrading to 1.33.1 didn't solve it for me, neither did all the transition stuff. In my case the lights turn on at brightness 1 no matter what method I use, be it from HA, my STYRBAR remote or the Z2M frontend. Both bulbs are in a group, but turning them on separately has the same behaviour.
I'm also suffering with this issue. I have just recently started with Home Assistant so I have no prior version history with Z2M and started on 1.34.0. I have LED1949C5 and LED2003G10 bulbs. If the transition value is blank in the Z2M setup GUI then the bulbs will turn on at 1 brightness, and report 255 brightness to HA, despite the previous state. Setting a transition of 0 or 1 resolves the issue. However, I still have this problem with groups of lights. From what I can tell there is no way to set the transition of groups through the GUI but when I set the transition in the configuration.yaml that doesn't seem to work.
@Koenkk it's been too long to say when it started, probably with 1.33.0 or even earlier. I usually don't need these lights until the days get shorter, so I might not have noticed until around October. Also, since it only affected 1/3 of the lights in the group I kinda dismissed it in the beginning.
I still don't think the issue can be fully explained by z2m alone and it's very odd. I can't come up with a reason why this happens except though a firmware bug.
@Jabe could you provide the herdsman debug log of doing the sequence which triggers the bug?
@Koenkk okay I've captured three scenarios. There is some noise in the data from other devices which I've XXX'ed out. Please see the the list of relevant device addresses at the end too. Here is my setup:
There is a 1 sec delay between each call. Each call was made using mosquitto_pub.
Test 1 was made with this:
{"state": "ON", "brightness":200} // Reset
{"state": "OFF"}
{"state": "ON"} // Brightness = 1
Test 2:
{"state": "ON", "brightness":200} // Reset
{"state": "OFF"}
{"state": "ON", "transition":0} // Brightness = 200
Test 3 I made with the physical toggle switch. I started with the lights ON at brightness=203 and toggled OFF then ON using the switch. The lights were at brightness=1 after that as expected. (I'm not sure I captured everything here.) test3.log
Addresses:
Diele Deckenlampe 1 - 0x70ac08fffef6f69f (IKEA STOFTMOLN ceiling/wall lamp WW37)
Diele Deckenlampe 2 - 0xf4b3b1fffe250f1f (ditto)
Diele Deckenlampe 3 - 0x70ac08fffef6e86a (ditto)
Diele/Flur Wandschalter - 0x001fee000000642d (Ubisys S2)
What value is returned when reading the onLevel
?
Read result of 'genLevelCtrl': {"onLevel":0}
Oh!
I've restored full functionality by setting it to 0xff (previous), including my scene switching when OFF. ๐ Somehow the attrib must have slipped in over time.
@villyvitz
I'm also suffering with this issue. I have just recently started with Home Assistant so I have no prior version history with Z2M and started on 1.34.0. I have LED1949C5 and LED2003G10 bulbs. If the transition value is blank in the Z2M setup GUI then the bulbs will turn on at 1 brightness, and report 255 brightness to HA, despite the previous state. Setting a transition of 0 or 1 resolves the issue. However, I still have this problem with groups of lights. From what I can tell there is no way to set the transition of groups through the GUI but when I set the transition in the configuration.yaml that doesn't seem to work.
You'll have to add transition: 1
to groups.yaml
for each group of lights you want to manually override transition, i.e.:
'1':
friendly_name: Dry Kitchen Pendants
transition: 1
devices:
- 0x804b50fffefb392a/1
- 0x84fd27fffe258a5a/1
- 0x84fd27fffe03dab1/1
@Koenkk I'm so sorry but I haven't gotten to downgrading herdsman and providing logs, we've had a newborn since July and I really haven't had the time to work on this, as we kinda need the house to just work during this season. Hope the logs from the rest of the community have been sufficient for you. I'll try to circle back again when I have some downtime.
Good news is that the transition
workaround has been working solidly, even with Z2M now at 1.34.0-1
(I leave auto update turned on). Just that it is rather taxing on the network when many lights need to be turned on or off at the same time (like with a scene), it takes awhile for all lights to reach the intended state, but that's mostly with the scenes we use when leaving or arriving home anyway so it's ok. Our curtain motors generate a lot more traffic than the lights (it updates the position of the curtain continuously until it reaches the destination) so I have adjusted some of our major scenes to not adjust certain curtains to ease the traffic a little, like when we arrive home, so that we can still toggle the lights when the curtains are still being opened. Previously when 9 curtains are being opened simultaneously, I couldn't toggle any lights at all until all the curtains were done opening. I've cut down to 5 and it's a lot better now.
@alex3305
Over the past few weeks more and more IKEA devices started acting up. Starting at the lowest brightness when turning on. Also Zigbee2MQTT was complaining about not having a valid
transition
property:Error 2023-11-06 11:52:57 Publish 'set' 'state' to 'Closet Bulb 2' failed: 'Error: 'transition' is not a number, got string ()'
Which I didn't even touch. I have set the
transition
property on all my devices to 0 now. I hope this keeps working ๐.
This happens when you click into the transition input box in the GUI, but enter nothing, and click away. The GUI autosaves it as an empty string (rather than do nothing/null/zero), causing this error.
Once you click it, you must put something in, as the GUI will autosave. If you want to revert it to default, you'll have to manually delete the transition:
line generated in devices.yaml
.
@JudahBella Like I explicitly said in my comment, which you have even quoted, I didn't touch the transition property input. I barely use Zigbee2MQTT's UI because I control all of my devices through Home Assistant. The behavior also appeared on more and more devices as time went by. I even manually set the transition to 1
or 0
to exclude any misconfiguration on my end, like I also mentioned. But to no avail.
What did happen though, is that some devices that I 100% knew I had set the transition property on, reverted to an empty field after a day or so. And re-setting the value would sometimes make it disappear again ๐คท. I'm also confident that everything worked perfectly prior and I didn't make any configuration changes on my end. Except updating Zigbee2MQTT.
However after switching from Zigbee to Home Assistant groups I haven't been affected by this issue since. Some devices within groups also seem to respond quicker. Which I find a tad peculiar.
Thanks @Jabe! So to all who are experiencing this issue, you can fixed it by doing a write in the z2m frontend like this (for attribute select onLevel
)
I'm still puzzled why the onLevel
was set to 1 in the first place, looking at the whole z2m code base, this is only done when the users sets the level_config
. Given that only TRADFRI bulbs are affected, it could also be a bug in their firmware.
@Koenkk is there a way to set this attribute at the group level? I've tried this fix for the individual bulbs, which has worked, but z2m grouped bulbs are still affected.
@Koenkk thank you for your hard work! As always.
I've previously stated that I was able to restore the correct behavior with a long power cycle, but later I couldn't reproduce that. In hindsight, there might be a possible explanation.
The bug stopped for a short time when my home had a power outage of about 5 minutes, so the bulbs came back online without z2m being online (the host is much slower). I might have tested it immediately without z2m being able to listen to deviceAnnounce. On later tests I just power cycled the bulbs with z2m being online, which didn't work. Looking at the code introduced in https://github.com/Koenkk/zigbee-herdsman-converters/commit/c99f72d96dbc63b3c5c19982b9b9849ca933b48f, maybe I had a value (like null or "") for state.level_config.on_level
in my DB, causing z2m to set onLevel to 1 on deviceAnnounce. This could close the loop considering the behavior I noticed. How would one check the DB value? And obviously, how could such a value end up there?
@villyvitz no there's not. The attribute is stored on the device and it shouldn't make a difference how you get the device to turn on, either directly or through a group.
And the story continues.
I had a look in the database.db of a backup from last week and indeed it had onLevel = 0 persisted:
And now for the fun part: it came back! While checking my current database.db I noticed this:
This reflects the actual state right in this moment: One light is indeed at brightness = 1, the other two are at 203. Somehow onLevel got back in the DB.
Now I read the value using the dev console and only one device reported 0, contrary to the DB.
@Jabe Like I said in my comment yesterday, that also happened to me on the transition property. But only when I use Zigbee groups. Although like you said earlier, that shouldn't make a difference.
I also tried to read out the onLevel
but that doesn't seem to work for me ๐
Clicking Lezen (or Read) doesn't do anything. Same for Write. Reading an unsupported attribute yields an error.
@Jabe this should only happen when there is an on_level
for this device in the data/state.json
file, can you check that?
@Koenkk looking at the backup again, it's set to 0 in state.json:
"0x70ac08fffef6f69f": {
"update": {
"state": "idle",
"installed_version": 65542,
"latest_version": 65542
},
"state": "OFF",
"last_seen": "2023-12-07T16:27:32.352Z",
"brightness": 203,
"linkquality": 94,
"power_on_behavior": "off",
"level_config": {
"on_level": 0
},
"color_mode": "color_temp",
"color": {
"x": 0.4348,
"y": 0.4033
},
"color_temp": 330
}
Right now it's set to "previous"
because I've reset the lights again earlier today.
So to all who are experiencing this issue, you can fixed it by doing a write in the z2m frontend like this (for attribute select
onLevel
)
Thanks! this fixed the problem for me (2x IKEA LED 1836G9 with firmware 2.3.093).
I finally solved this. I don't know why, but the config value for LevelCtrl -> startUpCurrentLevel
was set to 255. This is an invalid value since the maximum is 254. So whenever my IKEA lights went through a cold start while being off in HA, they would start at level 1 brightness. As a note LevelCtrl -> onLevel
was already correctly set to 254 but it made absolutely no difference.
After I wrote 254 to startUpCurrentLevel
the problem is now gone!
@Jabe try to:
"level_config": {
"on_level": 0
},
onLevel
@Jabe try to:
- stop z2m
- remove the following from your state.json
"level_config": { "on_level": 0 },
- start z2m
- write
onLevel
- see if issue is fixed.
Writing On_Level 0 did not work for me. After writing 255 to On_Level my bulb worked correctly again, finally saving my brightness. Have this issue with LED1624G9 and LED1836G9
@Xitro01, if you power-cycle the bulb, does the issue return?
@Xitro01, if you power-cycle the bulb, does the issue return?
Ah yeah it does, that is kind of worthless.
@Koenkk I've been busy these past few days but I just tried it.
"level_config": { "on_level": "previous" }
confused ??"level_config": { "on_level": 0 }
. confused ??level_config
from state.json"level_config": { "on_level": 0 }
Now it gets wild, but I did see it happen: When I power cycle the lights, for a short moment the dev console reads 255 after the devices come back online, then it quickly changes to 0. But that at least explains why state.json sometimes has a 0 and sometimes a previous, even in a mixed state.
I could imagine that there's some fighting going on between the int values and "previous", maybe on device read/write and when applying the value from state.json. Also 0 gets written on deviceAnnounce to the device when state.json has no value for level_config (see step 11).
I have the same problem with a pair of IKEA [LED1925G6], that will turn on at 1 Tried setting the onLevel to 255 in the dev console and that works. But haven't tried power cycling anything yet.
This might also be related. I have noticed that if I set transition: 0 or anything on a group it will behave strange. 1: Have a group with lights that have different brightness levels. 2: Change the brightness of one light in the group in HA 3: Turn the whole group off in HA 4: Turn the group on again and all members will have the same brightness as the last set member had when turned off.
@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.
@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.
it's possible to add on_level and startUpCurrentLevel values manageable via WebUI?
@mrmaximas yes, see https://github.com/Koenkk/zigbee2mqtt/issues/19211#issuecomment-1850725742
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 Lights
to 100% causes all bulbs in the group to be at 100%:Toggling
Common Toilet Lights
group OFF:Toggling
Common Toilet Lights
group ON causesCommon Toilet Ceiling
to be dim:Toggling
Common Toilet Ceiling
OFF directly:Toggling
Common Toilet Ceiling
ON directly withtransition
value indevices.yaml
deleted, bulb turns on but is dim:Setting
transition
to1
and togglingCommon Toilet Ceiling
ON directly causes bulb to turn on to the correct previous brightness:It seems that when the
transition
option is set, togglingCommon Toilet Ceiling
ON directly will causegenLevelCtrl.moveToLevelWithOnOff({"level":254,"transtime":10}
to be sent andCommon Toilet Ceiling
will turn on to the correct previous value. With thetransition
option cleared,genOnOff.on
is sent instead, causingCommon Toilet Ceiling
to be dim.Regardless, toggling the group ON always always causes
genOnOff.on
to be sent, causingCommon Toilet Ceiling
to 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.