[OpenTRV-dev] QoS

[Bruno Girin]

On 26 February 2015 at 16:24, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:

> [snip]



> >
> > With that in mind as far as I understand most of the communications in
> OpenTRV are just fire and forget, there is no confirmations that the other
> end got the message. So adding QoS would entail defining a back channel for
> confirmations and some form of retry if no confirmation is received. So I
> think the question is are there any communications in the OpenTRV system
> that are worth the extra power consumption and effort of adding this?
>
> Well, it is highly desirable to get (esp two way) comms reliable (a friend
> was moaning about the unreliability of parts of his home automation last
> night), and with reliability at whatever level is necessary there then
> comes the possiblity of for example turning down radios as far as possible
> and avoiding sending multiple message copies without compromising that
> level, which may be different for different parts of the traffic BTW, thus
> conserving battery and bandwidth.
>
> It may indeed be that we need none of this new-fangled QoS nonsense, but
> we might, and I’d like to continue to explore that.
>

I'd say it depends on the message as Jeremy suggests. For messages like
sensor data, it doesn't matter too much if some messages are delayed or
even lost. For instructions for the actuators (e.g. open valve, fire
boiler, etc), it may be more important to ensure they get delivered, at
least the initial one to ensure that the user gets immediate feedback.

Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20150226/5b6d7994/attachment.html>