state inconsistency when turning Osram bulb off using brightness parameter #2566

user1o1 · 2019-12-19T19:43:49Z

Hey, unfortunately the following behavior is back:

The bulb is turned off, but that was as well the case before (sorry if I was misleading). Strangely enough, now the previous brightness is returned instead of always 1. The same behaviour can be applied to Tradfri bulbs (dimmable and dimmable + CT models).

this is how the mqtt communication looks like

I would be happy if the device returned {"brightness": 0} instead of {"brightness": 50} just as I've set it.

Originally posted by @thewilli in #1321 (comment)

The text was updated successfully, but these errors were encountered:

Kryzek · 2019-12-21T05:40:40Z

I believe that ”brightness 0” gets translated to ”state off” inside the bulb firmware so it acts as it receives turn off command. If you turn off bulb normally it also reports state as off and last value of brightness it was using? This is what I expect happen since when turned on it will resume to last brightness it was using.

user1o1 · 2019-12-22T18:41:09Z

Hi Kryzek, thanks for your response. The current behavior is not consistent:

Bulb is on with "brightness":25
a) i send "brightness":0 the zigbee2mqtt response is '{"state":"OFF","brightness":25}'
b) i send "state":"OFF" the zigbee2mqtt response is '{"state":"OFF","brightness":0}'
in both cases if i send "state":"ON" it goes back on with "brightness":25

So the answer to your question "If you turn off bulb normally it also reports state as off and last value of brightness it was using?" --> No

stale · 2020-02-20T19:29:31Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

user1o1 · 2020-02-27T20:08:29Z

Hi @Koenkk do you have any solution for this behavior?

Koenkk · 2020-02-27T20:21:40Z

Could you provide the complete debug logging of this issue?

To enable debug logging set in configuration.yaml:

advanced:
  log_level: debug

user1o1 · 2020-02-28T19:28:08Z

Hi Koenkk thanks for your response. Sorry for the delay, here comes the log:
log.txt

Koenkk · 2020-02-29T14:00:54Z

I understand the problem now.

The questions is what the behaviours should be. My current opinion is that this is expected behaviour.

brightness = 0 will be translated to state = off
When state = off the bulb is off, so the brightness value is not relevant anymore
The problem comes when the bulb is turned on again, it will turn on the brightness were it was turned off with, e.g. 50, if the last know state of the bulb would be {"state": "OFF", "brightness": 0}, turning it on will result in {"state": "ON", "brightness": 0}, the brightness value will be incorrect now as the last state is brightness = 0.

user1o1 · 2020-02-29T18:28:43Z

the expected behavior for your last case is at the moment not working.

turn it off with "brightness":0.0 ->
Received MQTT message on 'zigbee2mqtt/Stehlampe_Wohnzimmer/set' with data '{"brightness":0.0}' Publishing 'set' 'brightness' to 'Stehlampe_Wohnzimmer' MQTT publish: topic 'zigbee2mqtt/Stehlampe_Wohnzimmer', payload '{"state":"OFF","brightness":25}'
and right after that i turn it on with "state":"ON" ->
Received MQTT message on 'zigbee2mqtt/Stehlampe_Wohnzimmer/set' with data '"state":"ON"' Publishing 'set' 'state' to 'Stehlampe_Wohnzimmer' MQTT publish: topic 'zigbee2mqtt/Stehlampe_Wohnzimmer', payload '{"state":"OFF","brightness":0}'

in my case is the problem that you translate brightness = 0 to state = off
and after that the status answer from the bulb is: "state":"OFF","brightness":25
in openhab the slider for brightness will jump back to 25 but the bulb is off

nobbi1991 · 2020-04-02T09:33:18Z

I have the same problem.

I use a “Philips Hue Aurelle” with zigbee2mqtt and control it from openHAB. When I set the brightness to 0:
{"brightness":0}

I get the following return:
{"state":"OFF","brightness":255,"color_temp":201.835596345,"linkquality":99}

My problem is, that I use a slider-item to control the brightness / OnOffState and when I slide to 0 the light switches off, but the slider jumps back to the old value (here 100%)
Is it possible to always return brightness 0 if the state is OFF?

