[OpenTRV-dev] I just added this to the data sets doc...

Bo Herrmannsen bo.herrmannsen at gmail.com
Tue Jun 23 09:38:37 BST 2015


that is excatly the reason behind my thought....

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...

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

2015-06-23 10:31 GMT+02:00 Damon Hart-Davis <dhd at exnet.com>:

> 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:
>
> http://www.earth.org.uk/OpenTRV-protocol-discussions-201411-1.html
>
> Rgds
>
> Damon
>
>
> > On 23 Jun 2015, at 09:24, Bo Herrmannsen <bo.herrmannsen at gmail.com>
> wrote:
> >
> > 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?
> >
> > 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...
> >
> > just a quick thought
> >
> > 2015-06-23 10:12 GMT+02:00 Damon Hart-Davis <dhd at exnet.com>:
> > Hi Y’All,
> >
> > 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.
> >
> >
> http://www.earth.org.uk/note-on-IoT-data-sets-and-processing.html#binshiftrep
> >
> > Any thoughts?
> >
> > Rgds
> >
> > Damon
> >
> >
> > 2015/06/22:
> > Bruno and Damon discussed the desirability of completely mechanical
> conversions
> > from JSON sensor units to UCUM/SenML units to minimise or eliminate magic
> > 'mappings' that require sophisticated developer time (in line with IBM
> > suggestions).  One particular issue that cam eup is being able to
> represent
> > value as integers (for brevity and to keep code small on the sensors)
> > and scale to integers for transit, when the natural scaling is a power
> of two,
> > eg temperatures from common sensors with four significant bits after the
> binary
> > point, ie that are currently being sent with units <code>|C16</code> for
> > "Celsius times 16".  Bruno was going to investigate.  One possible escape
> > hatch is with the Ki/Mi/Gi/Ti "special prefix symbols for powers of 2".
> > _______________________________________________
> > 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/20150623/0046ef6b/attachment.html>


More information about the OpenTRV-dev mailing list