2 switches were added with the abbreviated capabilities. They respond to on/off commands from the hub normally.
4 switches were added with the normal, full list of capabilities. They do not respond to on/off commands from the hub.
5 LZW36
3 switches were added with the abbreviated capabilities. They respond to on/off commands from the hub, as well as LED bar color changes, normally.
2 switches were added with the normal, full list of capabilities. They do not respond to on/off or LED commands from the hub.
1 LZW31-SN
Exactly one dimmer, my historical “problem child” was the only dimmer to join securely. It got the abbreviated capabilities and responds to commands from the hub.
A total of 19 LZW31-SN switches joined only insecurely despite requesting S2 profiles. They all joined with their full normal complement of capabilities. Mostly they seem to work, modulo some maybe sketchy connections. A majority of these never prompted for the leading DSK digits. A few did, and LEDs turned to green upon entry. None of the other two models failed to get included as S2.
This testing of remote on/off was true with both the Hubitat and the Inovelli drivers.
This morning, after letting the Z-Wave network mature a bit, I ran Z-Wave repair, and then I was able to get all of the LZW36 and LZW30-SN into a state where they are both connected via S2 and responsive to the hub. I did this by excluding the devices with the full list of capabilities on the Z-Wave Details page, factory resetting the switches, and re-adding them. This time around I was particularly careful to enter the leading 5 DSK digits before the switch inclusion mode would time out (this required some preparation of the keys). One LZW30-SN didn’t discover correctly and I had to reboot the Hubitat, forget it, and include it again, but then, after another Z-Wave repair, it worked.
I now also understand what I have been calling the “abbreviated capabilities” on Hubitat’s Z-Wave Details page. They are in fact the inClusters list of capabilities, while on S2 the secured capabilities appear on the secureInClusters list, which is NOT presented on the Z-Wave Details page. So a shortened list means that things are probably working correctly.
And the one little LZW31-SN of 20 that could do S2, so previously problematic I had to move the hub just to flash it, is still happily chugging along, heh.
Further update on SmartStart:
I excluded one each of the (properly performing) LZW30-SN and LZW36, and scanned them both into SmartSmart using Hubitat for Android. They both included with S2 and respond to commands. Looks good.
Neither adopted the device label I entered, and they remain in the “included, pending” state in SmartStart. But I experienced other unexpected behavior with regards to the naming as well. For example the second device added to the SmartStart list inherited the name and room of the first. Also, sometimes when looking at the SmartStart list, duplicates appear (but disappear upon refresh). I suspect the problem taking the device labels may be on the Hubitat side.
EDIT: According to Hubitat not adopting the device label from SmartStart is things working as expected:
I tried again last night with my LZW-31SN and could not get any of them to pair with S2, how were you able to pull it off? Both of my LZW-30-SN did pair via S2.
Mostly, I was not. Only 1 out of my 20 LZW31-SN paired with S2, despite repeated efforts on the rest. This seems to confirm what @bcopeland reported above last week, that the LZW31-SN routinely fails S2 bootstrapping, at least on the C7. We are still waiting for some official response from @EricM_Inovelli or another dev.
We are looking into the issue with the LZW31 & S2 on a certain version of the Z-Wave controller SDK. Might take a while to get to the bottom of it, but I’ll keep you updated. For now you will have to use the downgraded inclusion that occurs.
Hubitat 2.2.3.132 released today, so I decided to try a few times to include of one my LZW31-SN dimmers with S2 again. This is a switch that failed to include with S2 previously.
Long story short, no luck. I included it 3 times, was prompted for the DSK once, and never got S2 security.
I upgraded to the new firmware yesterday too. I installed a new Black Series On/Off and managed to get the S0/S2 popup. I unselected all and hit OK. Then another popup with the entire QSK code popped up and I hit OK (or whatever next was). The device was found, but did not finish “Initializing” before the timer ran out. I went to Z Wave Details and selected “Discover”. Then the device was finally initialized and added to the device list.
Isssh…with the C5, I didn’t have that problem, so that is what I was used to. I will try on the next switch to install (should be sometime today). Thanks for the info!
Not to say the C7 won’t be a great hub, but it’s starting to look like the C5 is the recent champ. Right now I have the C5 as a “Server” node and runs all the rules; C7 is the device host (“Client”). At first I thought the Hub connect was being the problem, but it may be the C7 not wanting to send ZWave commands out…
It looks like a new production run of the Red Series Dimmers is in. It would be interesting to see if they have the same S2 inclusion problems with Hubitat.
Yeah we still have the old firmware on it unfortunately as our engineers did not figure out the issue when they were in production.
Good news… We received some beta firmware this morning that should fix the bootstrapping issue. I’ll let @EricM_Inovelli explain it better and post it, but this is the explanation from the firmware engineer.
We have fixed the bug, the reason is that the device does not allow ADC detection when we used the 700 series hub, we modify the ADC detection mode to avoid it.
I have no clue what that means but it appears they have fixed it, so fingers crossed.
