<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 26 February 2015 at 22:59, Bruno Girin <span dir="ltr"><<a href="mailto:brunogirin@gmail.com" target="_blank">brunogirin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 26 February 2015 at 16:24, Damon Hart-Davis <span dir="ltr"><<a href="mailto:dhd@exnet.com" target="_blank">dhd@exnet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>[snip]</span></blockquote><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>><br></span><div><span>
> 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?<br>
<br>
</span>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.<br>
<br>
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.<br></div></blockquote><div><br></div></span><div>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.<span class="HOEnZb"><font color="#888888"><br></font></span></div></div></div></div></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>Bruno</div><br></div><br></div></div>