Yes, this is exactly correct. As of right now 1.47 seems like it is going to be the production version. We have had almost all positive reports regarding this version.
Any chance param 51 could be a timing value instead of full on/off?
I’m thinking 250ms might be a good balance between double tap timing and delay after a single tap.
We will work on adding this option in an alternate firmware but it will not make it into the production version.
Can you provide some additional information on what “Smart Bulb” mode does?
I was expecting it to lock the dimmer at 100% output, effectively allowing me to “dim” the dimmer without actually affecting the load (simulate dimming, so that the LED strip shows the dim level).
Am I misinterpreting what the parameter does? If I enable smart bulb mode and press the off button, it still cuts power to the bulb.
@jtronicus - I believe you are correct with output power, but you still need to disable local control to prevent turn off of the load. Smart bulb mode doesn’t automatically turn off the local control.
We actually introduced that setting for users that were having problems with smart bulbs. Some users were having their bulbs turn off or flash.
The feature as you describe it wasn’t intended in this release but more of an accident in a way. Now that it has been brought up we will probably release it soon, but it will likely not make the production release. We are already super behind as we were trying to make the firmware work for most people in most scenarios.
I saw there was a little discussion about the param 51 being adjustable in the switch thread.
Not sure if it was addressed.
How about 51 timing the delay 0=None, x=x00ms.
Is it possible?
I’m running 1.47 on most of my dimmers, but one started acting strange after The upgrade. When the light is off, I have brightness set to 20%. When it’s on, I have brightness set to 100%. Since the upgrade, when I turn the light out, the LED on that dimmer goes to 20% as expected, but about 4 seconds later it goes to 100%… and the light stays off. Is this related to the firmware upgrade, or is my dimmer going bad? Thank you for your help!
I can also confirm that switches that previously had “disable local control” enabled needed to be toggled off then back on as well.
The 1.47 announcement is missing the instructions on how to update - although this was there in 1.45 and earlier.
@WexTX, can you set the new configuration options for “instant on” and “smart bulb mode” to see if that corrects the issue? When a z-wave update introduces new parameters those parameters need to be “initialized”. This can also be done with a factory reset, but setting the parameters is much easier.
@wellsi I’ll add the instructions in the post. Thanks for the heads up.
I was having an issue with 1.47 where my switches would not register the additional button presses in Home Assistant. Toggling the “Instant On” to enabled and back to disabled resolved the issue. I didn’t realize that the parameters needed to be initialized. Thanks for that confirmation!
Will the batch of 10-pack red dimmers due in late August have the 1.47 firmware preinstalled?
I’ve got a firmware update issue … perhaps there is some insight out there …
I’m using Hubitat and @bcopeland’s binary updater … I updated one switch last night as a test, and though it took a few attempts both files went 100% and stuck. Noting that the white LED bar feature is only functional if both files were updated, it seemed like a logical test, so I set it to white, and it worked. I assumed all was good, and tried to revert the LED bar back to blue, however, now the thing is stuck as white, and there doesn’t seem to be a thing I can do about it.
I air-gapped the switch and even reloaded the firmware a couple times, but the led bar is stuck white no matter what I try. When the switch loads, it cycles the colors, and the firmware is loading, it blinks blue, so the electronics appear intact.
For reference, the switch is installed with neutral, and is loadless … not sure its relevant though.
One thing to check is to see if there is any value in the “custom led color” preference. That will take priority over the drop down.
Also, make sure “remote control” is not disabled.
It was the custom LED setting … somehow that got set to 360. I didn’t even realize it was set to non-default value so I never even noticed it. Thanks!
There was an issue in the driver that was causing the custom field to be populated when the LED color was set to white, but I just fixed it and pushed the update up to github.
Whats interesting is that it didn’t happen consistently … I have a few switches left to upgrade, but so far I only encountered the problem about 50% of the time. Sometimes I was able to switch to white, and then back without clearing the field. Either way, I’ll pull down the update, thanks for looking at it.
@EricM_Inovelli Confirming that this update has solved the problems I was having with Hue bulbs. Awesome!
A couple things to note:
- A power cycle via the air gap is recommended after flashing. Until I did that, I was still having problems with power cutting out to my Hue bulbs.
- One of the dimmers I upgraded to 1.47 had a weird problem, where even with smart bulb mode turned on, the lights would flicker consistently (as if the power output were somewhere closer to 50%). I eventually solved it by setting all available parameters, including max level. This was a device I haven’t had any problem with to date.