How does Vera treat a battery device ?

Let’s say a battery TRV device is asleep and whilst it’s sleeping the controller processes several new temperature settings, let’s say 21c, 22c, 23c - none of which are able to be executed as the device is not awake.

When the battery device awakes, will Vera only send the most recent (as it’s clever and only the last one is required), or all three ?

Am hoping it’s the former, because the latter results in pointless traffic and may not even all be sent before the device falls back asleep.

Cheers

David

[quote=“dmckenna, post:1, topic:183524”]Let’s say a battery TRV device is asleep and whilst it’s sleeping the controller processes several new temperature settings, let’s say 21c, 22c, 23c - none of which are able to be executed as the device is not awake.

When the battery device awakes, will Vera only send the most recent (as it’s clever and only the last one is required), or all three ?

Am hoping it’s the former, because the latter results in pointless traffic and may not even all be sent before the device falls back asleep.

Cheers

David[/quote]

What device are you talking about? Usually VERA receives current temp info from a Battery temp sensor. I’m trying to think that battery sensor is receiving the temp.

I was talking about the Stella Z but to be honest it’s moreover the architecture of the Vera box that’s sub optimal.

I’ve subsequently tested and discovered that Vera queues up ALL temperature change requests and processes them all in turn. In a test lab condition this works fine, but because of the latency on the network with battery devices sleeping and Vera re-retrying the send/poll process, invariably on a large network the new temperature set change takes hours (or even days !!) to get to the device, if the system has sent a new set point in the meantime then this gets added to the end of the queue and processed in turn.

The better architecture would be for Vera to only store ONE setpoint change in the queue for battery devices - let’s face it a temp change is for this instant, you’re no longer interested in a previous setpoint change from hours back that the TRV wasn’t able to process because it was asleep.

Unless anyone has discovered a way of flushing the queue before a new send ?? Any LUUP code available perhaps ?

Ahhhhh Euro stuff.

I have a temp sensor that lets me set the reporting interval (like report every degree change, or time like every hour). It will wake up each time to report it in my case. It doesn’t wait for any particular time except if I set one.

EDIT: nevermind I see its for euro too.