Fairly new user. I've been up and running for a few weeks with a handful of z-wave Inovelli switches, one Fibaro ZW5 triple sensor (motion, temp, lux), and integrating nicely with LifX and Wiz bulbs through the app, have a Harmony hub controlling my theatre connected and a flic hub smoothly sending maker api commands. Everything was working fine as I delve into the world of complex rule machine routines, until I added two new Fibaro sensors last night. Since then, all of my z-wave devices have become only intermittently reliable.
I've done several hub reboots, z-wave repairs (there are some questionably circuitous routes in the mesh), and each of my inovelli switches (dimmer, red and black series) are at times now showing up as pending or unreachable. I did some forum searching and I THINK I know the problem, but wanted to see if I missed anything.
The 3 Fibaro's show as using S0 security, which I've seen mentioned can be a resource hog and cause the mesh to fail. The Fibaros and Inovelli are my only Z-wave devices, but I have plugs, a thermostat and garage door controllers to add later. Given the timing of my issues are the sensors the most likely culprit for me? If so, what's the best option moving forward?
- Remove and trash them?
- Decrease their refresh/polling intervals- will that help enough?
- Remove them and get something called a secondary z-wave stick to mesh with them (I don't really know what that is yet...)
Thanks for any tips!
I didn't want to risk having the device joined with S0 Security on a C-7 so I removed it and installed it on an old C-4 hub. As I understand it, the older Z-Wave stack doesn't support security so it joins with no security [please correct me if I have this wrong]. Then I share it with Hub Mesh.
Those Fibaros also seem to be chatty as heck with all the different things they can report. It hasn't been an issue yet but I am keeping an eye on it.
Not wrong so much as over simplified. 
The series 500 chipset used in Hubitat Hubs prior to the C-7 supported the same security options of S0, S2 and unsecured. Those hubs were not certified and therefore Hubitat could choose to pick and choose the options and how they interacted with the user. Hubitat chose to not enable S2 and chose to not force S0. They made it an option and advised us not to choose it unless required... like for GDO and Locks. Remember this option???
The C-7 hub got certified and that meant following all of the certification rules laid down by SiLabs.. including that during the Join process an S0 capable device would join S0... no option to select unsecured. For devices that support S2, then Hubitat must popup the options and on that page, unsecured would be allowed.
I have simplified and perhaps over simplified too.. but in a different way 
For C-7 users, today the only choice to join unsecure is to use a secondary controller and the PC Controller tool from SiLabs. Even using a 700 series secondary controller with PC Controller leaves open the option for unsecure. It's not the chip, 500 and 700 are the same in that sense, it's the options shown by the software/UI.
1 Like
Ug, just took an hour to exclude, remove, and then remove the ghost of one of those dumb sensors.
So, did some further reading here: Dropbox - Hubitat UZB Stick How-To.pdf - Simplify your life
If I'm understanding correctly, there are 2 methods to use these Fibaro's and other S0 devices to prevent mesh issues.
1- is to use the UZB stick attached to PC to pair them with HE with no security.
2- Is to have a second hub (C-5), or some sort of always on Z-wave stick as a secondary controller, and then just keep those devices on that hub.
Am I interpreting this right? Any major considerations for going with one method or another? Other than needing to add yet another hub to a bloated wanna-be smart home?
1 Like
Excellent explanation. Thank you!
The UZB has a tough time working with the PC Controller software on a PC. Maybe it needs special drivers, but I just went and bought an even smaller, ZWave only, usb stick.
DigiKey and Mouser both sell them.
https://www.digikey.com/en/products/detail/silicon-labs/SLUSB001A/9867108
One or the other... a 2nd hub can use one of several Apps to 'mirror' devices from one hub to the other.
A secondary controller, such as the stick from Digikey is used during a Join. It can be powered off after, but since it just sits in a USB socket, you may as well leave it powered. When you need to Join one of the S0 devices as unsecured, you plug the stick in your PC, do the deed, and plug it back in to always on power.
I have 7 Hubitat Hubs so I can't really respond to:
@csteele Ha ha ha! Fair point. Thanks for the suggestion, I'll look into that. In your experience is there any specific reason, pros or cons to go one way or the other? I feel like using the stick to join devices as unsecured is simpler than setting up a new hub just to keep them isolated from the main mesh.
Can I expect that my several year old Linear brand garage door openers I salvaged from my vivint system are likely to be one of those S0 security only devices?
Garage Door Openers (GDO) are always S0 (or more) and they just will not work unsecured. So there's no reason to shy away. I have a Linear also and it's been connected to at least 3 of my hubs. It's a bit fiddly to make sure the Join completed securely. If it didn't you have to exclude and then include again, til success is achieved.
After each join, check the Details page and verify:
- zwaveSecurePairingComplete: true
S2 will be 128, meaning it's not S2 but is secure. Programmers right?? !! Who would guess 128 means S0?
By comparison a S2 will be above 128:
I have PLENTY of Hubs to Join ZWave devices and could follow that pattern of splitting devices along those lines. I don't and use physical as my split criteria.. one hub for Upstairs, one for Down, etc. Therefore I chose to use the ZWave usb stick method to join a device to the "right hub" In my view, Hubitat will eventually fix this gap, but for the moment, the SDK that runs out on the ZWave radio is changing too much.
So I got my stick from digikey- pairing it to the hub was straightforward. I added the offending sensor, and it ended up being re-added with it's old ID number and S0 security- must have still been an invisible ghost association despite it not being in the list previously. So I used the stick to successfully remove it. Problem is, I can't get it to properly re-add now. I've paired and removed multiple times- it always takes the next sequential ID number now) Sometimes it seems to have worked according to the controller logs, but shows up in hubitat as an unknown device that it can't collect data from, and can't trace a path towards. The PC controller app has never given me a pop-up asking to chose a security level (is it supposed to?). The last several attempts to re-add have just resulted in a time out, and a failed add message (although the PC controller still shows it as a motion device after that, but it doesn't turn up in hubitat at all).
I've been pairing it right next to the hub. Is it possible this sensor just has a defective z-wave card? I have 2 others on the network right now with S0 that don't cause trouble. It was when I had this one joined via hubitat previously that my network blew up. Next step would be to see if I can pair one of the other 2 unsecured with the stick, but I'm hesitant to mess with something that's working fine at the moment. Any other suggestions, or ways to verify if my sensor is faulty?
Chees.
