[OpenTRV-dev] Wire formats from low-power sensor leaf nodes to more powerful upstream (concentrator) node

[Bruno Girin]

Hi,

With regards to binary formats, what about using BSON? http://bsonspec.org/

Bruno


On 19 October 2014 16:42, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:

> Hi,
>
> I’m quite sure that I don’t know enough and haven’t read enough to make
> the right choices yet, but yes xAP seems to be in the right ballpack though
> possibly still a bit verbose/heavy for this purpose.
>
> Thanks for the link: I’m reading!
>
> Rgds
>
> Damon
>
>
> On 19 Oct 2014, at 16:38, Stuart Poulton <EMAIL ADDRESS HIDDEN> wrote:
>
> > Damon,
> >
> > I’m sure you’ve already looked at existing alternatives, but a lot of
> what you are trying to achieve sounds very similar to the goals of the xAP
> protocol that I was involved with in ~2002, the current protocol
> specification can be found here.
> >
> > http://www.xapautomation.org/index.php?title=Protocol_definition
> >
> > I’m sure you’ll find some useful hints and pointers within the above.
> >
> > Stuart
> >
> >
> > On 19 Oct 2014, at 16:04, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:
> >
> >> To be clear; from the concentrator onwards some more standard
> protocols/formats would be preferable; I’m really only trying to minimise
> the pain of the first hop from a low-power sensor.
> >>
> >> Eg the concentrator could act as an MQTT proxy (what sort of heresy and
> ignorance am I indulging in here).
> >>
> >> Rgds
> >>
> >> Damon
> >>
> >> PS. The more I think about it the more I like the unique node ID plus a
> simple list/map of (name, scalar value) pairs with selectively signed or
> encrypted parts for the TEXT form.  The interpretation of a data frame
> depends on the node and concentrator IDs and timestamp.  But maybe I can be
> talked into JSON at least!
> >>
> >> On 19 Oct 2014, at 15:41, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:
> >>
> >>> Hi,
> >>>
> >>> Thinking out loud here, so not necessarily making sense…
> >>>
> >>> I’m trying to do ensure that when OpenTRV and/or any sensor platform
> based on it is sending data points from leaf/sensor/actuator nodes to a
> more powerful concentrator node there are a couple of possible mechanisms
> with the following features:
> >>>
> >>> 1) TEXT: The ability to instantly add arbitrary new sensor types’
> outputs to the data stream for quick development and without any predefined
> schema, and without blowing up an existing unupgraded receiver, and to be
> able to see what is going up the wire preferably (eg easy debugging and
> storage).  Maybe a node ID plus an ASCII (ASCII-7 printable only) list of
> name/value or name/value/units.  Syntax might be JSON or something even
> more terse.  Generating and sending extra bytes has a significant
> code-space and energy (eg CPU and radio) cost, but the ability to instantly
> add new values to a data stream in a robust way may make that worthwhile.
> Note that maximum frame sizes are likely to be very constrained by node
> memory, radio duty-cycle regs, etc.  Note that this form plus may with some
> decoration (eg with concentrator ID and timestamp) may be directly suitable
> for long-term storage and sending over the Internet.  Note that printable
> ASCII may eliminate the need to bit-stuff or whiten on some carriers.
> >>>
> >>> 2) BINARY: The ability to instead/also use a very compact binary wire
> form, eg once a particular set of sensors has been settled on for a
> particular deployment and available engineering skills can handle this.
> Logically equivalent to TEXT form but possibly hand-crafted for size/cost
> and robustness.  Should ideally be convertible to/from TEXT FORM freely at
> various places in the data path, with a tight version control of the schema
> expected.
> >>>
> >>> 3) The possibility in some cases of ‘signing’ some or all of the data
> points at the leaf or at the concentrator.
> >>>
> >>> 4) The reverse path to a leaf node (if present) should always support
> the BINARY option but may also support a limited subset of the TEXT form.
> >>>
> >>> Thoughts?
> >>>
> >>> If JSON were to be used, then surely some stylistic choices should be
> made, eg flat list/map with/without units?
> >>>
> >>> Damon
> >>
> >> _______________________________________________
> >> OpenTRV-dev mailing list
> >> EMAIL ADDRESS HIDDEN
> >> http://lists.opentrv.org.uk/listinfo/opentrv-dev
> >
> > _______________________________________________
> > OpenTRV-dev mailing list
> > EMAIL ADDRESS HIDDEN
> > http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> 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/20141020/36b00ef8/attachment-0001.html>