I’m trying to further understand this issue, and perhaps why the firmware engineer doesn’t think it’s a bug, so that we can find a solution for people on other hubs than hubitat.
It almost sounds like the situation is that the current firmware faithfully implements the ZigBee specification, which specifies unintuitive/undesired behavior.
Here are two snippets from the ZigBee Cluster Library, version 8:
Effect of On/Off commands on the CurrentLevel attribute
This describes the desired behavior in response to a simple “turn on” command: fading up from zero to the previous level, using the default or specified transition time. It sounds like this works as expected, but only when the “on/off” commands are used, not the level set commands.
State Change Table for Lighting
This describes how to respond to the “set level” commands from various starting states. The relevant line here says that when getting a “move with on/off to level MID over 2 sec” command, the device “turns on and output level adjusts to or stays at half”. There’s some ambiguity there, because the starting level was “any”, but the way I interpret it is “adjust from currentLevel to MID smoothly over 2 seconds”, where currentLevel is the stored value, which in this case is much higher than the minimum level. I don’t understand why anyone would want this, but it is what the spec appears to say.
It looks like @mamber’s workaround is to first set the level to 1, so that currentLevel is close to the actual starting brightness (off), not the last used level from when it was previously on. (side note, what’s the 100 for in zigbee.setLevel(1,0,100)?). This seems like it would get the desired behavior, but I don’t think other hubs (I’m especially thinking of Home Assistant) will like this idea of inserting additional commands. And it doesn’t help if something other than the hub is sending the command, like with binding. I’d really like to find a way to get the device to work as expected when receiving standard ZigBee commands.
After staring closely at the spec for entirely too long, I think I’ve found a change we could make which would get us to the desired behavior, and still comply with the ZigBee spec. The ZigBee spec doesn’t include enough attributes to do this using the generic clusters, but we can leverage the fact that Inovelli is using its own custom fields in its custom cluster (default_level_local and default_level_remote) and ignoring the OnLevel attribute in the LevelControl cluster to get the desired behavior. Basically, in order to do this, when off, we need a place to store the previous level which is not CurrentLevel. We can use OnLevel for that.
I’d specify it as follows:
When processing an Off command (either received from ZigBee, the paddle, or a 3-way), do the following:
- Set the
OnLevel attribute in the level control cluster to the value of CurrentLevel
- Change
CurrentLevel to the minimum level allowed for the device over the specified time period (which I think currently comes from Inovelli’s custom cluster, rather than from the OnOffTransitionTime attribute in the generic OnOff cluster. We could leave that behavior unchanged.).
- Leave the
CurrentLevel set to the minimum value, and switch to off (which complies with the spec because OnLevel is defined).
When processing an On command (either received from ZigBee, the paddle, or a 3-way), do the following if currently off (do nothing if currently on):
- Turn on at
CurrentLevel (which will be 1 because that’s how the “Off” processing leaves it).
- Smoothly fade from
CurrentLevel to the appropriate default level (local or remote) from Inovelli’s custom cluster. If that value is 255 then fade to the value of OnLevel from the level control cluster.
When processing the “with on/off” variant of any of the LevelControl commands, if the on/off state switches to off, then set CurrentLevel to the minimum level.
It’s entirely possible I’ve made a mistake or overlooked something, but I think this would work. I have no idea how you manage access to your Github issue tracker, or communication with the firmware engineers, but I’d be open to communicating with them directly. I’ve got a pretty good understanding of the low-level details of both ZigBee and Z-Wave.
I hope that your engineer does indeed find this to be a bug one day! It’s quite frustrating when you experience it especially with an entire room of LED fixtures that just “snap on to 100%” in the morning instead of slowly fade up.
