Z-Wave Details: S2 and Supervision Discussion

For a number of years, I’ve been convinced this happens. Randomly and unpredictable. Maybe different devices. Maybe months/years apart. Read the story in the link in my post, above, for the rationale…

1 Like

By design, Zwave does not guarantee delivery of messages or state. There is a concept of “SUPERVISION” where a device can send a message that it wants a response back from the hub, and will keep retrying to contact a hub until it gets a positive response that the message was received. This is often used in things like smoke/fire alarms, but usually not in motion sensors (the ZSE40 doesn’t support it). And there are limits (X number of retries max with Y seconds between etc).

Most motion sensors just send a single update when they change state and hope that it arrives back at the hub. If it gets lost along the way, the device has no way of knowing.

Unfortunately most hubs don’t support supervised messages very well. SmartThings Edge doesn’t support it at all.

Wireless motion sensors on UL listed security systems will continuously broadcast their state of motion as long as it persists, so that if one gets lost another will hopefully be received in 10-30 seconds. Wired devices are still the most reliable options.


I completely understand, it makes perfect sense for a battery-operated device to do that - just never thought about it until now…

This is, I assume, common to all sleepy devices? Falls to reason…

Most, but not all. As @csstup mentioned, Z wave does offer the “supervised“ command set, which will verify receipt, but it’s typically only used for really high security use cases.

But before we start going down the path of “supervision would be great for everything,“ read the following very thoughtful analysis:

I suspect that the problem described there in is why SmartThings doesn’t support supervision at all. They just don’t want to get into these weeds.

Most people just don’t intuitively understand what zwave was designed for. Automated lighting systems with very low traffic and no real time reporting.

That’s not how it used today, but it is what it was designed for.

Trying to make it fit a “tell me everything in real time, now!“ is just a bear. :bear:

1 Like

And, I would also mention that powered devices generally work the same way with the same “limitations”. If a powered light switch is turned on, it sends a message to the hub saying so. It doesn’t verify, in any way, that it actually made it (unless something like SUPERVISION was used, which no switches would bother.) Some hubs will poll powered devices every so often to check their current state - to get them back in sync in case they aren’t. Powered devices also don’t tend to send their state unsolicited (without being asked) unless actuated (such as a switch being changed logically or physically). Some might have a “send everything even if nothing has changed” timer but thats fairly rare in my experience.


Something else I’ll mention is that I still find it valuable to use S2 security on any device that supports it.

Only 100kbps links without S2 enabled will support a full CRC checksum to ensure packet integrity. S2 enables full CRC checking for any speed.

A Motion sensor update packet in zwave is treated as is “if 0, no motion, if non zero, motion”. Without full CRC checksumming that “0” data value turning off motion could easily get corrupted. Now in this case (packet corrupted, fails CRC check, effectively it doesn’t arrive) the hub would still show the sensor as motion active, but my point is that you don’t want the data itself to corrupt the state either.

I posted this on the Hubitat forum not too long ago:
I am one of the pro-S2 people. I use S2 on any device that supports it with both HE and ST.

Biggest plus for me is that S2 enables full CRC checksums on all data. Without S2, only 100kbs links use CRCs. To me that solved the random errant sensor data or switch doing something weird.

One con is that updating firmware with S2 can be slow(er) or tricky to do. The built in zwave firmware update app still doesn’t work with S2 devices (no warning either, it just doesn’t work) so you need to use another method. I usually update firmware using PC controller as a workaround.

I don’t care about the actual “security” (ie encryption) aspects of S2. The increased reliability of message transfer is worth it to me.

Another con is that any devices associated to one another must be at the same security level. I never use device to device association.

S2 got a bad rap for a while due to S0’s poor implementation, worry about processing speed (500 and later chipsets can easily handle the encryption/decryption without a noticeable speed decrease), or lack of adoption by hubs (ST didn’t get solid S2 implementation until 2020 or later).

Just my 2c…


Very interesting! And I see now why people jump to a conclusion and say, “S2 eats up battery faster!” even though the benefits (probably) outweigh the disadvanntages.

It certainly makes sense. And the extra reliability is a definite plus. I’ve always tried to use S2 when available, but never really understood the advantages and disadvantages.

Thanks to you both for the enlightenment… :thinking:


S2 is a more efficient messaging protocol than S0: it should have longer battery life in most cases.

One other big factor for the S2 Protocol is that it makes use of a single-frame transmission, which is a massive improvement over the three-frame transmission used by the S0 Protocol. Simply put, single-frame transmission is significantly more efficient than three-frame transmission. The improvement in efficiency allows for extended battery life, enhanced reliability, and a huge cut-down on latency. This means that a device using S2 technology will require less maintenance, including fewer battery changes. It will provide more consistent performance, and experience shorter operation delays. This alone makes S2 vital for anyone looking to achieve the most efficient automation network possible.

Just remember that S2 and supervision aren’t the same thing. Supervision does require additional acknowledgment messages, so it might well use up battery faster. There are just a lot of variables.

1 Like