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

[Damon Hart-Davis]

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