Create a virtual device (say a switch) and name it place holder (or whatever you like) and change the rule using the device that you're changing out to place holder (or what ever you named it) exclude and reinclude (click skip when prompted) and then change the device back to what ever you named.
Sounds workable but tedious, especially for 20 devices.
Can't I just reset a device, kill power to it, and then "Repair"?
There can be some benefit to S2: it allows the use of Z-Wave Supervision, which is one way drivers can help make sure devices receive commands sent from the hub (send the command, take note, wait, and try again if no report back for that command: this is handled at the application later, which on Hubitat is the driver--not lower down, where any kind of Z-Wave also has some means along these lines with which I am less familiar). Maybe that is the discussion you've seen? Not all drivers do this, though I think most built-in ones do if there device supports it.
S2 does not cause the amount of overhead that S0 does, and I don't see you with any S0 devices, so that's good! I do think, anecdotally, that some device firmware may not have been as well tested with S2 (certification be darned), and some people will still recommended avoiding it for various reasons. FWIW, I think all gen 2 Inovelli devices are paired with S2 (just because I wanted to test the setup that o assume most users would use: the defaults), and most haven't given me any trouble except old firmware during pairing, they've released an update for at least one device recently that may help (as SiLabs' fix might in the future if this is indeed the problem).
4 Likes
No.... The database in the z-wave chip doesn't work like zigbee does. Regardless of the platform you're on they all operate the same in this case. I think you can try the replace, but I don't think that works with devices with the same id... (someone will correct me if I'm wrong). As @bertabcd1234 points out, there can be some benefit, but my own opinion is lessening the overhead of any encryption helps overall. If you are satisfied with the speed of your mesh after removing the ghosts, you can just leave it as is...
Yeah, about that ... at one point, I had started a discussion on the idea of using Supervision to increase reliability. I was motivated to try and find a solution to increase reliability because I would occasionally have periods where devices disn't respond, or had huge delays. I thought this was packet loss (many advised that these situations were issues with mesh strength). So, in theory, it seemed that Supervision would help allow recovery if a packet was lost (at least I thought it might). Turns out, as I've learned more, for non-secure devices, you're better off just letting the normal Acknowledgement / Retransmit routines in the SDK do the recovery (its simply too hard to accurately do the necessary Supervision timing and coordination, and as the Ack / Retransmit at the SDK level should already be handling things, its unnecessary overhead complicating the drivers). In the end, I learned that the only time its necessary to use Supervision is when using S2 security where its is necessary in the event that some of the security setup packets are lost.
So, yeah, using S2 for reliability turned out to be just wishful thinking. I went the opposite direction and removed all S2 from my network and reliability increased.
As for the initial problems I was trying to solve, I'm now convinced they were (largely) related to z-wave SDK problems. Some of the problems have lessened over time as the SDK used in Hubitat has been updated. Recently, there's postings about a new Z-Wave SDK 7.17.1 which looks like it may be the "fix" many of us have been waiting for (the notes in the article describe delay issues and other problems I'm still experiencing). Hopefully Hubitat gets it implemented soon. Zwave get updated 7.17.1 - #47 by 672southmain
3 Likes
Very informative and helpful. Thanks.
