My problems with Hubitat Z-Wave

If you have both a Nortek and a Z-Stick, Hubitat will use the Z-Stick for Z-Wave. (This is how the C-3 and C-4 hubs shipped in non-North-American markets; you'll need an extension cable for one since the USB ports are a bit too close together for both to fit side-by-side.) I've used both Hubitat and Home Assistant with both with minimal problems on either (I do confess that every once in a while one of my locks won't report a lock or unlock event back to the hub, but there may not be a good repeater in good range of that one, so I haven't ruled out myself here yet).

I was aware of that. I initially thought I would go that route (as I have 2 z-sticks already). But once everything was nice and stable after getting all my devices on, I didn't bother.

Now the only zwave issues I have are on the pairing side. Always takes 2-10 tries, multiple device factory resets, and a few hub reboots to get things to pair. But it always does pair eventually, and my devices work fine after they successfully pair.

As someone with a grand total of 7 Z-Wave devices, I'll chime in with the reason WHY I only have 7 devices; IMHO, the Z-Wave radio in the C5 isn't all that great compared to my Nortek stick (which I have on a 10' USB ext cable plugged into my home server). The devices that I was able to pair took numerous attempts after reboots and resets and excludes and such. Finally, my frustration got the better of me and I went and replaced everything that I could with Zigbee devices. I still have those 7 devices sitting on my HE, but I keep thinking about transferring them over to my HA install.

In contrast, I have 117 physical Zigbee devices and have yet to really have any "big" issues with them.

My Z-Wave Devices: 2 GE/Jasco dimmers, 2 GE/Jasco wall outlets, 3 GE/Jasco wall wart outlets, 2 Ecolink motion sensors, and 1 GE/Jasco Smart Fan controller. Of those, the 2 wall outlets constantly fell off the mesh after a couple of days and one of the dimmers absolutely refuses to pair, and so I never put them back on and they are just dumb outlets now. In fact, one of the wall warts is currently plugged into a "smart" wall outlet. LOL

2 Likes

Just as a data point...

I have the same nortek stick model/version on my home assistant box, and the exact same devices it takes 2-10 tries to pair on Hubitat it takes exactly 1 try on home assistant... Following the exact same exclusion/reset/pair steps. :man_shrugging:

The 4 zwave plus devices I have on my C5 hub were a nightmare to pair too... So I would guess this is a software issue, not a hardware as my C4 and C5 hubs have different hardware... Or I suppose it could be a common cause hardware issue that affects both the C4 and C5 hubs.

1 Like

I don't have a C4, so I can't comment to that, but I've seen the same behavior with my Nortek stick; Z-Wave devices pair the first time and pretty much every time. A couple of the GE/Jasco dimmers had issues, but I think that's just because the older ones suck. In contrast, the same devices with the C5 consistently fail to pair multiple times and then just works out of the blue.

I'm attempting this at the moment. I'm starting with following your Hubitat > NodeRed > MySQL > Grafana (LONG READ)
but it may be a bit over my capabilities.

2 Likes

After "knowing" you here for a few months, I know you'll get it. If you do get stuck, PM me and I'll give you a hand.

As for HA, do you have an install already setup?

2 Likes

Not yet, I was seeing if I could accomplish this part first. Then I was going to move to that next step. Do you have HA running on your server or a Rpi?

I have it running on my server (my horsepower, though HA doesn't really need it). However, if you have a rPi around, I'd throw it on there along with a Nortek stick. That way, you can easily move it around should you need to for pairing.

1 Like

@waynespringer79:
If I may ask, are you using Lock Code manager on your zwave locks?
I found that my zwave locks (Kwikset), have dropped from my zwave mesh after using that program.
Using from RM, from the device page, and from dashboards - no problem.
P.S. I have found that it's critical to have a "beaming" device near the lock (I have a Leviton Zwave Plus Switch nearby).

Yes I'm using Lock Code Manager and I have 5 beaming Aeotec Range Extender 6's

1 next to the hub and 2 EACH by each problem lock.

I have yet to prove it, (I'm currently away from my home for some time), but I believe that the lock code manager is causing locks to drop from the zwave mesh. I know that it happened to me.
Again, I stress that I haven't yet been able to prove it (because if I could prove it, and show that it is repeatable, I know that HE Staff would try their best to fix it).
If you don't use LCM, I would wager that your locks will not come off the mesh!

Interesting theory. Next time they drop I will delete LCM and test it.

My theory is the hub's power supply is under powered for "secure" zwave communication with "secure" zwave devices, but like yourself I'm unable to prove this. Makes me wonder why they set up the zwave radio to "choose" between "Locks and Garage Doors" and All Secure Zwave, as well as having this ability to "limit" the secure communication of zwave is a first I've seen on the 3 different platforms I've used.

I ran this test on one of my many excluding everything and start over attempts. The All Secure Zwave causes far more "communication" issues than just the "Locks and Garage doors" given the appearance of the "secure" communication of the radio as being the problem.

Another data point for my theory of this is here lately after they have dropped off, if I simply do a hub reboot they all come back working again, until a few hours later.

I don't think that the problem. I think the following is the problem:
(from an excerpt of a solution, posted in 2014):
"Z-Wave devices form a mesh network and a beam command from your controller to the lock may have to pass through other devices in the network to get to the lock. These intermediate devices need to recognize the beam command as a valid command and then retransmit it to the next device in the network. If the intermediate device doesn't support the beam command, it may simply drop it on the floor and it will never get to the lock. If your controller is able to be in direct communication with the lock, without any intermediate devices, then it wouldn't matter whether the intermediate devices support beaming or not. But you won't really know whether that's possible until you install the devices and allow the mesh to be configured."

I believe, (again no proof), that the Hubitat zwave radio is not as powerful as the ST radio, and therefore it relies on other intermediate devices, re transmitting messages. However, as the previous excerpt said, all of those intermediate devices must support (in one way or another), the beaming class command. Therefore, you should be looking at your mesh.
As many others have said, "it's all in the mesh!"

I'm not buying to much of this explanation as the problem didn't exist on two previous platforms (yes I also believe their radios are stronger) using far less repeaters and probably none had "beaming" capability. And the locks didn't drop off.

Right now I have 23 repeating devices with at least 5 have beaming capability for only 14 battery devices (3 of which are locks) So I have almost 2 repeating devices for every 1 battery powered non repeating device. As well as 2 beaming devices for every lock that is further than 10 feet from the hub. And STILL have this issue.

1 Like

Wayne, that's precisely my point.

If other systems had hubs with stronger radios, then possibly they could attach to the lock directly. They wouldn't need intermediate, repeating devices, and it would be irrelevant if all devices in the mesh could "beam".
However, some other hubs, require intermediate repeating devices, and require that all intermediate devices support beaming.
Do all your intermediate devices support beaming?
(To a certain extent this is "shooting in the dark", because, in general, we don't know what our z wave mesh really looks like.)

1 Like

Under my latest test currently going on now for 3 days YES. As I have a completely separate hub by itself with the following devices ONLY:

5 Aeotec Range Extender 6's (beaming supported)
3 Schlage BE469 Locks

And the locks have still dropped off.

This just isn't possible. Lcm communicates with the lock driver not the device directly.

The range extenders stay connected now? Or do they drop too?

Last night I tested them again and the "test packets" received were dropping down again unlike all receiving all 30 back instantly after the firmware updates. I'm rebooting that hub again at the moment as all 3 locks dropped off again after reboot I'll test the range extenders again.