Is Zwave slow or is it just me?

If you are saying to move a-wave devices Nd the rules that control them to their own device, the. I can see that working. But if you are suggesting, as per your prior comment, to but the z-wave devices in a different hub than the rules, then I will have to see it to believe it. Could be an excuse to buy the C7....

If you do go ahead and buy the C7, Then the smart thing to do is to move over to the C7 the zwave devices (and the zigbee devices). Then, with HubConnect, you can control them with your existing C5 Hub, and your existing rules.
Nonetheless, as per my previous note, do the simplification stuff first. Do a "soft reset" . Move the Simple Automation (wherever possible), use Notifier, Motion Lighting, Button Controller, etc. Maybe you won't need to buy that C7.

I will say that I absolutely cannot tell the difference between controlling devices from the hub they are joined to, or controlling them from the remote hub using HubConnect. All of my button controllers, RM4 rules, ML, SA, and motion/contact sensors are on the remote hub now, with all of my zigbee/zwave lights and groups/scenes on the server hub.

Wouldn't it be great if we actually had appropriate telemetry within HE to easily diagnose slowness issues? I wish the HE team would take this seriously. It would make all of our lives better.

How much faster? Very curious about this..

I'm sorry, I didn't measure so I can't give you an exact answer.

However, as I said previously do all the other initiatives first to get it back to working quickly.
If you find that it still is slow after all that work, then consider purchasing a C7 to be used just for "device control".

Also, there are other approaches to dividing up the load. One individual has a Hub for each floor in his house. Others (such as myself), use one hub for devices and one hub for control. One individual has one hub for zwave and one for zigbee. In other words, your mileage may vary - before going down this route, plan it out carefully.

I would like to also recommend an excellent response that I read some time ago. It posits that the reason for slowdowns is the lack of memory, and it gives a few practical suggestions on how to increase that memory:
[RELEASE] Hub Watchdog - Simple way to monitor if your hub is slowing down or not
Specifically this:

1 Like

If you can't tell the difference, why do you run it this way? Anyone else agree to move all app processing to a remote hub away from the hub that the devices are physically attached to? Ethernet and http are very fast so not concerned with latency?

Last December, after 6 months of daily reboots and problems with keeping Lightify and Hue button controllers attached to the hub, I decided that the easiest and cheapest solution would be to buy a second hub to put all end-devices on. This solution, for the most part, fixed the problem. Lights on Hubitat 1, devices that automate lights Hubitat 2. It seemed reasonable at the time to put rules that involved using Hub 2 devices on Hub 2, and rules that didn’t involve Hub 2 devices on Hub 1. After getting to the point where both hubs were running equally fast, I thought there must be a benefit to having the button controller and rule on the same hub as the device being controlled by it, so I had a couple Simple Automation rules on Hub 2, using a zigbee outlet plug on Hub 1 and button controller on Hub 2. I then moved the zigbee plug to Hub 2 so I could experience the amazing speed difference. There wasn’t any detectable difference. The outlet already switched on and off so fast that there really wasn’t any room for improvement. I’ve also tried this exercise with motion lighting and not seen any difference. My guess is that any latency introduced by having the rule on a different hub is negated by the extra bandwidth provided by the second zigbee radio. I will say that I haven’t tried having all of the devices in use by a rule on a different hub than the one the rule is on.

Anyone else have similar experience?

Most commonly see it with people using smart light bulbs. They typically make bad repeaters and can cause havoc on a mesh. Some people confine them to their own hub to contain the problem and improve the reliability of the mesh. You can also use a different channel so it reduces the load on the overall mesh. The main issue of using multiple hubs is that you add additional complexity into your setup and more points of failure. Keeping it as simple as possible is typically the best practice but if you understand all the gotchas and can easily troubleshoot issues adding additional hubs does have benefits.

Separate hubs has been great for resiliency & isolation - I had 2 Z-Wave devices go bad (not at the same time) on my main hub while my upstairs hub kept chugging along.

