Within a custom Device Handler, when you receive a notification from a battery operated Device (ex: SensorAlarmReport, WakeUpNotification), you have, or not, the opportunity to immediately send back to the Device some additional Command(s) using response().
But experimentally I discovered that after some Device notifications (ex: WakeUpNotification) the Device DOES wait for an answer from the Handler for some (limited, unknown) time, while for some other notifications (ex: SensorMultilevelReport), the Device returns IMMEDIATELY to sleep.
My question is : is this different behavior part of the Z-wave specification, is it applicable to all Z-wave compliant Devices, or is there no other way than trial & error to discover which Commands keep a given battery operated Device awaken (for a limited time) after a given notification, and which don’t ?.
Google and SmartThings documentation were no help (or I used the wrong keywords).
The z wave spec mandates the behavior of WakeupNotification for sleeping devices:
If no Wake Up No More Information Command is received from the Wake Up destination, the
node MUST respond to the Wake Up destination until 10 seconds have elapsed since the last
transmission or reception with the Wake Up destination.
[Reference: from the “Z-Wave Plus Role Type Specification”, version 24]
Thanks Tony, that is pretty clear. Does that mean that if you space by 1s a string of commands sent to the node/device in response to a WakeUpNotification, you cannot send back more than 10 commands before the node returns to sleep ?
Also, do you know of any other command class which awaits for an answer ?
@JDRoberts : thanks for the link, but again I must have searched with the wrong keywords and got no useful answer. Could you please zoom a bit on a pertinent section (I can further search from there, with the proper keywords)
My reading of the spec is that there has to be 10s idle (no messages sent or received)…
[Quoted spec above is from the “Z-Wave Plus Role Type Specification”, version 24]