What I learnt from Zniffering, and lessons for the "Slowdown" Disease

My assumption is that ceteris paribus (all other things being equal), running the built-in zwave repair process a number of times during a day, should have no impact on the subsequent speed of the zwave network.

If it does have an impact on the speed of the zwave network, then the built in zwave repair has a resource leak (or some other issue) which causes a slowdown.

I had the slowdown disease prior to getting my z-wave locks. The last HE update that addressed queue overload seemed to fix my issues, until I got clever and added a Tasmota WiFi device that was linked to my VoIP ATA adapter LED to report when the line was in use. Issue was the light flashes at 0.5Hz, so the hub was getting bombarded with traffic. My typically 3-4 day slow down became almost instant until I fixed the code in the Tasmota.

Soooo.... it seems the HE still has issues where the task queue seems to overload, and will not recover until it's rebooted. Perhaps it gets substantially fragmented as tasks in the middle are kicked out? Everything still functions normally, it just is delayed at least 2 seconds per action.

This has been my experience too. Even removing and adding nodes to a Z-Wave mesh tends to change things immediately. The route invalidates, explorer frames are used to validate a new route and everything works. Device returns, routes re-establish.

I keep seeing references to waiting 24 hours here regarding Z-Wave, and whatever thing that requires this is not on my network. And I have near or more than 100 Z-Wave devices.

1 Like

@endorphin_junkie:
So, is it your experience that running a zwave repair a number of time (say 3 or more) during a day, causes a slowdown in all automations?

Maybe this is where the ghost node thing comes into play dunno. I do know that adding or excluding devices can majorly impact the speed of the network - I could tell this by zniffing especially with the MS6's. How the network speed relates to the slowdowns - well my main hub would reboot every night around 3am right after the repair so mmmm. I also have a z-stick and included it on my main hub as a secondary controller then I was able to see I had 6 ghost nodes that never cleared my system (at least based on their lower #s). Was able to remove them.

I have to say its been about a week or so free of nightly rootn tootn rebooting but I've also been doing a lot of stuff to reduce hub overhead, removing rules/apps, replacing old z-wave devices, relocating hubs, adding new zw repeaters etc...

My main hub now seems stable (except for some slow responding Aeon switches - Nano & Dual). My upstairs has been rebooting nightly - this morning did a soft reset. Will likely check that one for ghosts too if it persists...

I actually haven't run a Z-Wave repair in a very long time, I can't remember when I last did.

My point is that repair is often unnecessary, I simply don't use it. Unless you have added a brand new repeater and you want to get some nodes to start using it right away, there's rarely a reason to retrace the mesh. Removals are routed around nearly instantly.

I mean, here's the thing. If you had a traveling z-wave setup for conferences, and you would take it all down and then wire it all up in a new space -- yeah, you should repair your mesh after doing that. But I don't tend to move things around in my house, and when I do it's usually just one thing. Z-wave sorts itself out really fast, without any help IME.

1 Like