<div dir="ltr">that is excatly the reason behind my thought.... <div><br></div><div>the 2 units in my living room have 2 programmed periods and when i change battery the time goes bad... so if they could get the time from the unit at the hot water it would make life a bit more easy...</div><div><br></div><div>ultimately this translates in to me being lazy and dont want to open 2 boxes each time i have to change battery--- ie open battery box and change battery and screw it together again... then open the opentrv box to set time correct</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-23 10:31 GMT+02:00 Damon Hart-Davis <span dir="ltr"><<a href="mailto:dhd@exnet.com" target="_blank">dhd@exnet.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The leaf nodes are not expected to maintain or transmit accurate time: the concentrator node adds timestamps.  See here, item 3 in the Decisions section:<br>
<br>
<a href="http://www.earth.org.uk/OpenTRV-protocol-discussions-201411-1.html" rel="noreferrer" target="_blank">http://www.earth.org.uk/OpenTRV-protocol-discussions-201411-1.html</a><br>
<br>
Rgds<br>
<br>
Damon<br>
<br>
<br>
> On 23 Jun 2015, at 09:24, Bo Herrmannsen <<a href="mailto:bo.herrmannsen@gmail.com">bo.herrmannsen@gmail.com</a>> wrote:<br>
><br>
> btw... and not related to JSON... but could a time stamp of some sorts be put in so that one unit can be the master clock for the others?<br>
><br>
> Since my unit at the hotwater cylinder is mains powered and the rest on battery it would be nice to just replace battery and they listen for the time from the DHW unit...<br>
><br>
> just a quick thought<br>
><br>
> 2015-06-23 10:12 GMT+02:00 Damon Hart-Davis <<a href="mailto:dhd@exnet.com">dhd@exnet.com</a>>:<br>
> Hi Y’All,<br>
><br>
> Bruno and I were having a discussion yesterday afternoon about how properly to represent for *JSON* transmission values with units that can be automatically translated to SenML/UCUM units, that are easy for an MCU to generate (eg no floating point if possible), that remain human readable and reasonably compact, and that deal with values whose natural representation is with some power-of-2 multiplier to capture all the significant (binary) digits with minimal bloat in the decimal int expansion.<br>
><br>
> <a href="http://www.earth.org.uk/note-on-IoT-data-sets-and-processing.html#binshiftrep" rel="noreferrer" target="_blank">http://www.earth.org.uk/note-on-IoT-data-sets-and-processing.html#binshiftrep</a><br>
><br>
> Any thoughts?<br>
><br>
> Rgds<br>
><br>
> Damon<br>
><br>
><br>
> 2015/06/22:<br>
> Bruno and Damon discussed the desirability of completely mechanical conversions<br>
> from JSON sensor units to UCUM/SenML units to minimise or eliminate magic<br>
> 'mappings' that require sophisticated developer time (in line with IBM<br>
> suggestions).  One particular issue that cam eup is being able to represent<br>
> value as integers (for brevity and to keep code small on the sensors)<br>
> and scale to integers for transit, when the natural scaling is a power of two,<br>
> eg temperatures from common sensors with four significant bits after the binary<br>
> point, ie that are currently being sent with units <code>|C16</code> for<br>
> "Celsius times 16".  Bruno was going to investigate.  One possible escape<br>
> hatch is with the Ki/Mi/Gi/Ti "special prefix symbols for powers of 2".<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>
<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>
</blockquote></div><br></div>