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?
The one @firstof9 tested was new out of the box so presumably didn’t ship with beta firmware.
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
@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
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.
It potentially affects any hub that sends COMMAND_CLASS_SUPERVISION commands.
My understanding is that COMMAND_CLASS_SUPERVISION is a way to send a command that requires the receiving devices to respond with a status (success/failure). Without it, the device will acknowledge that a command was received (ACK), but will not acknowledge wither or not is was able to execute the command successfully.
Without COMMAND_CLASS_SUPERVISION, the device would need to send reports in order for the hub to determine if the status actually changed
@Eric_Inovelli @EricM_Inovelli. Right. So it doesn’t affect only HA as others use node-zwave-js, you just haven’t seen reports as those aren’t as popular. Any hub using supervision would experience this. OZW doesn’t support it so nothing running on OZW triggers the bug.
Hubitat also supports it so this is likely happening there too. Though those drivers have to be changed to use Supervision I believe (versus we do it across the platform) so it’s possible no one has done that yet.
Also, @firstof9 confirmed that disabling Supervision for this device seems to fix it. Logs of the run with it disabled are available at the link I posted earlier.
I need to talk to @alcalzone but I assume we’ll disable this for now for all users unless the fw can be rolled out quickly.
Got it, ok thanks for letting me know - very helpful! I’ll regroup with @EricM_Inovelli when he gets here and I’m sure we can get this taken care of fairly easily on our end with the manufacturer.
We’re going to push a PR to the device file today disabling it for now. Let us know when it’s fixed please.
This makes sense of what I’ve been seeing. I have my preferences to return to previous state on return to power, but I have seen the lights cycle as if it was air gapped and turned back on.
Thanks for the support here Eric! I never witnessed it but noticed my fan was always turning off, so glad we got it figured out!
Sometimes doing it the “right” way (ZJS programming) brings out the littlest of mistypes lol.
So do we have to exclude the device and then include again after this fix?
I was able to do a re-interview from the zwave2js-mqtt web interface and that fixed it for me.
Just re-interview the node.