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

Updated 2024-05-16.
MQTT, JSON, UCUM: OpenTRV archival data format, radio/wire comms format, and other issues.
Discussion and decisions over IRC including that it is not necessary to send all fields from each leaf (ie for all its sensors) each time; and send infrequently-changing values less often.

Some items up for discussion:

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 .

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.


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} ]


(Count: 1)