Inconsistent Dimmer Behavior: Homematic IP vs. Zigbee: ON, OFF and Dimming Value

[Cplant]

I’m having multiple HomematicIP-dimmer devices and since a few days Zigbee dimmer devices (via the OH Zigbee-Binding, all on OH 4.1). Their dimming behavior, however, is completely different from one another, and even rafter reading multiple posts here, here and here, I can’t wrap my head around on how to harmonize their behavior.

I’m now tempted to write a quirky rule as a workaround, but this can’t be it, can it?

Undesired (inconsistent) behavior

Behavior of Homematic IP dimmer (what everyone got used to here at home in the past 5 years):

1. Light off → Alexa “Room xyz to 30%” → Light goes to 30%
2. Light off → Alexa “Room xyz ON” → Light goes to 100%.

Behavior of Zigbee dimmer (new since a couple of days):

1. Light off → Alexa “Room xyz to 30%” → Light does not go on.
2. Light off → Alexa “Room xyz ON” → Light goes to previous state.

So in short completely different behavior. Ideally the Zigbee dimmer behaves like the Homematic dimmer.

My undersanding what happens why in the two undesired Zigbee-cases

1. Light off → Alexa “Room xyz to 30%” → Light does not go on
   The 30% are sent correctly to the item…

2024-01-04 21:15:19.409 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Lichtschalter_Esstisch_Level' received command 30
2024-01-04 21:15:19.481 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Lichtschalter_Esstisch_Level' changed from 0 to 30

and OH sets the switch to ON…

… but only if I turn the switch above OFF and then ON again, the light goes on, but not to 30% but 100%.

2. Light off → Alexa “Room xyz ON” → Light goes to previous state.
   The 100% appear to be correctly sent to the item…

2024-01-04 21:44:05.363 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Lichtschalter_Esstisch_Level' received command ON
2024-01-04 21:44:05.670 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Lichtschalter_Esstisch_Level' changed from 0 to 100

… and the switch is set to ON…

… but the light only goes to the previous value (and not 100%). Turning the switch OFF and ON still turns it on to the previous value (and still not the desired 100%).

There’s so far no (out-of-the-box)-way to switch on the light to x% or ON as consistent to the HomematicIP dimmer…

I’m now tempted to harmonize this Zigbee-dimmer with proxy-items and quirky rules. However, I’m wondering whether this should not be something that’d be fixed in the binding itself?

@matt1, I still remember your quote:

@matt1

I have written bindings for lights from scratch and if it does not work then it is IMHO the fault of the binding not correctly handling ON OFF and PERCENT commands on the channel.

Am I missing something / have configured the item itself wrong?

My configuration

Item configuration:

label: "COLOR_TEMPERATURE_LIGHT: Level Control"
type: Dimmer
category: light
groupNames:
  - esstisch_pendelleuchte
tags:
  - Light
  - Switch

Alexa Metadata:

value: Light.Brightness
config: {}

[Max_G]

IMHO the light should always come on at the set dimmer value.

I have two lights, each switched on|off with a SonOFF push button. The are used in the evening/night, and when switched on come up with the 10% dimmer value they have been set to. I would be disappointed if the they come back at 100% and I have to set this over and over to 10%.

Also, I am planning to have all my CW/CC-adjustable LEDs come on at the value for the respective time of day, as well as dimmer value as set by time of day. So again, coming on 100% would be not what I’d like to see.

[Cplant]

Thanks. I see. So either you go down one path, or another, but it should be consistent.

I changed the Zigbee-behavoir to match the Homematic-behavior with the following workaround-rule. Not the nicest coding, but gets the job done:

if (items.getItem('Lichtschalter_Esstisch_Level').state > '0') {
  // Set to zero to avoid flickering if previous value
  // was e.g. 100% and the new value is only 30%.
  items.getItem('Lichtschalter_Esstisch_Level_Non_Dummy').sendCommand('0');
  items.getItem('Lichtschalter_Esstisch_Level_Non_Dummy').sendCommand('ON');
}
items.getItem('Lichtschalter_Esstisch_Level_Non_Dummy').sendCommand(items.getItem('Lichtschalter_Esstisch_Level').state);

The rule is executed when the light level of the Alexa-item changes and then passes on the value to the (“_Non-Dummy”) item (the one linked to the Zigbee-item).

[rlkoshak (Rich Koshak)]

@Cplant

but it should be consistent.

Unfortunately OH doesn’t always have control over this behavior. It’s often embedded in the device. Sometimes the binding can compensate for the behavior. Sometimes there is a device configuration on the Thing to change the on behavior.

But more often than one wants, the dimmers behave in strange ways, such as always interpreting ON commands to be 100 instead of remembering their last state, or letting you set the level without actually turning them ON.

Note you might be able to work around some of this weirdness by turning off autoupdate. Then the Item(s) won’t actually change state until the device actually reports back that it’s changed state. Then in your Zigbee case the switch wont turn ON when you send command 30, letting you immediately send the ON command without first turning it OFF.

@Cplant

Am I missing something / have configured the item itself wrong?

If it’s the binding’s fault, then there is nothing you can do about it through your config. It requires code changes to the binding.

[matt1 (Skinah)]

You can work around it by storing the last known dimmer value to be assumed when turning on. But this may be an issue if your not using openhab exclusively and are making changes with another way like an app. You could always offer both ways as an option to be picked by the user if the Api does not actually support a better way

[Cplant]

Using proxy-items was actually the way to go. Thanks for all your contributions.