[OpenTRV-dev] QoS

Damon Hart-Davis EMAIL ADDRESS HIDDEN
Thu Feb 26 16:24:47 GMT 2015


> Hi,

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

Good point.  For this I primarily was thinking of the local radio hop, yes, but you are also right that for QoS to be meaningful its scope may have to extend to the ‘Net part too.

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

Thanks for an excellent kick-off!

Rgds

Damon

> 
> Cheers,
> 
> Jeremy
> 
> On 26 February 2015 at 13:27, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:
> What Quality-of-Service support if any should we be considering in OpenTRV products and the IoT platform?
> 
> Rgds
> 
> Damon
> 



More information about the OpenTRV-dev mailing list