Z-Wave the public standard

Repeated and Missing Events


I’m trying to understand how devices are supposed to behave and how they do behave.

I cannot find a specification for the state machine for the ZWave definition of a motion sensor, but I think that the normal states would be ‘motion detected’ (md) and ‘no motion detected’ (nmd), with two external event sources: movement and timeout. Starting in nmd, a movement event would change the state to md, spit out a CC message and a timeout event would have no effect, in md, a movement event would reset the timeout counter (without emitting any CC message) and a timeout would cause a transition to nmd, with a corresponding CC message. Is this correct/is there a specification in any of the documentation?

A characteristic of the above state machine is that it is not possible send multiple CC messages of the same value without an interleaved message of the opposite value.

I’ve got a small set of PIR motion sensors that are emitting CC Sensor Binary for motion detection and logging CC messages based on OpenZwave events received (Fibaro FGMS-001).

I am seeing the following behaviours that look odd at first glance:
1/ More than half of the CC messages detected are repeats occurring a short time (<1s) after a CC that could be emitted at a state transition.

2/ There are many instances of several messages of the same sense emitted over several minutes (8 in a row is the most, so far). These runs of CC messages are for both senses, ie, several motion detected events in a row with no intervening quiescence, and several ‘return to nmd’ CC messages with no intervening motion.

Should I expect to see these behaviours and if not, has anyone any hints as to where to find the cause? If the behaviours are to be expected, what is the best approach to handling them:

  • detect and log the anomalies and use the data to drive future device type buying
  • avoid making any assumptions about what ‘motion detection’ means
  • something else?

thanks in advance



Hi Tim,

A Z-Wave device is described in this document: http://zwavepublic.com/sites/default/files/command_class_specs_2017A/SDS11847-22%20Z-Wave%20Plus%20Device%20Type%20Specification.pdf.

A PIR sensor is described as a Sensor - Notification. More detailed operation of the device is described in the specific Command Classes: http://zwavepublic.com/sites/default/files/command_class_specs_2017A/SDS13781-4%20Z-Wave%20Application%20Command%20Class%20Specification.pdf.

The Notification CC is used to report binary events like motion detected. It however does not define how often a motion detected must be send. So you may see some variation in the configured timeout from md to nmd. Also a device may send md on a fix timeout interval while others may “just” send md and nmd.

If your application just needs to know md and nmd, I suggest you ignore the additional md frames.



Hi Carsten
Thanks for that. I’d been focused on SDS12657-12-Z-Wave-Command-Class-Specification-A-M.pdf, and SDS12652-13-Z-Wave-Command-Class-Specification-N-Z.pdf. And getting rather tangled in understanding the deprecation structure.

For background, I’m looking to build on the design that I was responsible for that is currently being deployed with a target size of ~10M homes, but using ZWave, rather than Zigbee as the networking protocol to sensors/actuators. Like the BG system, the usecase involves devices that are not monitored by people, and service quality/cost depends on spotting when devices or the network behave unexpectedly.

So I cannot assume that multiple similar messages mean anything significant, eg, that there’s a missing message. That’s a bit of a shame as it reduces the confidence in device/network monitoring.

If there’s no standard for behaviour, it also complicates device sourcing and use over time as I’d want to implement the same application using many different SKUs for the same device type.

Never mind, at least I now know better where I am.



Hi Carsten
I see that figs 20 and 21 in the second of those documents does describe at state machine much like the one that I had in mind - although for a smoke detector in the context of a flood sensor description - but that the figures only refer to a recommendation.

So I suppose that I’m going to need to check out ZWave protocol version compliance statements as part of sourcing.



Hi Tim,

Z-Wave is strong in the interoperability and backwards compatibility. But the Z-Wave specification has been developed and improved over 15 years. So this leaves a long tail of devices that will work on the network but may not comply with resent specification and recommendations. I am sure you can get devices that are compliant with latest spec, and work as you describe.

First step is to make sure that you are using Z-Wave+ devices. The Z-Wave Alliance introduces the “+” some years back, to improve the interoperability.

Also April this year the Z-Wave Alliance introduced a requirement for S2 security in all devices.

I suggest you contact Sigma Designs or the Z-Wave Alliance, if you need help finding the proper devices. If you already have a DevKit, you can contact Sigma support through http://zts.sigmadesigns.com. Otherwise you can contact Sigma Designs through http://z-wave.sigmadesigns.com/contact-sales/.