Zigbee2mqtt: state inconsistency when turning Osram bulb off using brightness parameter

[user1o1]

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 https://github.com/Koenkk/zigbee2mqtt/issues/1321#issuecomment-474050282_

[Kryzek]

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]

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[bot]]

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]

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

[Koenkk]

Could you provide the complete debug logging of this issue?

To enable debug logging set in configuration.yaml:

advanced:
  log_level: debug

[user1o1]

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

[Koenkk]

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]

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]

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]

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]

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]

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

[user1o1]

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

[Koenkk]

@Gio76 please share your debug logging here

[Gio76]

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]

I don't see debug logging.

To enable debug logging set in configuration.yaml:

advanced:
  log_level: debug

[Gio76]

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]

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

[nbarrientos]

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:

https://github.com/home-assistant/core/pull/36134

[georgeavd]

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]

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]

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.

[Koenkk]

I'm also questioning wether brightness 0 should be returned when state OFF is set, this seem to cause nasty issues like #4214

[user1o1]

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.

sorry i actually meant, that if i send brightness = 0, it should become brightness = 0 and state is untouched.
So as i said : "The problem was that zigbee2mqtt automatically translate brightness = 0 to state = off." so i´m with you that zigbee2mqtt should act transparent in this scenario.

[sjorge]

My 2 cents, brightness should not be returns as 0 when the bulb is off but whatever the bulb is set to (reported via attReport for example)

But personal preferences aside... somethings to consider:

• most (all?) bulbs seem to turn on when you send them brightness > 0 at the resulted level
• some turn off when you send them brightness == 0, I remember some not doing that... if forgot which brand
• no (aside old ikea) accept stuff like color or color_temp when off

Ideally z2m should just send what I asked directly to the bulb. But I guess that will introduce differences for different brands that then need to be worked out in a layer above z2m which might not always be doable.

I wonder what would happen if we send brightness 0 followed by off when brightness is requested as 0...

We already some some ordering for other stuff like on + color change in one message.

If I am not mistake I’d you then later send brightness > 0 the bulbs will turn on at that brightness, not sure what happens I’d you send just a on request then though.

[Pockrandt]

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]

Sorry this doesn't make any sense.

What do you refer to with "this"?

[Pockrandt]

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]

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]

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]

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]

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]

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 [e-mail] 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]

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 (https://github.com/Koenkk/zigbee2mqtt/issues/4237#issuecomment-686255712). 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]

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]

@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]

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]

@sjorge exactly!

[sjorge]

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 [e-mail] wrote:


@sjorge exactly!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Koenkk]

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

[sjorge]

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 [e-mail] 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]

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]

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.

[Koenkk]

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]

@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]

@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]

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]

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

[georgeavd]

@Koenkk For me that behaviour is correct.

[Koenkk]

Ok, I will close this. thanks all!

[andreypolyak]

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]

@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]

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