Many of us have probably seen postings from time-to-time about overloaded z-wave meshes, and need to limit power reporting, etc. I was interested in looking at exactly what this means, so I thought some z-wave numbers analysis (albeit simplified) as to the number of packets that could be sent in a z-wave network might be interesting.
- I have a Z-wave network with 100 nodes, looking at the bandwidth and hop count, I found I have an average Hop distance of 1.78 hops, with an average bandwidth of about 80 kbps.
-
On the hop count, more specifically, 47 nodes had direct (1 hop) connection to the hub, 51 had 2 hops, and 20 had 3.
-
Interestingly, a large number of the "multi-hop" devices and "lower speed" connected devices were battery operated - for example, 10 out of 12 of my HomeSeer leak sensors were multi-hop as were 4 out of 5 door locks.
-
Now, Z-wave is a CSMA/CA type network (Carrier Sense Multiple Access with Collision Avoidance), like WiFi. The CSMA/CA algorithm tries to monitor and sense when other nodes are transmitting to avoid problems, but even so,, you can't ever achieve "full" efficiency of the network due to some packet loss, collisions, etc. . There are a lot of papers out there modeling efficiency of CSMA/CA networks (considering collisions, packet loss, retransmission, etc.), though I didn't find one specific to z-Wave, a rough guide is you can get an efficiency of about 50% as the network gets larger. A Hubitat hub should be able to transmit much more efficiently - it knows when it is already sending another packet, so it should not cause self-collisions; the collisions would mroe likely be on the acknowledgements and hops. So given that 50% efficiency of a channel, that average channel bandwidth of 80 kbps results in more like 40 kbps that can be put to use. Drops fast!
-
But wait, modern z-wave chips communicate on multiple channels simultaneously - I think there are 2 channels in the U.S. (actually, it might be 3, but looking at worse-case of 2), so different nodes can use different channels and can round-robin between them -- big advantage - and we're now at 2 channels at 40 kbps - i.e., back to the 80 kbps total. Basically, the multiple channels counters the losses, collisions, etc. - how convenient. Update: I checked my z-wave logs and 3 channels are used in the US, so the performance could be better than I'm estimating here.
-
So, divide by 8 to get capacity in bytes, and that's about 10 kBps as the expected throughput on a Z-Wave network using 2 channels after accounting for collisions, loss, retransmission, etc.
-
Now, how many packets per second can be transmitted with that 10 kBytes/s - well, z-wave uses the G.9959 physical layer and each packet starts with a preamble of 24 bytes -- used to synchronize receivers and transmitters and for the CSMA/CA algorithm to detect that a transmission is about to start -- , add to that a start-of frame and end-of frame, and you got about 26 bytes of air time before you even transmit anything useful.
-
Then start framing your data - add in the HomeID (4 bytes), source ID (1 byte), Header (1 byte), routing info (up to 4 bytes), and data length (1 byte), and you have another 11 bytes -- so about 37 bytes of air time just to get started.
-
Now the rest is relatively small - a simple command like an on-off for a device is only about 2 bytes, while a complex report -- such as a power or sensor report can be more ( about 15 bytes for a Meter Report using 4 byte meter values.
-
So, look at worst-case packet size -- i.e., for a meter report -- you get about 52 bytes of air time used up between the preamble, basic framing, etc. But let's double that - every time you send, you also get an Ack coming back the other way. Ack frames are much smaller, but let's say that the sending and Acking of a packet uses up about 100 Bytes of air time for both the send and ack.
-
But wait, my average hop count was 1.8, so each time something gets sent, multiply by 1.8 since that's the average number of times you repeat it - thus, that is 180 Bytes of air time gets used for a transmission (again, leaning toward the worst-case use of larger packets, etc.)
-
Looking at the 10 kBytes I found in 4, and considering a 180 Bytes of total air time for a packet after you look at headers, loss, retransmission, etc., should allow about 55 separate commands or reports (together with their acknowledgements) a second. Really quite a lot for a home and gives a bit more perspective on how hard it should be to really overload a z-wave mesh.
-
Now, let's say you had 50 devices with metering, and they reported voltage, current, and power - 3 reports. If they report once every 10 minutes, that's 150 reports / 10 minutes, or about 1 every 4 seconds. I.e., that should have almost no impact given the ability to send about 55 reports / second. At 1 report / minute, you'd have about 2.5 reports a second - still should be OK. On the other hand, if you had those devices reporting once every second, that would be 150 reports a second - and your network would fail.
-
My simple conclusion - it should be very very rare that anybody has to worry about having enough transmission bandwidth in Z-wave. 55 reports / second is quite a lot and unless you've pumped up the power reporting to ridiculously short periods between reports, you should be fine.
