My fan has been turning off after about 3 hours and I’ve tried about everything. Most recently I tried setting parameter 17 to 100 but it keeps reverting back to 0. Not sure what to do at this point if this is the temporary fix.
Not really. What’s reported causes the state of endpoint 1 to go out of sync with the device when endpoint 2 is operated. It shouldn’t cause anything to turn off unless that’s triggering an automation somehow. Node certainly isn’t sending a command 2 hours later based on a prior event.
The notes above about the light turning on with the fan seem related, though.
It’s great these bugs get reported here but they really need to be opened on the the node-zwave-js project on GitHub if we’re potentially to blame. We can help work through whether this fan issue is originating with the device or HA but we need more detailed logs. A Silly level log should report in the zwavejs1.log file whether a message came
in unsolicited (device) or this was due to a command going out.
Someone should open an issue. No one can begin to fix this until we understand if it’s coming from the integration, node, or the device. As it stands now this hasn’t been reported and isn’t being investigated, at least not by us at the node project. We could have fixed the fan/light status issue weeks ago but it was first reported tonight.
1 Like
Completely understand and thank you for perusing @blhoward2.
I’ll get an issue logged on GH right now, and ensure future concerns are brought there as well as I can.
Thanks for your support!
If someone can beat me to logs, here is the issue:
Al is already on it and commented that he will wait for logs.
@Eric_Inovelli We’ve confirmed with a brand new switch, never before used, that the switch is rebooting itself right at two hours and change as if it had been air gapped. We’re still looking into this but any ideas on your end? Or why this would only happen with zwave-js? Have you seen reports with ozw or other platforms?
Tagging @EricM_Inovelli more importantly! Saw this in a ticket as well so we will make sure it gets addressed.
Too many people with the same name. 
Hmmm… yeah that is interesting. I think I’ve seen this in the community as well with HA users lol, I thought this was in our PM, my bad. Would be awesome to figure this one out!
Eric M will actually be in Michigan starting this weekend, so maybe we can try to figure this one out together. He’s traveling today and tomorrow, so I’m not sure if he’ll be able to look at this right away.
Do you have a Zniffer at all that you can see what commands are being sent (if any)?
The person testing it does not, unfortunately. He’s doing it again with our max logging at the controller.
I’ll give some more details, when the switch looked like it was rebooting, what I saw was the LEDs both going green like at the end of inclusion.
Since I wasn’t fully paying attention that’s all I saw, but it reminded me also of when I first powered the switch up fresh from the box.
I am on Home Assistant with zwavejs2mqtt and so far I am NOT experiencing this issue.
Is everyone on the beta 1.36 firmware, or are some of you on earlier versions?
Mine is reporting v1.34
The one @firstof9 tested was new out of the box so presumably didn’t ship with beta firmware.
1 Like
Confirming the LEDs go RED BLUE GREEN then the switch toggles back on.
@EricM_Inovelli Update: We’re still confirming this but believe this may be a bug in the firmware relating to the Supervision CC. OZW hasn’t implemented that CC but we have which is why users experience the bug when switching. The reboot happens with no commands having been sent. Even if it’s not causing this problem something seems off with Supervision based on the log file we’re seeing.
We’re going to disable Supervision for this device on our end for @firstof9 and see if this bug goes away to confirm.
See @AlCalzone’s analysis of the log file here: Inovelli LZW36 - Light turning off reliably after ~2 hr 10 min · Issue #2159 · zwave-js/node-zwave-js · GitHub
/cc @Eric_Inovelli
2 Likes
Awesome, keep us posted!
@Eric_Inovelli @EricM_Inovelli I was able to recreate the issue on my end, and captured the data with my packet sniffer if anyone needs the zniffer files.
It does look to me like @blhoward2 is correct. The fan responds to the SUPERVISION_GET command with the wrong Session ID (it sends the SUCCESS response with the wrong ID, then sends a WORKING response with the correct ID). ~2 hrs and 10 minutes later it appears that the device reboots
2 Likes
So for someone like myself who doesn’t understand what this means, can you help me understand why this only affects Home Assistant (that I know of)?
Edit: also, thanks @jtronicus for confirming this for us 
This is because Home Assistant uses the zwave-js driver as the recommended method for utilizing zwave devices now. The zwave-js driver, unlike OpenZwave, has support for the Supervision Command Class.
I’m sure @blhoward2 can give you much better details, but that’s the basics.
1 Like