Not that long ago I moved all my logic over to a Node-RED server to reduce resource overhead and help mitigate the HE hub "slowdown" issues that a lot of people were reporting at the time. This seemed to resolve my issues so kept using it.

Now am migrating things to a single C-7 but keeping NR because I like the system and editing the existing rule logic to switch hubs is super simple. Currently running a C-7, (2) C-4's and a C-5..

I have not noticed a decrease in speed due to the shift to a remote server for either multiple hubs (originally connected via HubConnect) OR Node-RED but I have not formally tested this either.

Good info. Just not sure i want to move all my logic to a whole different technology (node red) . Why are you going to consolidate to one C7? Thought you were a fan of the distributed model.

I still think multiple hubs is a good thing and may end up there at some point - I do have a spare C-7!

The folks at HE have always maintained that a single hub should be sufficient for most people even for larger installations. As I am now recommending the Hubitat to my residential clients I thought it might be a good idea to test things out in it's "simplest" form.

As far as Node-RED goes - yeah it certainly is not for everyone but wow is it powerful and flexible. I like that I'm not locked into any one vendor, it integrates with a lot of different technologies and that it's opensource. The HE Nodes allow me to control devices on multiple HE hubs - currently 4 online at the moment. The visual flow control model for me works really well and certainly during this transition is saving me a ton of work rewriting stuff..

It would be nice to see people's z-wave times with Hubitat Watchdog to have comparisons for different setups.

I have found that Hub Watchdog is important for spotting slowdowns, but not for comparing absolute values.
I used to have one hub that controlled my zwave and zigbee devices (around 150).
I used to have Hub Watchdog go to a zwave plus device that was approximately 5 feet away to test response. Time was usually in the .2 -.3 range.
I then purchased a C7 and moved all my zwave devices to it. The physical position of the C7 was right next to the C5 (which now had only my zigbee devices). Times from Hub Watchdog was in the order of around .5-.7.
The cause of the increase was the route of the zwave mesh on the new C7. For whatever reason, on my C5 it was one hop away. On the C7 it was 3 hops away. Why? I really don't know.
So, the number of hops affect the speed as reported by Hub Watchdog.

I get all that. I'm mostly interested in comparing times across firmware revisions.

here's mine show me yours

i have been unable to figure out why i get an occasional slowdown.. it is not always at the same time.. i wonder if the hub cleanup runs at differnt times..
here are the times when it occured my checks are every hour .. so you can calculate the time from the last time shown above. They also may have been when i was running individual node repairs.. becuase that can cause an occasional hub busy message. That would not explain the zigbee slowdown however...

I'm on .148 on a C7 with zwave test device at maximum distance from hub. I was checking the routes from that side of the house. Ignore before 13:00 as I was doing a bunch of other stuff to the hub before then. I also don't currently have any zigbee test devices configured.


My hub started locking up daily and was trying to track it down. I think it was a misconfigured device in google home integration but hasn't been running long enough yet to confirm.

mine is not max distance it is avg. I was just checking on hub performance itself not trying to debug a certain location. The house will be empty for awhile and I want to be alerted if things stop working.

but With an extra hop I was seeing times similiar to yours. I am also c7 on .148

This is my Z-wave test switch I use so I'm not actually turning on and off lights all day long. It's a Honeywell (GE/Jasco) Z-Wave Plus Dimmer the same as most of the other switches in my house. Just need to wire up Line, Neutral, and Ground since I'm not actually controlling a load with it and that lets me use a regular 3 prong plug. I can move it around the house as I want to test different areas. I told all my kids repeatedly that it will kill them if they touch it and I think they finally got the point now to stay away from it. My daughter came to me last night and said: "The death plug is by the printer and I need to print something for school. Can you move it?" It was like 6 feet away from it but sure. I have a box ordered to put it in but it just hasn't gotten here yet. I haven't settled on a good test device for ZigBee yet since most of my ZigBee devices are battery-powered. Thinking about getting a ZigBee in-wall outlet.

Here are the tests from the next day. Pretty much the same results.

2 Likes