Yet Another "Why Z-Wave Is Slow?!" Thread

I was reading through all the existing "slow Z-Wave" threads, and I think I exhausted the generic advice, hence the custom thread...

A bit of history for context:

  • I had a super-fast and responsive Z-Wave network on my C-8.
  • Then C-8 Pro was released, and I (obviously) had to upgrade.
  • After the migration, none of my Z-Wave devices worked (they showed in the settings but were unresponsive).
  • I decided to use mesh between the C-8 and the C-8 Pro, leaving the devices on the C-8, so I reset the C-8 Pro, disabled the radios, and then migrated the apps only.
  • Now, after I brought back the C-8, the devices work, but I see random 2-3 seconds delays on random Z-Wave devices. Sometimes, the same device will respond immediately, and sometimes it lags.
  • I did de-ghosting (finding and killing a couple of ghosts) and a full repair, but the lags persist despite the topology looking healthy and all the devices having plenty of neighbors.

I am out of ideas, so yours are welcome :slight_smile:
(tagging @csteele, maybe?)

Topology

Graph

List

This has always been my experience with Z-Wave. I have two active C7 hubs, but my Z-Wave devices did that with my previous C-4 and C-3 hubs too. I'm going to guess that if I joined my Z-Wave devices to Home Assistant, I would get the exact same result. In my personal experience, this is what to expect from most Z-Wave devices, especially door locks. But if they lock (which they always do), then I personally don't care about the delay. Only devices that are not slow are my old Aeotec HEMs.

This is why I don't have many Z-Wave devices. I would really be unsatisfied with my smart home if this was a thing I had to deal with for every device. Zigbee has served me very well, and I don't have to maintain it in any way.

1 Like

Not in my case. I had a bit of that with C-7 back in a day, but de-ghosting fixed it, and I had an instant response from all my Z-Wave devices, except locks.

Yeah, my locks responses take tens of seconds for me as well, but I don't mind either. This thread is about the switches and the dimmers mostly :slight_smile:

It isn't something you deal with for every device or often. I did the de-ghosting twice in so many years.

Understood. I only have one Inovelli LZW36 Fan/Light controller in use. It's set to digital mode, so it's not directly controlling the fan or the light. I also use its two LED indicators to show us the status of our door locks. I have the Picos on either side of the bed programmed so we can turn them off for total darkness, but a motion sensor turns them back on if I get up during the night. It's just enough light to see in the dark after we've been asleep for a while.

Anyway, long-winded explanations aside, I noticed that sometimes those lights shut off instantly when I get back in bed and press the button again, but sometimes there's several seconds lag. What doesn't make sense is, the buttons for the fan and the light never have more than 1 second delay in controlling the fan or the light. That's surprising since they're talking to the hub via Z-Wave and that's controlling an RM4 Pro which is sending an RF signal to the fan and light. I would think the LEDs in the LZW36 would be just as fast, but they are not always. :person_shrugging:

You list has too many 'scary' RTT values. I first saw a "Avg RTT: 3023ms" and thought that was amazing. A 3 second round trip time?? THEN I found "65002ms" and almost fell outta my chair. 65 seconds round trip time? More than a minute? Then "316634ms" -- I gave up looking. :smiley: I couldn't take anymore. :smiley: That's more than 5 minutes Round Trip Time. Those are numbers beyond what I thought was possible.

I'm trying, in my head to imagine how those ranges of numbers can occur... it's well beyond timeouts, forcing me to consider hub load that is 'blocking' such as synchronous HTTP.

I think you have to bring in the big guns and ask @bcopeland to look at the engineering logs because ZWave on its own shouldn't be able to get values that high. That's an Earth to Mars RTT (4.3 mins)

1 Like

Yup, as I said... A tiny bit slow...

Did you power cycle the hub? Only when power is completely removed will the Z-Radios be restarted on power up. Settings: Shutdown, wait for the message and red led. Remove power for 10 seconds and then power it back up.

2 Likes

I'll try that. When I looked at the RTT 65002ms switch I realized is dead and not in use for a while now. I am going to remove it with the Simplicity Studio and then do the hard reboot. Will report back!

On top of the high RTT some devices have a very high route change count. This resets when the hub is rebooted, so its good to know how long it was running. A good test it to reboot (or power down totally and restart) and then monitor those devices over 24hrs to see if the route change is constantly going up.

Every time there a route change there is basically a storm of discovery packets being sent out from that device. If it is happening often it can slow down the entire mesh.

2 Likes

