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

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 address 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.

Postscript

Note that for the OpenTRV trial in north London over the winter of 2016--2017 we did indeed tunnel secure frames directly from TRV1(.5) valves to a cloud server via our REV10 'boiler controller'. The REV10 relayed the frames over GSM (2G) once the REV10 had authenticated the frames inbound from the local 868MHz ISM radio, to avoid some potential mischief. The relay did not re-encrypt those frames, but forwarded them bit-for-bit. Note also that at rest on the cloud server the frames remained encrypted, and the keys were never in the cloud, for maximum security. To process them for analysis we brought them off-line to decrypt and crunch.

The 128-bit AES-GCM encryption of the secure frames was evaluated to be secure enough to protect the data in-flight across the mobile phone network and the Internet. That will not be true for more sensitive data and/or several years hence.

In short, the "stuff encrypted at the leaf and that tunnels though the concentrator" model is clearly workable, even with a relatively puny MCU/CPU in the concentrator, in the case of the REV10 the same 1MHz CPU clock ATMega328P as in the valves! It is still good to authenticate the traffic before relaying it to prevent bad actors injecting bogus frames into metered traffic, and thus running up large bills with it, or DDoSing the central server via the relays.

Secure Frame Content

Sample of newer JSON log messages from secure OpenTRV nodes (ie using AES-GCM protected frames):

[ "2017-08-17T17:30:38Z", "", {"@":"91ACF3CFF388D4E0","+":12,"tS|C":0,"vC|%":4140,"gE":0} ]
[ "2017-08-17T17:30:53Z", "", {"@":"E091B7DC8FEDC7A9","+":4,"T|C16":383,"H|%":64,"O":1} ]
[ "2017-08-17T17:30:59Z", "", {"@":"FEDA88A08188E083","+":6,"vC|%":626,"gE":0} ]
[ "2017-08-17T17:31:24Z", "", {"@":"96F0CED3B4E690E8","+":13,"tS|C":0,"vC|%":934,"gE":0} ]
[ "2017-08-17T17:31:27Z", "", {"@":"FA97A8A7B7D2D3B6","+":8,"L":55,"T|C16":367,"H|%":64} ]
[ "2017-08-17T17:31:36Z", "", {"@":"91ACF3CFF388D4E0","+":13,"L":175,"T|C16":388,"H|%":61} ]
[ "2017-08-17T17:32:08Z", "", {"@":"819C99B4B9BD84BB","+":5,"vac|h":255,"B|cV":257} ]
[ "2017-08-17T17:32:20Z", "", {"@":"95ABDC89C1999C9E","+":9,"O":1,"tT|C":6,"tS|C":0} ]
[ "2017-08-17T17:32:27Z", "", {"@":"FA97A8A7B7D2D3B6","+":9,"O":1,"vac|h":9,"B|cV":252} ]
[ "2017-08-17T17:32:34Z", "", {"@":"91ACF3CFF388D4E0","+":14,"O":1,"vac|h":9,"B|cV":254} ]