I looked at the other thread and saw the image you posted of the events log (the one where there is a report received every 1 second). Can you turn both types of logging on for the device and see what report is being sent every second?
I did this and of course that event every second pattern is no longer seen. I did however notice something else when looking at the event stream and the logs while the log levels were increased.
These were taken from the same device. Using the device page to control it there is nothing in the event history showing my interactions. Does this look correct? I see off() and on() in the logs but not in the event history. There also is a huge gap between lasActivity entries now. Thatās strange as there are no power reports and nothing else in the event history despite the fact that all night long there have been scenes, button presses, etc. Maybe thatās just a logging quirk Iām not sure?
Note that this dimmer does have a neutral (and is configured for it), controls a simple and pure resistive incandescent load, and has no customization of its reporting. It was migrated from my old C-3 hub using the method posted in the Hubitat forums.
After performing this process I noticed that Preferences were not changing despite me making adjustments then clicking save. I would have to adjust a parameter to some āincorrectā setting, save, then adjust it back to the desired setting then click save, click save again, and then finally it would be committed to the device. Iām not sure the cause here or if it is related. But I had to factory default every dimmer to successfully migrate the whole network (which was trivial, but time consuming).
While testing the v1.52 beta firmware, I notice that tapping the config button 2x (to clear a notification) causes the switch to send a āButton 2 Heldā event. This mimics the same as tapping the Down paddle 2x.
I donāt recall it doing that before. Is that the expected behavior? I donāt think the config button 2x should send the same event as a down button 2x event. I believe it should send no events or possibly a ābutton 7 heldā event. But not a ābutton 2 heldā (same as down click 2x). This is a problem when double-click scenes are defined for the down button and they get activated when clearing notifications with a config-click 2x
I have all my LWW31-SN running v1.52 and I donāt remember if it did this before or not. Iām not sure if its always been this way or if changed in one of these beta updates. Is this the expected behavior or a bug?
fwiw - all my LZW31-SNs are at 1.48 still, even with debug enabled I see no events at all when clicking the config button 2x (and no physical effect either).
The double-tap of config button scene is new to Beta 1.49. However, for me it is correctly registering as a double-tap of config button (scene 003), and not as a button 2 hold event.
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 
- Retail versions of the dimmer are on firmware 1.48. The feature you are referencing is part of the beta firmware. Have you already updated to the latest beta? If you did update firmware, how did you do it? If you used the Zwave PC controller software, you can always change the config parameters through that.
- The current version of the HA zwavejs integration does not support the changing of config parameters (I believe the feature is coming soon though). Currently, the only way to change config parameters is to use websockets (which I am not too familiar with) or with something like zwavejs2mqtt
- The delay is not adjustable via the config button at this time.
- A config file with the latest beta features is currently not available. I think there are a few people working on it though.
1 Like
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?
1 Like
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.
1 Like
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.
1 Like
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?