In terms of locks, I'd like to put in a plug here for (not so new) Kwikset (sometimes called Weiser) locks.
I had many issues with Schlage BE469ZP, so I decided to go back to Kwikset. The Smartcode 620 uses the Zwave 700 series, and it seems to have instant response on my system.
(It also seems to be better built and better designed that the Schlage. The Schlage looks better with a beautiful keypad, but the Kwikset works better. )
Here is a link to this device on Amamazon:
(No, I have no personal interest in Kwikset, and no, this is not an "affiliate" link.)
https://www.amazon.com/Connected-Technology-Featuring-SmartKey-Security/dp/B09HR79RR3/ref=sr_1_5?crid=1QSPMES9H6EE4&dib=eyJ2IjoiMSJ9.6wws0RLAplATmrkzCp8WOxv_bVtALhRysfFnyhVEzkRTW2PznbKLpjph9th86lhSpLTYF-jzQPFMnWESBwhc0OFO54L0zdYrq2k66xX0LzfA8xaZLeqRbyLo-hgeL8-czNMTbyFPywXaoHqMlGCUn9HP7ujSz-ahndMHS5SH4HabYNaPLsx5jvNsvUjaIsOw1rY98qtOfTMyla3Y0KrQOeN-a3EOEcsaN5_hC3DUbd7SKqOhxy7LKP6C015n6Hfxn1-60dze3earvO5lj67V1QkvxGcDNfuZIZxP7iH9Odc.wge0pR-nGwSqbUWjLo_DxZbjq5HdB9WZLGowNScVAT0&dib_tag=se&keywords=kwikset%2B620%2Bz-wave&qid=1709048675&sprefix=kwikset%2B620%2Caps%2C241&sr=8-5&th=1

Thank you! I went with the stupid Ultraloq because of the fingerprint, which is more critical for the WAF than the immediate response (for a lock).

Why not?! I really should be.

Sometimes the delays make sense when you consider Z-Wave's routing strategy. In a nutshell, if the last working route fails, try each of several pre-calculated routes in succession until one of them works; if none do, try mesh flooding to invent a new one..

SiLabs calls that the 'last resort' routing attempt; the delays can be large even in a normally functioning mesh as this chart from SiLab's Z-Wave routing tutorial shows:

If explorers succeed in establishing a reliable LWR you'd expect that large delay to be a one-off; but if it subsequently fails you're back in the timeout/retry loop with all the old pre-calculated routes again (aside from 'getting lucky' at establishing a reliable LWR via explorer frames, Z-Wave routing only 'learns' new routes when they are sent from the hub during Z-Wave repair).

What's worse, depending on the SDK level, older Z-Wave devices might not store LWRs at all but need to repeatedly rediscover them via explorers if their pre-calculated routes keep failing...

I'd be tempted to try Z-Wave repair again; might be worth trying single device repairs on 'awakened' sleeping devices... just give the hub time to distribute the routes it has calculated and avoid using Z-Wave while repair is underway since it will likely saturate the mesh.

That's a great addition to the plan.

Here's what I have so far:

  • Remove the dead device with the insane RTT
  • A hard reboot
  • Wait 24 hours for the routes to settle
  • Possibly a full repair if needed

24 hours later update:

I got top marks in WAF, which is "I can't recall anything that annoyed me today", so that's a win.

For objective metrics, I discovered the Hubitat Z-Wave Mesh Details app, so more scrolling over the built-in list:

Sorted by RTT

Generally, it looks much better from what I can see. The locks are just being Ultraloq locks, I guess nothing I can do about it, the rest looks good, right?!

Sorted by Route Changes

The top ones have a lot of changes; I am not sure why. Any ideas or suggestions?

Sorted by Neighbour Count

This looks good, but it looked good yesterday as well.

It may look better but it till looks terrible IMO. How long since the last reboot in these screen caps?

The locks I would say is normal for locks in my experience, they will have a slower RTT because of FLiRS. They get route changes because of the stupid way z-wave has implemented FLiRS, where the controller sends a packet blind first and if there is no response then it sends the wake up beam out to get the devices attention. There is a 90% chance it wont be listening on the first try.

Your locks do seem to have a high message count. What are they chattering about? Do you use these locks / doors frequently? The chatter and route changes from the locks could possibly be disturbing other nearby devices causing them to route change, and it cascades from there. I noticed this a little in my mesh when I added 4 locks but not nearly to this extent.

I would focus on one device. The Master Bath light. What device is it exactly? How often does it get used? How far from Hub? Any metal obstructions? Does it have any power or sensor reporting built in?

Also, have you tried swapping the antenna from your C8 to the new Pro? Just to rule out a possible defective antenna that shipped with your Pro?

24 hours.

Any way to find out?

Not at all. Since the reboot, I haven't used the two locks on the RTT screenshot.

Do you mean the one with the most route changes? Master Bathroom Pendant Light?
It's Zooz Zen27 Central Scene Dimmer, and it is absolutely nothing special. I have ~50 others just like it. It's probably a 30ft beeline to the hub with two drywalls between them.

The devices are on the C8 with the same antenna they always had and worked perfectly, as I gave up transferring them to the Pro because the Z-Wave devices didn't work after the migration. If anything, the damaged antenna could be on the new Pro.

Just a quick note while I'm out walking the hounds, waiting only 24 hours for Z-Wave to modify routes is probably optimistic.

It was @jtp10181's suggestion:

You might get lucky and see something quickly, but probably not so likely in my experience. Unfortunately not an exact science...Z-Wave is often inexplicable. :wink:

1 Like

So, what would be the reasonable next debugging step?