Blue Series 2-1 Dimming Timing Ignored When Dimmer goes from Off to On

its a bug, fixed in beta version 2022-11-18.

Here are the beta fixes since the 2022-11-03 version you are running. Let me know which version you would like and I will send to you via private message

* 2022-11-04(MA) fix 'siren' fast/slow effects (18/19) were backwards
* 2022-11-05(MA) fix selection of multiple individual leds with ledEffectOne (e.g.1357 to select the odd leds and 246 to select the even leds)
* 2022-11-17(MA) more fixes for when user enters decimal (floating) values for an integer parameter
* 2022-11-18(MA) fix startLevelChange with null duration
* 2022-11-24(MA) improvements to quickStartEmulation
* 2022-11-26(MA) fix Config Default not defaulting all parameters
* 2022-11-27(MA) add lines to indicate beta driver

Amazing. Thank you. Much appreciated!

I would expect that 2022-11-18 is as far as I would want to go into beta land? When/which seem to be close to release? I’m a patient guy depending on the amount of time I’d be waiting.

Also confirming that this is indeed a driver bug and not a firmware bug?

Last but not least (lots of questions…) what happens to my currently maintained by HPM driver?

It’s a driver bug. Verified working in 2022-11-18 and newer.

But I guess I forgot to ask: Are you comfortable updating your driver without using HPM? If not, then you can just wait until HPM gets updated. I can ping @EricM_Inovelli to move 2022-11-26 into production (it’s the latest on the beta GitHub site). It’s pretty stable and 11-27 only exists on my computer right now :wink:


I’m completely comfortable updating drivers. I’m just wondering how I rejoin “current” or whatever is hosted in HPM after 2022-11-26 becomes the current release. I was around Hubitat long before HPM and have been around code for a whole lot longer than that :sunglasses:

Also happy to wait 24-48 hours if that’s all it is.


Driver 2022-11-26 is available via HPM now


I made the update via HPM but I see no change in behavior. I do see that the driver has been updated when I check in the driver code itself with the last changelog entry being 2022-11-26 and getDriverDate() returning the expected 2022-11-26 string.

def getDriverDate() { return "2022-11-26" }

…and also…

* 2022-11-03(MA) updates for fw2.05: addeded param 262; added additional LED effects rising,falling,fast/slow, etc.
* 2022-11-04(MA) fix 'siren' fast/slow effects (18/19) were backwards
* 2022-11-05(MA) fix selection of multiple individual leds with ledEffectOne (e.g.1357 to select the odd leds and 246 to select the even leds)
* 2022-11-17(MA) more fixes for when user enters decimal (floating) values for an integer parameter
* 2022-11-18(MA) fix startLevelChange with null duration
* 2022-11-24(MA) improvements to quickStartEmulation
* 2022-11-26(MA) fix Config Default not defaulting all parameters

But looking at the device page I see this:

driverDate : 2022-11-03

I tried a reboot, Save Device, and Save Preferences. None of these had any effect on the original problem nor the driver date value. Something still is amiss but perhaps now it is something else?

Whenever you change or update the driver its always best practice to do a “Configure All” command
(Select All from the dropdown, then Click on the Configure box)


I performed this action and did indeed get the driver date to report correctly.

However the original issue persists. Still scratching my head here as to what’s going on.

OK, I think I’m finally seeing what you’re seeing and I believe this is a firmware bug. It has to do with the current “level” that is stored in the switch (viewable under Current States). If you dim to off (setLevel 0) the stored level goes down to 1. Then if you dim up (setLevel >1) it dims up appropriately.

However, if you just turn it off, the stored level stays at its previous level (45 in your example) even though the switch state is off. Then when you issue a setLevel 45 command, it thinks it’s already at level 45 (even though the switch state is off) and it just turns on with no transition.

I will enter this as a bug in github and see what the firmware developers say.


Now that you mention this — yes — concur. I see the same behavior and it would explain why when setting a non-zero duration the dimmer would appear to “wait” that duration and then turn on instead of dim over that period of time.

Keep me posted. Glad to have caught this and help move these dimmers forward!

Also happy to test a firmware beta fix for this when it becomes available.

Any updates to this? Is a new firmware forthcoming or has this at least been identified as a bug?

Unfortunately the firmware engineer in China does not agree this is a bug :confused:

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 :slight_smile:

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 :man_facepalming:t3: 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!

1 Like

I’ve posted the updated driver.

1 Like

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:

  1. Set the OnLevel attribute in the level control cluster to the value of CurrentLevel
  2. 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.).
  3. 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):

  1. Turn on at CurrentLevel (which will be 1 because that’s how the “Off” processing leaves it).
  2. 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.

1 Like

That is essentially what the firmware engineer’s response was :frowning:

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.

1 Like

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