Koenkk
The brightness of bulbs is not updated correctly when set to 0%
What happened?
After updating from 1.33.2 to 1.40.0, I'm facing the issue that the brightness value of a bulb is not correctly updated when the value is set to zero by using both OpenHab 3.4 or the Zigbee2MQTT UI.
When I set the brightness to 50%, the bulb receives the state value "on" and the brightness value of "127", which is the correct behavior. However, when I turn the brightness to 0%, the bulb receives the state value "off" and the brightness is kept at "127". Hence, it's turned off as expected but keeps the brightness value of 127, which is not the correct behavior.
What did you expect to happen?
The state value should turn to "off" and the brightness value should be set to "0", like in 1.33.2.
How to reproduce it (minimal and precise)
To replicate the issue, I did the following with both versions:
- Setting the brightness of a bulb to 50% (works in both versions correctly).
- Setting the brightness to 0% (works only in 1.33.2 correctly).
Zigbee2MQTT version
1.40.0
Adapter firmware version
20210708
Adapter
zStack3x0
Setup
Pi using Raspbian
Debug log
Version 1.33.2 Zigbee2MQTT:info 2024-09-04 11:17:42: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/update-state', payload 'available' Zigbee2MQTT:info 2024-09-04 11:17:42: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/update-installed_version', payload '553788977' Zigbee2MQTT:info 2024-09-04 11:17:42: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/update-latest_version', payload '587806257' Zigbee2MQTT:info 2024-09-04 11:17:42: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/update_available', payload 'true' Zigbee2MQTT:info 2024-09-04 11:17:42: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/brightness', payload '0' Zigbee2MQTT:info 2024-09-04 11:17:42: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/state', payload 'OFF' Zigbee2MQTT:info 2024-09-04 11:17:42: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/linkquality', payload '129'
Version 1.40.0 [2024-09-04 12:09:34] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/update-state', payload 'available' [2024-09-04 12:09:34] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/update-installed_version', payload '553788977' [2024-09-04 12:09:34] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/update-latest_version', payload '587806257' [2024-09-04 12:09:34] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/update_available', payload 'true' [2024-09-04 12:09:34] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/brightness', payload '127' [2024-09-04 12:09:34] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bulbs/livingroom_spot2/state', payload 'OFF'
So what do you expect? It seems the normal behavior for this kind of thing. 0% means "no light" and that specific value (the Zero) could not be supported by many bulbs/lights because the normal range is between 1 and 255. If the light would be set really to 0% could even remains "on" which is a non-sense and maybe neither supported by the bulb/led. If you immediately set 0 from a starting point of 127 which number would you like to set for that light while at that status? 0? It's not supported. 1? No any-one set it to that specific value so it's not acceptable. Then? 🤷♂️ The only solution is to left latest value...so it depends on you to set desired Last_value before brings it to Zero.
Sorry, but I have to disagree. This is not the normal behavior, and I argue that the behavior was correct in version 1.33.2. If I set the brightness of a bulb to a value, I always expect to have this value reflected in the bulb's actual state and its brightness variable, regardless if it is set to 0, 127, 255, or any other value. I appreciate that the binary state of the value also changes to off when I set the brightness to 0, but that is also correct behavior.
In version 1.40.0, I set the brightness of the bulb to 0, the bulb turns off, the binary state shows off, and the brightness value is kept to the last value, which is the wrong value. As you said, no one set this value, it's deprecated! If I now query the brightness from the bulb, I receive a wrong value, as its true brightness is indeed 0 and not the value that was set before the brightness was set to 0. Having this behavior, my whole automation system is showing wrong values for all bulbs that have been turned off.
I also have to disagree with the range you mentioned. A byte value always ranges from 0 to 255 and therefore supports 256 different permutations, and all the devices I have used so far showed this (correct) behavior. If there is a bulb that supports only 1 to 255, this device should implement an exceptional behavior, but all devices that support a range from 0 to 255 should support my explained correct behavior.
I've understood what you said, but set a value to Zero (that remains Zero until changed again) means that even if the bulb initially was auto-turned off due to that value, a subsequent "ON" (just the "turn_on" command without any brightness parameter) command at which Value will set the brightness? To Zero again? But it would means that it would turn-off again automatically 😅 it doesn't have any sense....
A turned off light needs a positive brightness value to be used when a "just turn_on" command is sent to it or it cannot be turned_on if the final brightness is Zero again 🤷♂️
Yes, it's the same when you turn it off using a classical binary switch that cuts off its power. If you turn on the switch again, the bulb changes its brightness to a default brightness value that represents on (as standard behavior). I would argue that off is 0 and on is 255.
But I agree, the "correct" behavior is a question of definition. I would like to know from a developer whether this change was intentional. If yes, what is the exact reasoning for changing a behavior that has been established over the last years? It's causing so much trouble in the applications using it.
If the bulb in your example is a Smart one it's oblivious that if the hardware doesn't have a storage memory where save latest state then it will returns to a default brightness when the Power is lost....but normal Smart bulbs (at least all those I have) if they receive the "ON" command then they returns to the last brightness value they had before the last "OFF" command. This behavior works because they have a volatile memory where store latest Values but it's lost on power outages.
Unfortunately not: "ON" just means "some light is visible" and it's valid between 1 and max-value (usually 255, but someone has only 127). "OFF" means Zero but, as I prev explained, if the latest brightness value is left to Zero then an "ON" simple command will do nothing because it would try to turn it OFF immediately again.
In Z2M you have 2 controllers for a dimmered light: a SWITCH and a SLIDE/NUMBER. It means the ON/OFF simple commands "lives" for their own without knowing anything about brightness. In fact the message payload of a simple ON command is usually just "{state: ON}" without any brightness value. This because the bulb have just to turn ON and it usually chooses latest brightness value (if no any power outages occurred meanwhile). We CAN add the brightness value, but it's optional an it usually just exec two action sequentially: ON + set_brightness.
My OSRAM bulbs have a special EEPROM/NAND memory where to store latest config (color brightness, temp, hue, etc...) but it is used only when a special payload is sent to it like a "now you can save this config as default value" and when turned ON again it will return to that saved config even after a power outage. Obliviously this memory has a rewrittable count limit due to nature af all memory of this kind, and this is why those OSRAM bulbs doesn't saves latest config automatically each time a value is changed but only when the user really wants to do it.
I understand your argumentation, but it still doesn't explain if the change was intentional. The new behavior in 1.40.0 still has two (and probably more) significant drawbacks:
-
The brightness value of the bulb doesn't always represent the current_brigthness of the bulb, but in cases where the light is turned off the last_brightness. I argue that a brightness value should always contain the current brightness, and there should be a separate last_brigthness value. At the moment, it's not possible anymore to control the bulb appropriately sorely using the brightness channel, which was possible before. You always have to combine state and brightness.
-
The first point leads to the problem that applications that previously used a single slider element to control a bulb do not work anymore as they now show the wrong state (i.e. brightness) of the bulbs when it is turned off. In fact, you now need a combination of a switch and slider element to control this bulb appropriately where a slider was previously sufficient.
The best thing would be a parameter in Z2M where you can define the behavior as you need it.
And it's getting even more confusing when we talk about a color bulb.
I just tried how a color bulb behaves when I set the brightness to 0 using the HSB color space and the color channel. In this case, the bulb turns off and sets the brightness of the brightness channel to the last value before it was turned off. However, it keeps the set color value after the change and does not set it back to last value before it was turned off. Meaning that we have inconsistent behavior between the different channels.
According to your argumentation @emandtf, the color should be set back to the last value before it was turned off.
I did some further investigation. The behavior changed between 1.39.1 and 1.40.0 and there is no note in the changelog that indicates that the change was intentional, so I still assume it is indeed a bug.
Could you provide the debug log when changing brightness to 0% on both 1.39.1 and 1.40.0?
See this on how to enable debug logging.
While preparing the logs, I updated the version to 1.40.2, and apparently, the bug is fixed now.