I am trying to move some ZWave LR devices from S2 security to S0. C8 pro. On current firmware. Zwave JS. Can someone tell me what would be the best way to do this? If you read what I initially wrote below, my attempt resulted in what I like to call "ZWave hell" which is a very common dimension any time I try to alter anything ZWave.
I had a zooz zen54 working via SmartStart as a LR device with S2 Authenticated security. I excluded it. I factory reset it. I attempted to re-include it using SmartStart, but with no security.
From the ZWave logs:
2026-05-18 04:48:25.246 PMCNTRLR [Node 308] Security S2 bootstrapping failed: None of the requested keys were granted by the user.
"NWI Home ID not found in provisioning list, ignoring request..."
I'd attach the full log with DSKs removed, but 60 seconds of it is too large to fit here, it seems.
I fully power cycled the hubitat. I removed the entry from SmartStart and added it all over again. I verified the DSK is correct. No dice.
Any ideas? I did try including the device the old fashioned way on the mesh without SmartStart and it works just fine. I need SmartStart because I want to include it as an LR device, but no security.
LR pairing requires S2 per ZW spec, so (as far as I know) there's no path to come down from S2 if you want LR.
Edit - out of curiosity, why do you want to avoid S2? Although S2 had a rocky start many years ago, those kinks have all been worked out - there really aren't any disadvantages to it these days. All of my ZW devices (mesh and of course LR) are paired S2.
I appreciate the information. I think I am pretty familiar with Z-Wave though as I have over 200 devices running near-flawlessly after years of troubleshooting. The problem seems to be that Hubitat is always so rough around the edges - a proper UI would not allow one to select LR and then also select no security for pairing.
I have over 200 zwave devices. Security adds more overhead and slows things down in my setup. I have gone down this rabbit hole before and everyone argues it does not. They are wrong.
Are you using my SmartStart Manager app on the hub or just the mobile app? I have thought about adding more checks in my app but this comes up very infrequently. Also would not fix the mobile app itself allowing it.
I had attempted with both. I do like your app. I just wish things were more polished. As far as your app, it's a user app - you were kind enough to make it for free, so I cannot complain about polish there.
Replying to myself here, I just wanted to add - I know that LR isn't using the mesh, so one might ask why it matters if there is a tiny bit more overhead with S2 security. My theory (which I have evidence to support) is that the additional data required with security utilizes more radio time, which is still finite even between LR and mesh zwave devices.
Yeah he is saying the UI should NOT allow you to select invalid settings. Which currently it lets you do whatever you want even if by spec there is no way it will work.
@acr2001 I had something similar at a house I was working at. Pretty much everything was paired with LR to start with. Having all sorts of issues with the Garage devices. Constant failures with LR. Devices were maybe 30ft from the hub through a floor change and a couple walls. Wood and drywall construction. So I switched some stuff to Mesh to make some hops available and switched the garage devices to mesh. They started working better but one device kept having issues. Now I was watching the mesh with zsniffer and I could see it kept trying to re-route. I added MORE mesh devices, still not playing nice. I finally ended up switching that one device to Mesh no security and then finally it was working reliably. The only thing I could think of was that S2 was slowing it down just enough that it was not getting feedback quick enough so it would re-route,
Amazing what you wrote, because I am dealing with devices in my garage in a very similar situation. My mesh has always been very difficult to get "happy" and each time I add to it, there seems to be a high risk of "disturbing" it, so I have been successfully sticking to LR as of late, with new devices.
I am seeing RSSI as high a -96db on some of these new dimmers which is probably the reason they fail every so often. I need to either add a second Hubitat for the garage or I need to drill holes in the light fixtures that I bought and run the wires so that the Zen54s can sit outside of the light fixture. Right now they are sitting inside of aluminum lights, hence the poor RSSI.
I solved TONS of problems over the years by removing S2 security from mesh devices. I do of course use it on devices where it is necessary. Not only does it add overhead and cause issues in edge cases like you mentioned, but I have also seen device firmware (admittedly in older devices) that has issues with encapsulation. My older Zooz switches would actually completely crash (the physical switch would not even work and the light would be stuck in whatever state it crashed in) - requiring a circuit breaker flip since they have no air-gap. Disabling security on those devices fixed the problem completely - and it's been years. They used to crash maybe once every month or two. There is no reason to use security on devices that don't need it, and there is no benefit in my opinion.
Even if Hubitat's UI has a miss and let me select invalid option combos, they could at least have had a useful error pop up somewhere! The error in the logs isn't even very useful in identifying the source of the problem.
Just an update - I have moved the Zen54s outside of the light fixtures and the RSSI improved to -93 on average, which is fairly good for ZWave LR. I still get rare glitches where one light will take up to 20 seconds to respond, after there are retries. To those who continue to argue that S2 security is perfectly fine - here you go from the ZWave logs:
"2026-05-20 04:52:47.985 PM CNTRLR [Node 272] failed to decode the message, retrying with SPAN extension..."
This is the error that comes up when I see the issues. It is due to S2 security.
But I wonder if it fails to decode because the message is corrupted. So then without S2 the hub might be receiving and accepting partially corrupted messages.
We have seen this in the past with some temp sensors that would report in extreme temperatures at random. It was a hunch by someone that the messages were corrupted and that S2 might fix it since it has better error checking. Once the user switched it over to S2 the issue stopped. Same thing happened with at least two people on here.