[OpenTRV-dev] Sending Arrays via OpenTRV protocol

[Bruno Girin]

On 3 May 2016 at 20:54, Damon Hart-Davis <dhd at exnet.com> wrote:

> Hmm, interesting.
>
> Two minor thoughts:
>
>  1) What about t.1 rather than t/1?
>

Yes, or that. Any format that makes it easy to produce and parse.



>
>  2) How does any particular node which format (array vs individual) to use?
>

The idea would be to hard-code at the leaf node depending on the sensors it
has, thus keeping it as simple as possible for the leaf. E.g. basic code
would have single value (like today) and you'd compile in an "array"
extension for leaf nodes that have multiple sensors of the same type.

The hub can then detect an array when receiving a frame by checking whether
the first non-space character is an opening bracket '['. JSON parsers will
do that automatically and you can then check whether the type of the value
is a list or not.


> Rgds
>
> Damon
>
>
> > On 3 May 2016, at 20:44, Bruno Girin <brunogirin at gmail.com> wrote:
> >
> > Jeremy,
> >
> > There's always the option to do a mix of both by manipulating the key
> name, e.g.:
> >
> > send all temp values: { "t|C16": [288, 296, 280] }
> > send second temp value: { "t/1|C16": 296 }
> >
> > Leaf nodes can then choose the easiest way for them to do it and the
> hub, which has the CPU power to do smart things, can deal with whatever is
> received.
> >
> > I've probably made your proposal a lot more complicated now :)
> >
> > Bruno
> >
> >
> > On 3 May 2016 at 20:05, Jeremy Poulter <jeremy at bigjungle.net> wrote:
> > I have been looking at the Tx of multiple temp values. As far as I can
> see there are two options;
> >
> > 1) send each value with a separate JSON key. This has the advantage of
> fitting in with the current architecture, will only send each value when
> changed (could also be a downside depending on the use case) and will also
> filter down to EmonCMS a bit easier. On the down side it will take a lot
> more bytes to send a full set of temp values (and multiple frames?) and
> probably need more memory from the AVR to track the values.
> >
> > 2) send an array of values in the JSON. Probably the more correct way of
> doing it from a JSON POV and a smaller total message size, however there
> are several downsides. This would be a lot more work as the simple stats
> code would need changing to support values of types other than int, namely
> an array of ints. There will probably be issues if the array size exceeds
> the 32 bytes (IIRC) frame size, in practice limiting the size of the array
> to 4 values. It could get really complicated to only send the changed
> values so in effect you would need to send all the values all the time.
> >
> > Let me know your thoughts.
> >
> > Jeremy
> >
> > _______________________________________________
> > OpenTRV-dev mailing list
> > OpenTRV-dev at lists.opentrv.org.uk
> > http://lists.opentrv.org.uk/listinfo/opentrv-dev
> >
> >
> > _______________________________________________
> > OpenTRV-dev mailing list
> > OpenTRV-dev at lists.opentrv.org.uk
> > http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> 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/20160508/63a01ccf/attachment.html>