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

[Damon Hart-Davis]

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