Earth Notes: OpenTRV Protocol Discussions 2014/11 Part 2

OpenTRV data format, wire format, and other issues.

Some items up for discussion:

  • 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.
  • Investigate hub/leaf 'pairing' further, eg based on the radios turned down low and/or LED+photosensor and/or strange button pattern following the simple Bluetooth pairing schemes such as for headsets.
  • Consider associating unique long-lived possibly-routable IPv6 addr with each concentrator and use it as the unique concentrator ID.

Sample of logged current JSON messages from OpenTRV leaf nodes, using JSON libraries at Arduino/leaf and Java/server ends:

[ "2014-11-27T19:18:45Z", "", {"@":"819c","T|C16":163,"L":24,"B|cV":256} ]
[ "2014-11-27T19:22:45Z", "", {"@":"819c","T|C16":163,"L":7,"B|cV":256} ]
[ "2014-11-27T19:26:45Z", "", {"@":"819c","T|C16":162,"L":7,"B|cV":256} ]
[ "2014-11-27T19:49:42Z", "", {"@":"cdfb","T|C16":292,"H|%":86,"L":255,"B|cV":256} ]
[ "2014-11-27T19:54:46Z", "", {"@":"819c","T|C16":159,"L":31,"B|cV":256} ]

See the IRC transcript for the session of the evening of 2014/11/27.

Some decisions from the IRC chat:

  1. [Decision] It is not necessary to send all fields (key/value pairs) from each leaf (ie for all its sensors) each time; especially it makes sense to send infrequently-changing values less often (and nominally support a set of fields much larger than one frame) to save some bandwidth and provide more flexibility, especially for less-efficient encodings such as JSON.

(2017/04/17: added/updated links.)