[OpenTRV-dev] QoS

[Bruno Girin]

On 26 February 2015 at 22:59, Bruno Girin <EMAIL ADDRESS HIDDEN> wrote:

>
>
> 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.
>

As soon as I sent this, I thought of something else. One option could also
be to do what the Reuters RRDP protocol used to do (and maybe still does)
for real-time information system: use a fire and forget mechanism with a
frame counter and the receiver would send a negative-ACK if it had missed
one or several frame; the sender would then re-send.

Now, if we talk about QoS in MQTT terms, I think QoS 0 (i.e. at most 1) is
fine for sensor data messages and QoS 1 (at least 1) is fine for actuator
messages as long as we design them so that receiving the same message twice
is not an issue. QoS 2 (exactly 1) is probably unnecessary.

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