ie
If I Send a new SetPoint to the Secure RT321 (Heating Thermostat) to 22C and the the target devices is asleep - ie on a 15 minutes wake up schedule, how does Homey cache the instructions until the device is awake?
At the moment the instruction send just seems to fail.
Is there something in config somewhere to deal with battery powered devices?
I have searched the Forum - but unable to find an answer.
When sending changes to a battery powered device you must (almost) always wake-up that device just before pressing “save” or “send”. That is the only way to be sure the changes are really applied.
For the record: waking up is not the same as activating a sensor (fi trigger motion or open/close a door). You must press the include/wake button manually according to the instructions of the device.
That is not completely right. If commands are sent to a battery-powered device and the device sleeps, they will remain in a queue and will be sent to the device at the next automatic wackeup.
If that were not the case, you would have to wake up the thermostat each time the device when you send new temperature.
This does not apply to FLIRs devices, here the changes are transferred immediately, since they have no Wackeup.
Of course, you can shorten the time by manually waking up the device.
Is there anyway of checking that Homey has actually waited for the device to wake and actually sent it?
In a Flow I just get a failure - I cannot se any queuing mechanism.
How do i check the Queue in Homey.
It is my Day 9 with Homey so still trying to figure out how it works.
The FLIRS I am very familiar with - I have 8 Spirits 
It is the Secure Thermostats I am interested in right now.
Ie a scenario - someone turns thermostat up to 28C I want to detect it and change it back to 22C and after 30 minutes set back to 20C.
At the moment the change to 22C just fails as the ZWave sender just times out - or appears to when it declares an error.
Sorry, you’re right, i missed the FLIR part… 
In that case indeed temp changes should be immediately applied.
But for other (advanced) settings it is still almost always necessary that the device is woken up (at least with Homey it is).
There are multiple thermostatic valves that don’t have flirs, they indeed wait until they are awake until they receive their new set value, this works on an letterbox principle, and they just ask homey if they have any new data for them (instead of just saying that it is awake).
Homey however has difficulty with parameters when the device is asleep for longer then 30 minutes or so, and then either forgets to send the value, or just purges its queue.
This doesn’t work according this letterbox principle, which is probably why it fails sending the parameters sometimes.
There is no way to see the queue, so kinda hard to say for real what is going on.
But in general is it better to have the device awake just before you send the updated settings to the device to be sure it receives them.
Mmm I am seeing a lot of failures setting setpoint on Secure RT321’s.
Need to spend some time looking into whether it is just reporting failures and still getting through to the thermostats, which as I recall report to the controller every 15 mins.
I’ll read up on them and see if I can find a better way, need to work out how to get them to mesh as they are all working point to point with Homey and not using the mesh of all the other zwave devices around them.