user1o1 · 2020-05-23T22:54:52Z

Hi @Koenkk i have upgraded to the latest dev branch and run any ota update of my osram bulbs. Unfortunately is the behavior still the same

Koenkk · 2020-05-24T13:57:41Z

This issue should be fixed in the latest dev branch. Please confirm (ping @Gio76).

When the bulb state == OFF, brightness will always be 0.

Gio76 · 2020-05-24T21:17:36Z

@Koenkk I tested it with the zigbee2mqtt-edge add-on and the issue is still there.

user1o1 · 2020-05-25T05:25:50Z

i´m using now: zigbee2mqtt version 1.13.1-dev (commit #409fb24) and the issue is fixed. thanks a lot @Koenkk !

Koenkk · 2020-05-25T06:22:13Z

@Gio76 please share your debug logging here

Gio76 · 2020-05-25T06:34:06Z

zigbee2mqtt:info 2020-05-25 13:30:15: MQTT publish: topic 'homeassistant/binary_sensor/0x0017880102329beb/update_available/config', payload '{"payload_on":true,"payload_off":false,"value_template":"{{ value_json.update_available}}","state_topic":"zigbee2mqtt/0x0017880102329beb","json_attributes_topic":"zigbee2mqtt/0x0017880102329beb","name":"0x0017880102329beb_update_available","unique_id":"0x0017880102329beb_update_available_zigbee2mqtt","device":{"identifiers":["zigbee2mqtt_0x0017880102329beb"],"name":"0x0017880102329beb","sw_version":"Zigbee2mqtt 1.13.1-dev","model":"Hue white and color ambiance E26/E27/E14 (9290012573A)","manufacturer":"Philips"},"availability_topic":"zigbee2mqtt/bridge/state"}'

zigbee2mqtt:info 2020-05-25 13:30:30: MQTT publish: topic 'zigbee2mqtt/0x0017880102329ad8', payload '{"state":"ON","update_available":false,"color":{"x":0.526676280311873,"y":0.41329727450763},"color_temp":500,"brightness":255}'

zigbee2mqtt:info 2020-05-25 13:30:31: MQTT publish: topic 'zigbee2mqtt/0x0017880102329ad8', payload '{"state":"OFF","update_available":false,"color":{"x":0.526676280311873,"y":0.41329727450763},"color_temp":500,"brightness":255}'

Koenkk · 2020-05-25T18:28:23Z

I don't see debug logging.

To enable debug logging set in configuration.yaml:

advanced:
  log_level: debug

Gio76 · 2020-05-26T04:11:47Z

Sorry about that, please see below:

zigbee2mqtt:debug 2020-05-26 11:10:25: Received MQTT message on 'zigbee2mqtt/0x0017880102329ad8/set' with data '{"state": "ON"}'

zigbee2mqtt:debug 2020-05-26 11:10:25: Publishing 'set' 'state' to '0x0017880102329ad8'

zigbee2mqtt:debug 2020-05-26 11:10:27: Received MQTT message on 'zigbee2mqtt/0x0017880102329ad8/set' with data '{"state": "OFF"}'

zigbee2mqtt:debug 2020-05-26 11:10:27: Publishing 'set' 'state' to '0x0017880102329ad8'

Gio76 · 2020-05-28T07:37:28Z

@Koenkk setting homeassistant: false solved the issue. Thanks again for solving this matter so quickly 🙏

nbarrientos · 2020-06-11T13:09:49Z

For info on the Home assistant side a patch for the Prometheus exporter has been shipped in the latest version as an extra protection in case this bug shows up again in the future:

home-assistant/core#36134

georgeavd · 2020-09-02T14:34:47Z

the expected behavior for your last case is at the moment not working.

turn it off with "brightness":0.0 ->
Received MQTT message on 'zigbee2mqtt/Stehlampe_Wohnzimmer/set' with data '{"brightness":0.0}' Publishing 'set' 'brightness' to 'Stehlampe_Wohnzimmer' MQTT publish: topic 'zigbee2mqtt/Stehlampe_Wohnzimmer', payload '{"state":"OFF","brightness":25}'
and right after that i turn it on with "state":"ON" ->
Received MQTT message on 'zigbee2mqtt/Stehlampe_Wohnzimmer/set' with data '"state":"ON"' Publishing 'set' 'state' to 'Stehlampe_Wohnzimmer' MQTT publish: topic 'zigbee2mqtt/Stehlampe_Wohnzimmer', payload '{"state":"OFF","brightness":0}'

in my case is the problem that you translate brightness = 0 to state = off
and after that the status answer from the bulb is: "state":"OFF","brightness":25
in openhab the slider for brightness will jump back to 25 but the bulb is off

What is wrong with this behaviour. This is the same as for an 'analog dimmer'?
The result is now the when switching the bulb ON the brightness is 0 and not returned to the previous value (E.g. 48).

@Koenkk Is there a workaround for this (see my ticket #4237 )

user1o1 · 2020-09-03T18:07:42Z

the expected behavior for your last case is at the moment not working.
turn it off with "brightness":0.0 ->
Received MQTT message on 'zigbee2mqtt/Stehlampe_Wohnzimmer/set' with data '{"brightness":0.0}' Publishing 'set' 'brightness' to 'Stehlampe_Wohnzimmer' MQTT publish: topic 'zigbee2mqtt/Stehlampe_Wohnzimmer', payload '{"state":"OFF","brightness":25}'
and right after that i turn it on with "state":"ON" ->
Received MQTT message on 'zigbee2mqtt/Stehlampe_Wohnzimmer/set' with data '"state":"ON"' Publishing 'set' 'state' to 'Stehlampe_Wohnzimmer' MQTT publish: topic 'zigbee2mqtt/Stehlampe_Wohnzimmer', payload '{"state":"OFF","brightness":0}'
in my case is the problem that you translate brightness = 0 to state = off
and after that the status answer from the bulb is: "state":"OFF","brightness":25
in openhab the slider for brightness will jump back to 25 but the bulb is off

What is wrong with this behaviour. This is the same as for an 'analog dimmer'?
The result is now the when switching the bulb ON the brightness is 0 and not returned to the previous value (E.g. 48).

@Koenkk Is there a workaround for this (see my ticket #4237 )

Hi,
i explain what i think was wrong:
If i send brightness = 0, i will both brightness = 0 and state = off.
If i send state = off it is okay if the status from the bulb is "state":"OFF","brightness":25
The problem was that zigbee2mqtt automatically translate brightness = 0 to state = off. so my slide begin dancing.....

georgeavd · 2020-09-04T09:00:38Z

Hi,
If you like to have state=0ff when brightness=0 then this can be solved in your domotica configuration, but should not be taken care off in an interface like zigbee2MQTT is. This results in unexpected behaviour for all other users.
The zigbee2MQTT-interface should be transparent and only act as a protocol-converter (correct me if I am wrong) between Zigbee and MQTT.

In E.g. Domoticz, Node Red or HomeAssisant you can configure the desired response (state=off) when brightness=0 is received.

Pockrandt · 2020-09-04T11:04:08Z

Sorry this doesn't make any sense.

When you request a bulb to go to zero brightness it should turn off.
There is no other way for the bulb to get in the requested state other than turning off.

When a bulb is off its actual/physical brightness IS 0.

I think you need something like "lastbrightness".
But all bulbs I know return to the last state if you simple send a "on".

Koenkk · 2020-09-04T11:22:30Z

Sorry this doesn't make any sense.

What do you refer to with "this"?

Pockrandt · 2020-09-04T11:23:53Z

Sorry this doesn't make any sense.

What do you refer to with "this"?

returning any brightness beside 0 when a bulb is off.

sjorge · 2020-09-04T11:24:05Z

What do you refer to with "this"?

I think that a bullb will return a report of a brightness value > 0 when also reports a state of off.

Yet this is what I see most of my bulbs doing when looking at a packet capture or debug logging

edit:

Just enabled debug logging and ran this on the log:

[root@amethyst ~]# tail -f $(svcs -L zigbee2mqtt) | grep Level
Zigbee2MQTT:debug 2020-09-04 11:26:29: Received Zigbee message from 'kitchen/table_lights/bulb2', type 'attributeReport', cluster 'genLevelCtrl', data '{"currentLevel":254}' from endpoint 1 with groupID 0
Zigbee2MQTT:debug 2020-09-04 11:26:58: Received Zigbee message from 'kitchen/workarea_lights/bulb3', type 'attributeReport', cluster 'genLevelCtrl', data '{"currentLevel":254}' from endpoint 1 with groupID 0
Zigbee2MQTT:debug 2020-09-04 11:26:58: Received Zigbee message from 'kitchen/workarea_lights/bulb2', type 'attributeReport', cluster 'genLevelCtrl', data '{"currentLevel":254}' from endpoint 1 with groupID 0

Currently there are 0 bulbs with state=on

edit2: lets just grep for the table_lights/bulb2 while the log has not yet rotated:

Zigbee2MQTT:info  2020-09-04 10:10:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:11:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":36,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:15:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":39,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:16:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":31,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:20:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:21:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:25:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:26:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:30:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:31:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:35:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":60,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:36:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":47,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:40:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:41:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:45:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:46:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:50:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:51:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:55:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 10:56:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 11:00:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 11:01:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 11:05:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 11:06:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 11:10:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 11:11:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 11:15:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 11:16:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 11:20:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:info  2020-09-04 11:21:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:debug 2020-09-04 11:25:50: Received Zigbee message from 'kitchen/table_lights/bulb2', type 'attributeReport', cluster 'lightingColorCtrl', data '{"colorTemperature":250}' from endpoint 1 with groupID 0
Zigbee2MQTT:debug 2020-09-04 11:25:51: Received Zigbee message from 'kitchen/table_lights/bulb2', type 'attributeReport', cluster 'genOnOff', data '{"onOff":0}' from endpoint 1 with groupID 0
Zigbee2MQTT:info  2020-09-04 11:25:52: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":55,"state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:debug 2020-09-04 11:26:29: Received Zigbee message from 'kitchen/table_lights/bulb2', type 'attributeReport', cluster 'genLevelCtrl', data '{"currentLevel":254}' from endpoint 1 with groupID 0
Zigbee2MQTT:info  2020-09-04 11:26:30: MQTT publish: topic 'zigbee2mqtt/kitchen/table_lights/bulb2', payload '{"brightness":0,"color_temp":250,"linkquality":52,"state":"OFF","update":{"state":"idle"}}'

You see it clearly sending a genLevelCtrl report after sending a genOnOff report.

Koenkk · 2020-09-04T11:33:55Z

Sorry this doesn't make any sense.

What do you refer to with "this"?

returning any brightness beside 0 when a bulb is off.

So what to return for color_temp and color in this case?

I currently think it does make sense to report the values as how they are in the bulb. When state is OFF it invalidates brightness, color_temp, color. As can be seen in the log of @sjorge this is also how Zigbee bulbs works.

sjorge · 2020-09-04T12:10:09Z

The way I read the ZCL is that the brightness value is not invalidated when the bulb is in the 'off' state.
It still has a configure brightness, this is the value it will return to when the state moves back to 'on'

Sort of like when volume for a speaker, if it was set to 50% and you turn it off the volume knob is still at 50% (unless it's one of those where the volume knob also works as the power off... ok this is a really bad example)

Pockrandt · 2020-09-04T12:20:32Z

Sort of like when volume for a speaker, if it was set to 50% and you turn it off the volume knob is still at 50% (unless it's one of those where the volume knob also works as the power off... ok this is a really bad example)

But the current volume the speaker is outputting is zero, isnt it?
It think the most sane thing would be a current_Volume, last_Volume.
(current_Bright / last_Brightness for our bulb)

color_temp and color should be reported as null / none since they physically require a brightness greater 0.

Btw we would break dimmer (tthat sends absolute brightness instead of +/-) when setting 0 isnt treated as off.

sjorge · 2020-09-04T12:40:14Z

Have two properties in the output is not the way to go IMHO, that’s even worse than what we have now. If we go that route they should be saved and restored when the state changes back to on under the same property. And ideally be updated in the background when changes get reported by the bulbs (but not published). Still not convinced it’s z2m’s job to do this though, believe it should output what the device is telling us is the value. Or when reporting is disabled, what we set it too or read from it with a get. ~ sjorge

…

On 4 Sep 2020, at 14:20, Pockrandt ***@***.***> wrote: Sort of like when volume for a speaker, if it was set to 50% and you turn it off the volume knob is still at 50% (unless it's one of those where the volume knob also works as the power off... ok this is a really bad example) But the current volume the speaker is outputting is zero, isnt it? It think the most sane thing would be a current_Volume, last_Volume. (current_Bright / last_Brightness for our bulb) color_temp and color should be reported as null / none since they physically require a brightness greater 0. Btw we would break dimmer (tthat sends absolute brightness instead of +/-) when setting 0 isnt treated as off. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Koenkk · 2020-09-04T13:48:45Z

Btw we would break dimmer (tthat sends absolute brightness instead of +/-) when setting 0 isnt treated as off.

No, setting brightness 0 will still result in an OFF.

I started to realize what was wrong after reading the comment from @georgeavd (#4237 (comment)). Quoting the sentence which triggered me:

Indeed brightness 0 = OFF, but OFF ≠ brightness 0. But that's not whats happening now.

The behaviour will come down to the following:

Set {"brightness": 0} -> {"state": "OFF", "brightness": 0}
Set {"brightness": 20} -> {"state": "ON", "brightness": 20}
Set {"state": "OFF"} -> {"state": "OFF", "brightness": 240} (where the bulb brightness was 240 before it was turned off)
Set {"state": "ON"} -> {"state": "ON", "brightness": 240} (where the bulb brightness was 240 before it was turned off)

sjorge · 2020-09-04T14:12:00Z

What in the case of

Initial state {"state": "ON", "brightness": 128}
Set {"brightness": 0} -> {"state": "OFF", "brightness": 0}
attReport with brightness of 128
??? what here ??? (a/b/c)
Set {"state": "ON"} -> {"state": "ON", "brightness": ?}

a) update the state internally but don't publish
b) update the state and publish
c) ignore the state

What afterwards when we set the state to on? If we went a) I guess we publish the cached state, but if we went c... what do we send for brightness ? 0 (as now? which is honestly so confusing) or 128 ?

c is the current behavior with 0 for the publish on state on.

Koenkk · 2020-09-04T14:28:06Z

@sjorge when 0 brightness is set, the brightness level of the bulb should be 0, so the bulb will report 0 in this case.

sjorge · 2020-09-04T14:48:50Z

OK so in case of on + 128, sending brightness=0 will set the currentLevel to 0 and also onOff to 0 afterwards?
That would indeed also cause the bulbs to report brightness of 0 via attReport I believe.

Koenkk · 2020-09-04T14:49:46Z

@sjorge exactly!

sjorge · 2020-09-04T14:55:26Z

SGTM, I assume 0 here will be 1 for those devices with the extra flag set? ~ sjorge

…

On 4 Sep 2020, at 16:50, Koen Kanters ***@***.***> wrote: @sjorge exactly! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Koenkk · 2020-09-04T15:40:41Z

@sjorge that's indeed something that has to be checked!

sjorge · 2020-09-04T15:48:50Z

I have one of the E14 and E27 Innr ones so once this gets updated, I’d can check. ~ sjorge

…

On 4 Sep 2020, at 17:41, Koen Kanters ***@***.***> wrote: @sjorge that's indeed something that has to be checked! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

georgeavd · 2020-09-04T16:00:10Z

Btw we would break dimmer (tthat sends absolute brightness instead of +/-) when setting 0 isnt treated as off.

No, setting brightness 0 will still result in an OFF.

I started to realize what was wrong after reading the comment from @georgeavd (#4237 (comment)). Quoting the sentence which triggered me:

Indeed brightness 0 = OFF, but OFF ≠ brightness 0. But that's not whats happening now.

The behaviour will come down to the following:

Set {"brightness": 0} -> {"state": "OFF", "brightness": 0}

Set {"brightness": 20} -> {"state": "ON", "brightness": 20}

Set {"state": "OFF"} -> {"state": "OFF", "brightness": 240} (where the bulb brightness was 240 before it was turned off)

Set {"state": "ON"} -> {"state": "ON", "brightness": 240} (where the bulb brightness was 240 before it was turned off)

@Koenkk
This is exactly what I meant. And before upgrading to 1.14.3/1.14.4 (I was running on 1.13.1) it was working that way.
Please bring this back. If something else because of sliders in a gui is needed that can be solved in de domotica environment.
E.g. by adding a device with the needed behaviour.

georgeavd · 2020-09-04T16:11:55Z

Please look further as only a lightbulb with some intelligence onboard. There are also dimmer-modules (E.g. ROBB smart 200_004-0). If you send the OFF to this, the last set brightness level is maintained also in de return message.
Thus when sending ON to the dimmer-module it goes back to it's last state.

And please keep in mind that zigbee2MQTT is an interface and should be transparent to all messages and not altering them.
As it is now in version 1.14.x (forcing brightness to 0) is messing up the brightness settings of my dimmer modules.

…oenkk/zigbee2mqtt#2566

Koenkk · 2020-09-05T21:24:46Z

Fixed in the latest dev branch now.

@georgeavd @user1o1 @sjorge please test if the behaviour is as expected now.

@sjorge also test if it fixes #4214

Changes will be available in the latest dev branch in a few hours (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html)

sjorge · 2020-09-06T11:09:34Z

@Koenkk looks good now, old brightness is retained when toggling the st ate.
But is set to 0 when request so via brightness, toggling to one will take the minimal brightness to turn it on being 1 or 2 depending on the bulb 👍

georgeavd · 2020-09-06T21:30:56Z

@Koenkk Thanks for your understanding of my remark. The behaviour looks okay now, including both Node Red and HomeBridge 👍
The only thing one has to take care for (as @sjorge mentioned) is the value for brightness when sending ON if the last known value for brightness = 0.

sjorge · 2020-09-06T21:33:01Z

The only thing one has to take care for (as @sjorge mentioned) is the value for brightness when sending ON if the last known value for brightness = 0. '

I’ve tested this and the value is either 1 or 2, depending on if the bulb turns off at brightness 0 or 1.

Koenkk · 2020-09-07T06:47:18Z

@georgeavd that behaviour is currently correct right? (it turns on at the lowest possible brightness for that bulb as @sjorge mentioned)

georgeavd · 2020-09-08T21:03:48Z

@Koenkk For me that behaviour is correct.

Koenkk · 2020-09-09T07:20:44Z

Ok, I will close this. thanks all!

andreypolyak · 2020-10-06T12:38:19Z

Hi @Koenkk ,
can this change be reverted or at least made configurable?
For me, it doesn't make sense how the brightness can be not zero if the lamp is turned off. If it's not zero then it means that it's turned on.
This feature in 1.15.0 broke some of my Lovelace cards, unfortunately.
Thanks in advance!

Koenkk · 2020-10-06T13:45:51Z

@andreypolyak could you explain more of your use case, maybe we can find an alternative solution. I'm not eager to make this an option because it caused very nasty (hard to solve) side effects.

andreypolyak · 2020-10-06T14:28:41Z

Hi @Koenkk,
as usual, thank you for the very quick response!
I have described my problem as an issue for Custom Button Card here: custom-cards/button-card#378 (maybe they can fix it from their end...)

stale bot added the stale Stale issues label Feb 20, 2020

stale bot removed the stale Stale issues label Feb 27, 2020

Koenkk mentioned this issue May 24, 2020

Philips Hue bulb brightness does not reset when turned off #3602

Closed

Koenkk added a commit to Koenkk/zigbee-herdsman-converters that referenced this issue May 24, 2020

Publish brightness 0 when state of bulb is OFF. Koenkk/zigbee2mqtt#2566

da590c9

user1o1 closed this as completed May 25, 2020

nbarrientos mentioned this issue Jun 11, 2020

Make prometheus light state report robust home-assistant/core#36134

Merged

20 tasks

This was referenced Sep 4, 2020

Brightness of dimmer set to 0% when switching to OFF with Node Red or when device configured in HomeBridge #4237

Closed

brightness stays 0 even when queried with get or updates via reporting #4214

Closed

Koenkk added a commit to Koenkk/zigbee-herdsman-converters that referenced this issue Sep 5, 2020

Keep current brightness when light is turned off (don't force to 0). K…

2201898

…oenkk/zigbee2mqtt#2566

Koenkk closed this as completed Sep 9, 2020

state inconsistency when turning Osram bulb off using brightness parameter #2566

state inconsistency when turning Osram bulb off using brightness parameter #2566

Comments

user1o1 commented Dec 19, 2019

Kryzek commented Dec 21, 2019

user1o1 commented Dec 22, 2019

stale bot commented Feb 20, 2020

user1o1 commented Feb 27, 2020

Koenkk commented Feb 27, 2020

user1o1 commented Feb 28, 2020

Koenkk commented Feb 29, 2020 • edited Loading

user1o1 commented Feb 29, 2020

nobbi1991 commented Apr 2, 2020

user1o1 commented May 23, 2020 • edited Loading

Koenkk commented May 24, 2020 • edited Loading

Gio76 commented May 24, 2020 • edited Loading

user1o1 commented May 25, 2020

Koenkk commented May 25, 2020

Gio76 commented May 25, 2020

Koenkk commented May 25, 2020

Gio76 commented May 26, 2020 • edited Loading

Gio76 commented May 28, 2020

nbarrientos commented Jun 11, 2020

georgeavd commented Sep 2, 2020

user1o1 commented Sep 3, 2020 • edited Loading

georgeavd commented Sep 4, 2020

Pockrandt commented Sep 4, 2020

Koenkk commented Sep 4, 2020

Pockrandt commented Sep 4, 2020

sjorge commented Sep 4, 2020 • edited Loading

Koenkk commented Sep 4, 2020

sjorge commented Sep 4, 2020

Pockrandt commented Sep 4, 2020

sjorge commented Sep 4, 2020 via email

Koenkk commented Sep 4, 2020 • edited Loading

sjorge commented Sep 4, 2020 • edited Loading

Koenkk commented Sep 4, 2020

sjorge commented Sep 4, 2020

Koenkk commented Sep 4, 2020

sjorge commented Sep 4, 2020 via email

Koenkk commented Sep 4, 2020

sjorge commented Sep 4, 2020 via email

georgeavd commented Sep 4, 2020 • edited Loading

georgeavd commented Sep 4, 2020 • edited Loading

Koenkk commented Sep 5, 2020

sjorge commented Sep 6, 2020

georgeavd commented Sep 6, 2020

sjorge commented Sep 6, 2020

Koenkk commented Sep 7, 2020

georgeavd commented Sep 8, 2020

Koenkk commented Sep 9, 2020

andreypolyak commented Oct 6, 2020

Koenkk commented Oct 6, 2020

andreypolyak commented Oct 6, 2020

Koenkk commented Feb 29, 2020 •

edited

Loading

user1o1 commented May 23, 2020 •

edited

Loading

Koenkk commented May 24, 2020 •

edited

Loading

Gio76 commented May 24, 2020 •

edited

Loading

Gio76 commented May 26, 2020 •

edited

Loading

user1o1 commented Sep 3, 2020 •

edited

Loading

sjorge commented Sep 4, 2020 •

edited

Loading

Koenkk commented Sep 4, 2020 •

edited

Loading

sjorge commented Sep 4, 2020 •

edited

Loading

georgeavd commented Sep 4, 2020 •

edited

Loading

georgeavd commented Sep 4, 2020 •

edited

Loading