Thanks for making my favorite dimmer! I’m thoroughly enjoying the Blue Series and believe that this is the best dimmer produced for the home that I have experienced. I continue to purchase more
I am experiencing what I am beginning to suspect is a Hubitat driver bug. Red Series dimmers do not experience this and Blue Series dimmers do this 100% of the time. Starting with a light that is off and turning it on remotely (via ZigBee from the device page, a scene, or otherwise), the dimmer will snap to its target level instead of dim. If instead I send an “on” instruction I get the default fade time as set in device preferences. No matter how I try to send an intensity with duration, the duration is ignored if the dimmer starts at 0% aka Off.
I suspect that this is a driver bug and not a firmware bug? At least I am hoping for that because the fix is probably quicker
Any thoughts?
— Richard
edit: I also tried this from the device page and can confirm that I still do not see a fade. If I set the dimmer to 1% and then send the same the fade is as smooth as ever.
It seems to be working correctly for me with Hubitat driver dated 2022-11-18 and firmware version 2.08
What driver date and firmware version are you running?
There is a difference between “Dimming” rate and “Ramp” rate. Your title says dimming, but you are mentioning on/off operations that use ramping. Make sure you are setting the ramp rate, not the dimming rate.
The Blue Series has several enhancements and many more parameters than the Red Series. In particular, the Blue has separate settings for “Local” ramping and “Remote” ramping whereas the Red has just one setting for both. It also has separate settings for Ramp-Off-to-On and Ramp-On-to-Off. Make sure you are setting the correct parameters for Remote on-to-off and Remote off-to-on
Thanks for writing back! I appreciate your comments. I hope I can get this working correctly.
It seems then that I might have an out of date driver. I use HPM to manage drivers on Hubitat and the latest version that I have is dated 2022-11-03. Perhaps that is my issue? fwDate and fwVersion are as yours.
I am and I have fiddled with those preferences. However that should not matter if a scene has a non-zero duration or if in the device page I specifically set a duration that’s non-zero.
I’ve adjusted all of this. No problem at all if I tap the switch itself or if I send a remote “on” command. I see a fade. The problems come when I send a level with a non-zero duration. No fade. Just a snap to the value.
The latest open/GA/non-beta version of the Blue driver for Hubitat is 2022-11-05, but I don’t think it’s massively different from the previous driver (which was 11-03, I think).
By command what I actually mean in practice is setting a level and a duration on the device page and then clicking setLevel. See the screenshot in my original post. If I click that with the switch on and the current level set to anything but 0, I get a fade. If I click that with the switch off, I get a jump.
Just did another test. Now I found something quite strange. If I use the device page to setLevel and I give an even longer duration (10 seconds), the dimmer seems to “wait” the 10 seconds and then set the value directly to the target level. Now that seems positively buggy to me.
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
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
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
Also happy to wait 24-48 hours if that’s all it is.
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)
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.
I spend all my time running the latest beta version and I loose track of the ‘released’ version 
