Have a switch, in SmartBulb Mode, with 2 Philips Hue bulbs, using zigbee2MQTT and a Conbee 2 USB Gateway, and I’ve created a Group and Bindings (onOff and levelCtrl) between the Switch and the two bulbs. The bulbs react to changes at the switch, local and remote.
The problem I experience with this configuration is that when I turn the switch ON, locally or remotely, the switch will show the correctly configured state (based on defaultLevelLocal and defaultLevelRemote of 254 for full brightness) but the zigbee bulbs will instead turn back on at the previous brightness level. This is a considerable problem because if I previously dimmed the switch, and consequently the bulbs, to 20% and eventually turned the switch OFF (locally or remotely), turning it back ON (locally or remotely) will show a full LED bar at the switch level (but the bulbs turn back on to 20%). I then have to hold the paddle to bring the brightness of the bulbs back up to 100% (or force the brightness from the hub) to light up the room.
Test Sequence:
1. Bind a Philips Hue lightbulb (onOff and levelCtrl) to the switch
2. Turn the switch and light ON to 100%
3. Dim the switch to 20%
4. Turn OFF the switch
5. Turn the switch back ON
Expected Result:
1. The lightbulb should turn on the the defaultLevel set on the switch when the Switch is turned ON
Actual Result:
1. The lightbulb will react to the ON change by going to it's last known brightness, which is 20%
2. The switch shows the full LED bar indicating it's turned on 100%
I guess I could create events to capture the up_single action and force the brightness of the bulbs but I’m reaching out first.
Can this be fixed at the software-level in zigbee2MQTT? Is this behaving as expected? Is this a technology limitation (with Philips Hue only perhaps)?
The power_on_behavior is for, I believe, when the actual power to bulb is cut and then restored. However, in this case, we’re using smart bulb mode to keep power on the bulbs at all times so I don’t believe this setting should be applicable - could be wrong on this.
I found more more information on the situation - when turning the switch OFF, because it’s bound to the LightBulb, it will turn the Hue off with a transition that matches the rampRateOnToOff which ends up putting the LightBulb in an OFF state but at a 1% brightness as the brightness ramps down. When turning the switch back ON, it will send an ON to the group which ends up turning the LightBulb to an ON state, but because the LightBulb doesn’t have a default ON level, unlike the Swich, it just turns on to the last known brightness: 1% …
I’m still learning but it seems to me that a remote or local OffToOn at the switch level should tell the binding group to Move to Level with OnOff (0x04) and use the remote or local rampRateOnToOff transition instead of just sending an On.
zigbee2MQTT has implemented something to address this specific problem:
// https://github.com/Koenkk/zigbee2mqtt/issues/2850#issuecomment-580365633
// We need to remember the state before turning the device off as we need to restore
// it once we turn it on again.
// We cannot rely on the meta.state as when reporting is enabled the bulb will reports
// it brightness while decreasing the brightness.
The same fix obviously doesn’t apply but the Switch doesn’t need to remember the old brightness, it just needs to force it’s defaultLevel and rampRate to the bindings when it changed States.
I’ve been trying to script to fix this but it’s definitely not covering all the scenarios. For Local, I can cover when pressing the paddle with up_single action but that doesn’t address sending a Remote ON state to the switch and I have various use-cases for that, namely through Google Home and Homebridge. It’s actually not even something that can be fixed at the software level because the bindings are all pure hardware zigbee that don’t even require a hub.
I used to have Inovelli Red’s in SmartBulb mode for all my Hue’s and I had to script all the different events, and it worked, but wouldn’t dim in real-time, which is what I was hoping to acheive with the Blue’s. It works, but this problem is definitely worse than not being able to dim in real-time at the switch. I was hoping for a better local user-experience with the Blue but I might as well unbind the group and go back to the the traditional non-Zigbee SmartBulb Mode of the Red’s at this point.
With bindingOffToOnSyncLevel enabled, the switch now correctly turns on the bound zigbee lights to the same brightness as the switch instead of ~1% when turned on locally. The problem is now that because defaultLevelRemote completely ignores its setting and consistently defaults to the last known level when it was turned off even though the value is set to any other value than 255, I still do not get the expected results when the switch is turned on from the hub unless it was at the correct brightness when it was turned off last.
Nice, I found a fix for the defaultLevelRemote problem in zigbee2mtqq (see the linked thread above). I’ll be testing this and the new parameter over the next few days to see if everything behaves.
Thank you so much for the new parameter, it was absolutely necessary!
Yeah, unfortunately this issue was because z2m was sending move to level with on/off instead of just on/off. So z2m was telling it to go to a specific level.