[OpenTRV-dev] Sending Arrays via OpenTRV protocol

[Bruno Girin]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20160503/1e3d7288/attachment.html>