Earth Notes: OpenTRV Protocol Discussions Part 1 (2014-11)

Some items up for discussion:

• Text for rapid development and for less technical users (makers and the Arduino target audience) and allowing introduction of new keys units and values at will without breaking tolerant receivers, vs compact hand-crafted binary for production by engineers.
• Energy/size/duty-cycle/bandwidth constraints of low-power leaf nodes and radio modules.
• Handling of authentication and encryption where needed.
• Pairing, key exchange other shared secrets and entropy.
• OpenTRV current single sliding security sensitivity scale, eg 'calling for heat' low sensitivity, temp medium, occupancy high.
• Making it easy for non-experts and experts to get security right by default.
• Node IDs (variable length prefixes of 64-bit binary value, compatible with FS20!
• Current FS20 carrier, misuse by DHD, and FS20 wire format.
• Mike S's protocol.
• Other possible carriers such as DECT, ISM GSFK, etc.
• Use of third-party backhaul eg Neul, SigFox, GSM telemetry.
• Very low bandwidth or expensive channels such as HF.
• Radio restrictions/availability elsewhere in EU on ISM.
• Leaf-to-node terseness vs expansion at node, timestamping, etc.
• Generic IoT vs OpenTRV use.
• Not sending all parameters all of the time; to save bandwidth, stay within max frame length, reflect changes (with periodic refresh).
• Two-way comms, actuators, over-the-air updates, etc.
• Making data easy to publish in repositories such as Xively, Thingful, etc.
• Alphabet soup of some candidate technologies: MQTT, MQTT-SN, JSON, BSON, Hyper/Cat, ...
• (Courtesy of Tim Small): send node type info (I am a Vendor X, ID Y, standard type 42 sensor) once (or occasionally to help concentrator and downstream know what it is getting.
• For units, what about using the UCUM codes? http://unitsofmeasure.org/trac/ ?
• JSON and binary format frames with Mike's MAC can probably be 50+ bytes and work with current typical 64-byte radio module buffers.

See the IRC transcript for the session of the evening of 2014-11-13.

Some decisions from the IRC chat:

1. [Decision] TinyHAN MAC should be preferred local RF MAC layer for OpenTRV and the generic sensor platform ...
2. ... and we will use it to support JSON-/Mike-/binary- format frames (Mike format draft spec: Mike's copy and local copy filed 2014-11-13).
3. [Decision] All full timestamps at and beyond the concentrator (leaf nodes need not timestamp their messages at all) in sensible unambiguous ISO-8601 UTC showing the 'Z' timezone to be clear not local time (Can be displayed in local timezone as required)
4. ... and with variable precision from just years down to many decimals of seconds as appropriate to the data, ie truncated on the right, with years always 4-digit; week notation also allowed.

Some issues touched on and/or to be discussed next time:

• Format for the concentrator upwards, including for long-term persistent storage, use of MQTT, JSON with UCUM, etc.
• Security between leaf and concentrator, and beyond, including stuff encrypted at the leaf and that tunnels though the concentrator, ie that it cannot decode.

Postscript

As of 2018 we are fairly content with our use of JSON and something close to UCUM for over-the-air real-time data and long-term storage, and secure enough (AES-GCM protected) frames to be safely tunnelable through a data relay and across the Internet, at least for now!