Easiest way to remove security from a device #4681
|
Hi guys, I have a few devices that I added with security, and given the extra overhead and because I don't really need the security, is there an easy way to remove the security of a device without removing and re-adding (to a new node)? I've noticed that the replace nodes I've done lately when devices have hung or stopped responding, reuses the old node and entity names in place (which is VERY helpful). Can I do a "replace node" on a live node to have it prompt for security again? Thanks, |
Replies: 1 comment 1 reply
|
Hi Shane, There's no way to change the security level of an already-included node in place — in Z-Wave, security (S0/S2/none) is negotiated once during inclusion and there's no command to re-negotiate it on a live node. And no, "Replace failed node" won't work on a live node either. The replace API pings the target first and refuses to start if the node responds ("the node replace process could not be started because the node responded to a ping"); it also requires the node to be in the controller's failed nodes list. So the device has to actually be failed/unreachable before a replace can begin. That gives you two options: 1. Replace failed node (keeps node ID, names, and entities):
Because the original node ID is reused, your names and entities are preserved — which matches what you've seen. 2. Exclude + re-include: simpler, but you get a new node ID and lose the existing names/entities, so most people prefer option 1 when keeping names matters. One caveat: if your goal is to drop security purely for performance, note that S2 in particular adds very little overhead and is generally recommended — S0 is the chatty one worth avoiding. So removing security is usually only worth it for S0 devices. |
Hi Shane,
There's no way to change the security level of an already-included node in place — in Z-Wave, security (S0/S2/none) is negotiated once during inclusion and there's no command to re-negotiate it on a live node.
And no, "Replace failed node" won't work on a live node either. The replace API pings the target first and refuses to start if the node responds ("the node replace process could not be started because the node responded to a ping"); it also requires the node to be in the controller's failed nodes list. So the device has to actually be failed/unreachable before a replace can begin.
That gives you two options:
1. Replace failed node (keeps node ID, names, and entities):