Firmware v1.55 (Beta) | LZW31-SN | Dimmer - Red Series (Gen 2)

I’m having some issues with my 3-way with this update, on a non-smart bulb. It seems like my AUX switch turns on and off the dimmer, I hear a click and the LED dims and it says “off” in Hubitat, but the load does not turn on and off unless I use the master switch. I’ve tried 3-way toggle and 3-way momentary. I had to have it on 3-way momentary before this update.

We don’t say “disable the relay” anymore; it is now “disable local control”. SBM just ensures that the load always has 100% power, so if you turn the switch device itself on/off it will just affect the LED and switch state, but it will still be outputting 100% power to the smart bulbs, which you would have to control using scenes. Same for dimming, it will change the level of the LED but will still output 100% power to the load.

We definitely do say it still. @Eric_Inovelli has a sweater that says it. It will be here forever!

3 Likes

And THAT . . . . is unfortunate :rofl: :rofl: :rofl:

2 Likes

Does the LED bar operate as normal when controlled by the aux switch?

When the switch is in 3-way toggle mode, the aux switch turns the master switch on and off, but it does not change the load. I can hear the master switch clicking, the LED turns on and off and the state is updated in the hub, but the load stays off.

When the switch is in 3-way momentary mode, the aux switch can turn the load off but not on. When it turns the load off, the LED on the dimmer goes to its off setting and the state is reflected on the hub, but I do not hear clicking. Once turned off with the aux switch, the aux switch isn’t able to turn the light on.

It is a GE 46200 and I know it is not on the tested list but it worked before 1.55 when set under 3-way momentary.

One step better than that actually. I verified this by increasing parameter 5 by 10 (IE: 40 → 50) and then setting the current level to 1. If the value is accepted / being used then the light will get brighter, despite setting the level to 1. I confirmed that this works up until at least 90 on v1.55 but didn’t test beyond that.

I’ve lost track of how many different times I’ve flash back and forth and tried different parameters at this point, but I think I’ve identified what leads to the issue.

Everything behaves exactly as expected until I configured the ‘master’ dimmer as being a three way with a dumb switch. With it configured as a three way I must increase the minimum dimming level by quite a bit.

Looking at the change log, this sounds very much like what weas supposed to have been resolved in v1.51:

Fixed: Issue where the same value of parameter 5 (Minimum Level) appears inconsistently when both parameters 21 (Power Type =1 - Neutral) and 22 (Switch Type = 1 – 3-Way) are set to 1.

Any thoughts @EricM_Inovelli? Please let me know if there is any further testing I can do to help get this issue resolved in the firmware.

HI @EricM_Inovelli

Any idea how I can revive this? or is it dead?

So far my dimmers (S2) stopped reporting back to the hub after the update (scene control, current states, logging, etc) - nothing would resolve this other than a factory reset. I had one without security enabled that worked fine after resetting parameter 50 and 51.

All seems ok now but Hubitat still doesn’t receive a button 7 held (or anything) with a double-tap of the config button. Any ideas?

I’ve seen this happen if association group 01 lost device 01. Thats the lifeline group that reports events back to the hub. Once I added it back things started working. Check that next time.

1 Like

I can’t think of anything if you can’t get it into a state where you can do an exclusion or a factory reset.

@Mr_B Unfortunately the extra scenes for the config button have been walked back as there was not currently enough room to keep them.

1 Like

There seems to be something off about the 3 way settings in this version. I am working with the engineer on it.

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.

@EricM_Inovelli I see :eyes: you posted 1.56. Can you tell us what changed :grinning: