Unfortunately the firmware engineer in China does not agree this is a bug 
I have put a workaround in the next release of the Hubitat driver to make this work. However this ‘fix’ will only apply to Hubitat users since the real issue is still in the firmware and will still exist on other platforms (HA, ST, etc)
@EricM_Inovelli can you make the 2022-12-12 Hubitat driver available via HPM? I’ve been running it for a couple weeks and it’s been stable
Thanks Mark - we appreciate your help with Hubitat side of things!
Now that the replacements are arriving in the wild, it would be great to have the latest-&-greatest driver too 
Just to double-check once again, please… Do you still recommend doing a “Config - All” on each Blue after installing a driver update via HPM?
Thansk again!
The need to do this depends on what has changed. Typically any time a new parameter is introduced then this will be needed. But there are other situations where it might be needed too.
It’s not always required, but it never hurts. So, yes, I do recommend doing a Config All with any driver OR firmware update
Unbelievable 
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.
Excellent! I look forward to seeing your fix!
Thanks so much for all of your support! I am excited to keep experimenting with these dimmers over the holiday break.
– Richard
bump for @EricM_Inovelli … With replacement Blues now arriving in earnest, would it be possible please to push the 12-12 driver to Hubitat Package Manager?
Thanks very much - I know things are still crazy your way between triaging the Blues, the weather and the holidays. We appreciate everything you’re doing!
I’ve posted the updated driver.
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:
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.
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
OnLevelattribute in the level control cluster to the value ofCurrentLevel- Change
CurrentLevelto 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 theOnOffTransitionTimeattribute in the genericOnOffcluster. We could leave that behavior unchanged.).- Leave the
CurrentLevelset to the minimum value, and switch to off (which complies with the spec becauseOnLevelis 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
CurrentLevelto the appropriate default level (local or remote) from Inovelli’s custom cluster. If that value is 255 then fade to the value ofOnLevelfrom the level control cluster.When processing the “with on/off” variant of any of the
LevelControlcommands, if the on/off state switches to off, then setCurrentLevelto 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.
That is essentially what the firmware engineer’s response was 
The 100 tells it to delay 100ms after issuing the command. The intention was to allow some time for “something other than the hub … like with binding” to be able to also process the 1st command before the second command was issued. That’s the idea anyway. I have no empirical data that says 100ms is the right number. I just took a SWAG at 100ms based on the zigbee response times I typically see. It may need to be bigger or it may not be needed at all. Its somewhat arbitrary at this point.
No, I think you pretty much hit the nail on the head.
Your knowledge and understanding of the details makes you a good candidate for the beta github site IMHO. But that is not my decision to make. Send a message to @EricM_Inovelli to request access.
Upon further research, I think I’ve found a Zigbee reference that supports our position that its not currently giving the desired behavior:
That extra step highlighted in yellow is essentially the workaround I put in the Hubitat driver. But it really should be built in to the firmware of the switch so it works the same across all platforms.
I’m going to add this to the github ticket and see what the firmware engineer says
