[OpenTRV-dev] QoS

[Jeremy Poulter]

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.

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?

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
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20150226/be33fc1a/attachment.html>