No worries. I think the flashing of Target1 may have bricked that one. I ordered 4 more switches, 1 to replace, and a few backups in case another one dies for some reason.
Dang, that is not good. Did you use the “old school” binary driver method to do the flashing or the Hubitat tool? I have not had good luck with the tool so I usually use the driver.
No worries. It happens. I was using the newer built in firmware updater app in Hubitat.
I was able to update all of the target 0’s on my 13 dimmers. But I am having no luck updating target 1. I’ll give the old school method a try and see if that works. I redownloaded the firmware just in case and it keeps timing out while trying to flash it.
Lets see how the old school method works.
So gave this a try. Night and day difference. The flashing was much faster and actually didn’t fail.
I’ve been fighting trying to update the firmware with the built in app for a while and then I finally tried the old school method and it works without fail.
Sometimes its just something so simple.
1 Like
So far I’ve updated only two dimmers to v1.55. These are the only two dimmers that have smart bulb loads at the moment. Both function as expected when Parameter 52 == 2.
I will continue testing but so far all is good!
1 Like
I’m starting to see some odd behaviour with dimmers that have been updated to v1.55(beta)
Initial testing all looks good. However, after running with it for about a week I’ve had a few occurrences where the on/off state reported by the dimmer does not match the actual state of the load.
In other words, it seems to work fine for several days and then at some point I notice the lights are off but the dimmer is still reporting to the hub that it is on. The LED status bar is also indicating ‘on’ status, but the load is off. Its also reporting a low wattage reading to the hub (probably the power of the dimmer internals and LED status bar). It seems like the load output circuit gets out of sync with what on/off state the MCU thinks its in. I can use either the physical button or zwave command to toggle off/on to get things back in sync again.
This has happened more than once, but I haven’t yet figured out what makes it happen or how to duplicate it reliably. It seems to just happen after several days of working normally. I’ll keep monitoring and paying closer attention to any pattern. I’m curious if anyone else running 1.55(beta) has seen something similar.
you posted 1.56. Can you tell us what changed 
That is strange. I am also wondering if this has been observed by anyone else.
Are these in a 3-way configuration or single pole?
@stu1811 I just posted about the 1.56 update. Like @Eric_Inovelli mentioned, it is to optimize aux 3-way control.
1 Like
3-way toggle (dumb slave switch) with Neutral.
Just happened again … same switch (my Hall Lights). Configured with Neutral in a 3-way Toggle and SBM Disabled. (Its actually a 6-way)
I’ll update it to v1.56 and see if it continues…
Updated to v1.56 and 7 days later it happened again. Same dimmer (Hall Lights). Running v1.56 on firmware0 and v1.44 on firmware1.
Not sure what else to check or do. I feel like this is a possible bug in the new Smart Bulb Mode code. This switch has SBM disabled, but it clearly has to do with improper control of the internal relay. (switch logic thinks its on, but the relay is off)
1 Like
I’m running into the same issue, with version 1.56 /1.44 with the Smart aux switch not able to turn lights on. One thing I tried is to change it to toggle and then try to turn on the switch I see the led go full blue but doesn’t turn on the light.
Got another dimmer with this same problem (Kitchen Lights). Its also a 3-way toggle with neutral. But, this one is running firmware0=1.50 firmware1=1.41
Can someone please explain parameter 52 for me please I kinda understand it but not fully… What does each option do
Option 1 forces the load terminal to be full-on or full-off with no dimming of the load. The switch logic and LED bars still maintain a dimming value (setLevel) which is used in automations and control of Smart Bulbs.
Option 2 is similar except the Load terminal is always on…even when the switch is logically off. This is for Smart Bulbs that need power all the time, even when the light is off. The switch logical still maintains bulb on/off status as well as dimming levels, but those are only use for sending commands to the bulb and do not control the voltage or on/off status of the load terminal
1 Like
Hi there, I’m wondering if you had a chance to see if v1.57 fixes this issue for you.
1 Like
Hi Eric,
Yes, it fixed all my issues, I just had some issues going from 1.48 to 1.57. Had to upgrade to a 1.52/1.55 first, then to 1.57.
Thank you for all your hard work.
Mike
1 Like
That should not be necessary. Are you flashing both files (the .otz and the .bin)? All the Dimmers have two files and their version numbers aren’t in sync (unfortunately). The “v1.57” release has two files you need to flash. There is a 1.57.otz file that flashes to Target0 and a 1.44.bin file that flashes to Target1.
Also, many of us have noticed that some new parameters need to be initialized before things work right. Sometimes you have to toggle the values before they stick the first time after a new firmware update. Even if it appears to have the correct value, we needed to change it to something else then change it back.
1 Like
Yep, thanks for the info @mamber. We have noticed that when flashing from a lower version (specifically 1.48) to 1.57 some of the button presses stop working (like a pressing the config button to get into inclusion / exclusion mode). This can be fixed by a factory reset by holding the config button for > 20 seconds. Or, as @mamber mentioned, I believe changing configuration parameter 50 & 51 to something else and then changing them to their desired value will fix this issue without a factory reset, but I haven’t been able to test it yet.