Hub Firmware Beta 25.26

@Nezmo

This is my investigation result to your comments and concerns about the your switches status not being updated as fast as 0.24.X. I had discussed this in private message with you, but since you asked about it again, I figured maybe there are useful information for others.

How Z-Wave Local Polling Works:

A given network has Z-Wave Devices (X), and there then exists (Y) devices that are of listening type and mains powered that the the hub will poll. Due to an old and expired since 2016 Lutron patent, some older Z-Wave devices (Switches) could not notify a change in their state to the hub, so we must poll these special devices at a faster rate so when there is a change in their state, we can catch that change. Z-Wave switches that support Association (0x85) command class do report the change in their state.

The Y devices are compromised of the following group following types:

  1. Fast Polled (F): Each device will get polled again if 10 seconds has elapsed since last poll. The devices that fall under this group are the devices that do not report the change in their status as discussed earlier.
  2. Slow Polled (S): Each device will get polled again if 15 minutes has elapsed since last poll or activity. Only devices that are listening and mains powered fall under this type of polling. Import to note, that switches that do report a change in their state fall under this type.

So Y = F + S

Then there is also another rule and Z-Wave specification rule that we must abide by

  1. There needs to exist 1.25 seconds difference between two consecutive polls (t(n) >= t(m) + 1.25 seconds; where n, m is any node)

So basically, when you have “Y” Nodes that need to be polled, the fastest that we can poll another device in the F is the largest value between the following

  1. 10 seconds (Fast Frequency Interval)
  2. 1.25 seconds * F

Example 1:
So, let’s say that a given network have 50 Z-Wave devices, 30 of these devices are listening devices (Y = 30), 10 of 30 devices are switches that need to be polled (F = 10, S = 20) at a fast rate, the fastest that a non reporting switch will be polled again is 10 * 1.25 seconds = 12.5 Seconds.

Example 2:
A network has 100 devices, 60 of those are listening devices (Y = 60), 45 of the 60 devices are switches that need to be polled at fast rate (F = 45, S = 15).

This gives us the fastest a switch can be polled = 45 * 1.25 = 56.25 seconds

However,

I have tried to emphasize that those calculations are the FASTEST calculations and if everything ideal

  1. Polling messages have lower priorities than users messages, so if there is a user/cloud command those are executed ahead of polling messages, so that means the next poll can be delayed
  2. Some devices could take longer than 1.25 seconds to complete a polling session which includes there request and a response.
  3. Some cases, the slower devices (S) will need to be polled as well (15 minutes has elapsed).
  4. In some cases, if a S device has missed many polls, the device is no longer polled at faster rate to avoid slowing down polls for other devices.

Also, this behavior has been the same since 24.X and has not really changed, I even have put some hubs using the old framework (in 25.X we have a new Z-Wave framework while having the ability to put hubs on 24.X framework so essentially running 24.X in some sense) and noticed 25.X is faster in terms of behavior.

Suggestions

Replace your older Z-Wave switches with newer ones, and make sure they do support Association Command class (Most of the Z-Wave Plus switches do support Association) or in general the newer devices do, otherwise you could possibly be getting the same issue where the state is not reported when you expected.

8 Likes