@Tyler looking for a little insight on how ST uses configure() for sleep devices in DH’s.
Sleepy devices basically respond to command in a wakeUp cycle. From the documentation on capabilities I’m able to gleam that configure() is called after the device inclusion is complete. The question I have, is the device ready to receive commands just after pairing is completed (is it sending a NIF at this point?) and configure is called or does one need to wait for the next wakeUp to send it commands?
Tagging @dkirker who can provide an explanation for you.
some people include a refresh button in their code which calls configure.
It doesn’t work that way for sleepy devices. They only respond during a wake up and NIF. @dkirker any insight into my original question would be helpful.
Hey,
So, some devices pair fast and are ready to receive configuration when we send configure(). Sometimes, however, this doesn’t always happen. We’ve seen devices (I think some of the Monoprice z-wave sensors) go to sleep quickly. I believe this also happened with Aeon sensors. Any device I have worked on I have made sure to re-work the configure logic so that all configuration is actually done in the wakeUpNotification period. A good example is the Aeon Multi Gen5 code https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/smartthings/aeon-multisensor-gen5.src/aeon-multisensor-gen5.groovy as well as the Aeon Multi 6. A better way to indicate “configured” would be to retrieve the set configuration parameters and compare them with what is expected.
Ultimately, I never rely on post-pairing configure() to be successful because the device may have already gone to sleep, or might have been mid way through a secure join when our platform sends configure(). For sleepy devices I always recommend taking advantage of WakeUpNotification. There is the added benefit that one can re-configure a device by following the instructions from the device’s manual. (So, say the device paired and immediately went to sleep without configuring properly – with pressing the button to wake it up, it will immediately receive the configuration as well. This is also useful for making sure that a device receives updated configuration parameters.)
Hope this provides a little insight.
That’s what I have also been seeing and thank you for the confirmation. So technically, on safe side one shouldn’t implement configure for sleepy devices.
One additional clarification. In a wake up command can one issue multiple response(zwave…) commands and if so is there any limitation or restriction or guideline? Reason being I’m building a unified DH (eg Monoprice new and old sensors behave and configure differently) and I want to make decisions based on MSR. For that first I need the MSR so I’m trying to issue a MSR request in wake up, delay it a bit until the response is complete and then decide what to configure and send the commands/verify. I’m am unable to get more than one response() to work
Is it not possible to force the wake up command from the DTH so it will take other commands?
No, wake up is a device initiated command (which is why it’s called sleepy devices otherwise it would fall into the category of a active or beamable device) however the wake up period can be configured by the DH when the device is “listening”
Do you mean you can configure it while it’s awake or that you can configure how long it stays awake? At the moment, I’m specifically playing around with the Aeon recessed door sensor and I don’t see anything that controls wake up. For that one, either you get 10 minutes of awake time on inclusion or you get a whopping 10 seconds if you hold the button down for a bit. And that seems fairly common from other things I’ve been playing with. Clearly I’m missing something. 
I’d appreciate any pointers immensely!!
A bit of both. First you need to realize that you may not always have access to the device in when configure is called.
Second you can define how often the device wakes up using the z-wave wakeup command class
Third you can determine to some extent how long the device stays awake, you need to tell the device when to do back to sleep but I believe if you don’t the device may eventually timeout and put itself back to sleep.
What you’re taking about is physical button initiation which is an external trigger
A little reading in the spec helps! So, if I get this right, on wake up, it will stay awake until 10 seconds after the last command or it’s issued the no more information command, right?
In the meantime, I could configure the wake up interval using the wake up interval set command. Is there a standard minimum or does that vary from device to device? It appears that there is supposed to be a min and max per the standard, but the only way to determine would be the wake up capabilities report right? As an example, for the recessed door contact, there is no mention of wake up interval min/max, just a battery check interval (with a minimum of 4 minutes) although it also refers to the wake up interval as it does a battery check on wake up anyway.
Could I theoretically set it to a shorter interval for some period of time to “do stuff” and then set it again at the end of the “stuff”? (Not seeing a real use case for this, just thinking out loud).
Thanks a ton for all the info! Already helps as I’m trying to get a better understanding.