I don’t recognize that screenshot. Im using Hubitat. If you are using SmartThings or some other hub then maybe its a Hubitat driver issue?
Also, you noted this changed in Beta 1.49. Are you running Beta 1.52 now? I wonder if its changed again between 1.49 and 1.52 
The screenshot is from a zwave packet sniffer (zniffer).
The change was made in beta 1.49, but the screenshot is from a dimmer on beta 1.52.
Thanks for that info. I was able to figure out how to “fix” this in Hubitat. I now have it so Config Button 1x sends a “Button 7 Pushed” event and Config Button 2x send a “Button 7 Held” event. This makes it a unique event and doesn’t trigger my Button 2 Held events when I clear notifications with a Config double-tap 
Its a small edit to the Device Drivers code if anybody is interested. @EricM_Inovelli maybe something to consider including in your next driver update? 
Starting at line 1241, change this:
default: buttonEvent(cmd.keyAttributes - 1, (cmd.sceneNumber == 2? "pushed" : "held"), "physical") break
To this:
default: if (cmd.sceneNumber == 3) buttonEvent(7, "held", "physical") else buttonEvent(cmd.keyAttributes - 1, (cmd.sceneNumber == 2? "pushed" : "held"), "physical") break
Now I’m seeing some log entries that are eyebrow raising. I had another device forgotten type of scene failure today. It happened to the same device twice consecutively. In the log I see entries such as:
Unhandled: SwitchMultilevelSet(dimmingDuration:null, value:null)
Does this reveal some of what’s going on here? Only the Inovelli devices which have experienced the “forgotten during scenes” failure entered this to the log. The other devices are not as specific though I am monitoring those in the same manner (both logs enabled).
I just got my LZW31-SN today. I’m running zwavejs in Home Assistant so I don’t yet have parameter 50 exposed in the UI to update. Is there a config button pattern I can use to adjust the delay?
Otherwise loving the switch so far. Just want to bump that delay down a bit 
I updated using zwavejs2mqtt. That addon has a websocket interface that’s compatible with the beta integration in HA 2021.2.1. Due to the PR that’s currently awaiting merge I was hoping I could edit those parameters early. But I can just as easily wait for the PR. Both zwavejs addons are updating to new releases very quickly.
Currently loving the switch.
Installed this and now the switch is reporting 1.6W when on full brightness and 0W when off. I need to find an incandescent to confirm what’s up but this seems really odd… There is definitely ~40W connected.
Any thoughts? Did a delete/reset/join for good measure but no change (except for node id of course).
Yep, I need to update the driver / device handler for the new scenes.
@rpulivella Those are really strange log entries. It seems like you aren’t getting any reports at all. I’m curious, if you use the built in Hubitat drivers does it show reports coming in or are you having similar issues?
@kreene1987 I know this is probably a silly question, but you are using a neutral config vs a non-neutral correct?
No silly questions when troubleshooting!
Yes neutral is selected and was unselected/reselected for good measure without change:
Both drivers experience the same lack of events. There’s not even anything in the main Hubitat log stream but even more bizarre? Many of the lights still function and respond to scenes, rules, etc. This is super strange stuff. I’ve tried it all at this point.
What I can say with some confidence now is that the problem seems to occur most often with devices migrated from the old Hub. I followed Bruce’s exact instructions. I ran into zero issues at first except this (now lingering) scenes problem.
All Inovelli devices that stopped reporting (but somehow still quietly respond to the Hub commands) are dimmers running 1.52. That much is known. I have two RGBGenie micro dimmers that also suffered from the forgotten by scene problem but those now reliably respond (and log) after a few clicks of the refresh button on their device page. This trick does not fix the issue for Inovelli dimmers. I have one dimmer running older firmware which was migrated from the old Hub. While it’s never been forgotten by a scene it too is showing some strange gaps in its event stream and log though it’s nothing like what I’m seeing with the migrated 1.52 devices. Now all of that said I did not perform the upgrade to 1.52 until migration was complete and I performed that upgrade (of both targets) using the Hubitat built in firmware update tool. This is not the older method of switching device drivers but a true “firmware update” app built into the latest version of Hubitat.
I had different problems than you when I updated to 1.52 using the the Hubitat built in firmware updater tool. For me, the current state information wasn’t updating, even though the dimmers would respond to hub commands. It only happened on dimmers I had paired with S2 security, I had a couple with no security and they worked properly after updating with the Hubitat firmware tool. I also tried the older method you described (replacing the device driver) but couldn’t get that to work, kept getting a ‘sleepy device’ message. So I ended up excluding them from Hubitat and updated with a Z-stick. No problems after that, everything worked properly. I don’t really understand how the Hubitat built in firmware updater could cause this, but it might be worth trying to reflash one of yours this way to see if it solves your problem.
Same issue with mine after using the hubitat firmware updater app (Also tried the older “driver” updater which gave me the same “wake sleepy device” message indefinitely) - No proper events making it through to hubitat, but they did respond to hubitat commands. Z-Stick flashing method (Target 0 .otz & Target 1 .bin) resolved it. The hubitat firmware updater app also failed entirely or went extremely slow (like 24+ hours) for some switches, which ultimately were re-flashed using the z-stick in under 10 minutes.
This is shockingly familiar to problems I am experiencing. I am going to perform a re-flash as soon as I am able to test if this resolves my issue.
Also I can confirm that the only ZWave devices suffering right now are S2 connected and were updated using the Hubitat tool.
Update: @Eric_Inovelli @EricM_Inovelli I flashed one dimmer with v1.52 using the PC Commander/ZStick method. I now have a completely non-functioning dimmer at least as far as network control is concerned. It seems to be receiving network traffic as there are ZWave log entries from it and I can ZWave Repair it successfully every time. ZWave Mesh traffic is significantly impacted after this latest turn of events. Furthermore this dimmer does not turn on or off, it does not respond to on() or off() much less setLevel(). Worst of all I cannot re-flash any target or version as neither the Hubitat tool nor the PC Commander application can initiate OTA. I get “OTA command failed” even just trying to get its version number.
So I went from strange lacks of log entries to a mostly bricked dimmer. Not a good night here.
Did you do this as a secondary controller on your Hubitat network or was it a totally separate network?
The first flash was directly from the Hubitat app so that was Hubitat C-7 in the role of primary and the dimmer a participant of that network. In nearly all previous firmware flashes from my old C-3 hub I did it this way too with zero issue other than the occasional reboot/retry (using Brian’s Firmware Flashing Driver).
This time around I flashed from my C-7 Hub to the dimmer on my existing network. According to the built-in app the flashes went perfectly normally. But the side effect was that the dimmers no longer were sending events and a manual refresh had to be issued to get the event stream and log to begin showing entries. This was true even if a scene or rule sent a device an instruction. No log entry. Nothing in the even steam (Device Page “Events” tab).
The latest flash (which created the partially bricked dimmer) was performed from C-7 to device within the existing network. The 700 Series stick was a secondary controller on that network. Again the PC Controller App showed no errors and reported a successfully completed update of both targets. This was a re-flash of 1.52. Target 0 went first with no issue. Target 1 also no issue. After the expected reboot that’s when the dimmer ceased to respond to commands.
Removing the dimmer from the C-7 network and directly connecting to the stick makes no difference. I cannot flash this device.
I also have to add that flashing firmware should not require exclusion from a network at it then would destroy all the scenes/groups/rules that include that device and require a manual rebuild from notes. That would be a month long process for me and I only have 20 devices in a small apartment. Past firmware flashes on your dimmers have not had any issues at all. There is something wrong with some combination of my migration from C-3 to C-7, use of the Hubitat Built-In Firmware Updater App, S2 security, and perhaps v1.52 itself.
Will the LZW30-SN be getting the adjustable delay speed at some point as well?
+1 on both of @mamber’s use cases.
I need the 1.48/1.47 smart bulb behavior, and gaining minimum level 99 would be great as well since the ramp up (even at 0) occasionally upsets Philips Hue bulbs. I should have used LZW30-SN switches, but I really wanted that big LED bar.
I have an LZW31-SN dimmer runing 1.52, at it seems Local Control Disabled is no longer honored when configured on Hubitat? I usually disable it right on the device, but I also tried the child device method and see the same.
Is this expected?
I just updated my LZW31-SN (red) to the latest beta firmware. It now shows Parameter 51 in ZWAVE2MQTT which is great. However, regardless of the setting, the switch is behaving as “instant on”, not allowing for double-tap scene selection.
I presume this is due to parameter 50 having a setting of ZERO (0 ms delay).
Using ZWave2MQTT, I don’t see a configuration for parameter 50, presumably because OpenZWave 1.6.974 does not have an updated config for this firmware?
Is there a way to set this parameter using Home Assistant / ZWave2MQTT? Or maybe the SiliconLabs PC Controller?
