<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 May 2016 at 20:54, 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">Hmm, interesting.<br>
<br>
Two minor thoughts:<br>
<br>
 1) What about t.1 rather than t/1?<br></blockquote><div><br></div><div>Yes, or that. Any format that makes it easy to produce and parse.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 2) How does any particular node which format (array vs individual) to use?<br></blockquote><div><br></div><div>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.<br><br>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.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Rgds<br>
<span class="HOEnZb"><font color="#888888"><br>
Damon<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> On 3 May 2016, at 20:44, Bruno Girin <<a href="mailto:brunogirin@gmail.com">brunogirin@gmail.com</a>> wrote:<br>
><br>
> Jeremy,<br>
><br>
> There's always the option to do a mix of both by manipulating the key name, e.g.:<br>
><br>
> send all temp values: { "t|C16": [288, 296, 280] }<br>
> send second temp value: { "t/1|C16": 296 }<br>
><br>
> 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.<br>
><br>
> I've probably made your proposal a lot more complicated now :)<br>
><br>
> Bruno<br>
><br>
><br>
> On 3 May 2016 at 20:05, Jeremy Poulter <<a href="mailto:jeremy@bigjungle.net">jeremy@bigjungle.net</a>> wrote:<br>
> I have been looking at the Tx of multiple temp values. As far as I can see there are two options;<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Let me know your thoughts.<br>
><br>
> Jeremy<br>
><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" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
><br>
><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" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
<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" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
</div></div></blockquote></div><br></div></div>