Been chatting with AI about some sluggishness in my ZWave network I’ve been refining over several weeks.
I’ve started to move problem nodes over to LR to make them more reliable AND to take then out of the mesh intermediary role. That is working to some degree but hollowing out the mesh has negative implications too.
I was surprised at this dialog where AI is suggesting too big of a mesh can be a problem because the routing tables in the device become unwieldy. There seems to be some logic to it but I am wondering is this is just AI flat out guessing and in fact this isn’t really a known issue.
Is AI full of it???
_______________________________________________
You have hit on one of the most surprising secrets of modern smart home engineering: more mesh isn't always better. [1]
When Z-Wave was originally designed decades ago, houses only had a handful of smart devices. In that world, adding more devices made the network stronger by filling in coverage gaps. [1]
The "Too Big Mesh" Paradox
With modern 800-series and Z-Wave Plus hardware, we now put smart switches in every single room, on every wall, and even in multi-gang boxes right next to each other. [1] Your layout proves this—look at your neighbor counts again:
Node 90 has 103 neighbors.
Node 77 has 98 neighbors.
Inside the tiny microchip of a Z-Wave switch, there is a finite amount of memory reserved for the routing table. When a device is forced to keep track of 60 to 100 neighbors, its routing table completely overflows. [1]
Instead of a clean highway, your mesh becomes a packed stadium where everyone is shouting at the same time. The devices get so overwhelmed trying to calculate the "best route" through 100 choices that they choke, drop packets, and fall back to 9.6kbps out of pure exhaustion. [1]
I asked AI to confirm, it mentioned the routing tables in a way, saying that the most demanding tasks for Zwave are network healing and neighbor discovery, though it didn't mention the devices themselves having to deal with large neighbor tables. I really don't see why a table with 100 items is considered large in any system. DBs can be quick with millions of rows in tables.
I asked about that specifically after:
" No, a Z-Wave device generally does not slow down just from storing a large neighbor table. The slowdown you're asking about is rarely caused by a single device's own 'knowledge' but is instead a symptom of the network-wide congestion discussed in our previous conversation."
Further, it told me that the device does not try to find a route from the neighbor tables with every command. It uses LWR (last working route). It finds the best route during neighbor discover and healing, and then considers that to be the LWR, which becomes a static route that will always be used. Only if a command fails repeatedly does it look for a new route.
The Hard Limits & Real‑World Reality
Technical Ceiling : The classic Z‑Wave mesh topology is capped at 232 nodes (with node IDs 1–232). Z‑Wave Long Range, however, supports up to 4,000 nodes in a star topology.
Practical Ceiling : Most gateways slow down after 40–50 devices. High‑performance hubs can handle up to 100–150 devices before congestion becomes noticeable.
I have 45 Zwave devices, so I guess I am still good. Most of my devices are Zigbee.
Nope, you can have a dozen or the max of 232 and experience problems. It's all about the traffic. This was not written by AI and was posted a few years ago. Have a look: Dos and Don'ts of Z-Wave Power Reporting (repost)
Yes, but I believe that is a short coming with Z-Wave. So you hit a period of high Z-Wave activity many collisions and then a device ratchets down to a “tortured route” at 9.6kbps. That then becomes the LWR and it sticks to that. There really should be some background task that seeks to upgrade from lowest common denominator routes. It doesn’t have to be hyper agile, just operate in periods of low Z-Wave activity.
I started the build an App that would look at the “tortured routes” and rebuild just those routes (I thought it could run once a day in the middle of the night) but I couldn’t get the data out of the Z-Wave details table into an App to decide which nodes (the tortured ones) to schedule for a rebuild. It’s too bad because frequently when you manually rebuild these links they find a better path.
Interesting. I feel I have maxed out at about 45 Zwave devices at this point, they are mainly in-wall dimmers everywhere, and a few outlets. Everything I have added for the last couple years has been Zigbee, so I don't see myself getting into tortured route territory with Zwave. Good to know, though.
I have one zwave outlet that does power reporting, all the in-wall dimmers are pretty network quiet.
My old Aeotec HEM was kicking out readings at the min interval of 5 seconds for years. My new Aeotec LR HEM is at the (new) min of 10 seconds. No problems. I don’t pile on unnecessary electric readings from plugs. I have 106 LR nodes and 11 non-LR nodes.
Yes I had the same problem (with an old HEM) so I either shut off or extended the refresh time to the largest number for all the self reporting items, then I created a rule to poll the HEM at intervals I prefer. I even have an on demand refresh VSwitch. Works great but before doing this it was unnecessarily chatty.
I guess a pet peeve for me is the Zooz devices (smart plugs) that have almost a dozen settings for various reporting. How about a single parameter to just turn it all off?!?? Added to that is the ambiguity at the category level (V, A, W, kWh, ..) of reporting frequency, reporting threshold, reporting disable/enable, … it’s kind of a mess how they thought this up. Anyway a simple parameter to turn it all off would simplify reporting for users like me who don’t use any of the reporting. Make that the default level for e new device.
I have bought a few Minoston MP21Z 800s lately as they don’t have reporting so it simplifies my setup. Zooz and Minoston use the same ODM to source their products so the innards must be very similar.