<div dir="ltr">Hi,<div><br></div><div>From an IP point of view you only really need to consider QoS for real time communications as you tend to build applications on TCP that guarantees packet delivery and hence most IoT applications a few ms or even seconds delay is not the end of the world. </div><div><br></div><div>Specifically for OpenTRV I guess you are more thinking in the radio domain. So, I assume, by QoS you are more talking about guaranteeing delivery of messages over the air rather than the typical IP meaning of QoS which is about prioritising one packet over another?</div><div><br></div><div>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?</div><div><br></div><div>Cheers,</div><div><br></div><div>Jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 February 2015 at 13:27, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What Quality-of-Service support if any should we be considering in OpenTRV products and the IoT platform?<br>
<br>
Rgds<br>
<br>
Damon<br>
_______________________________________________<br>
OpenTRV-dev mailing list<br>
<a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
<a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
</blockquote></div><br></div>