Earth Notes: IoT Launchpad Project Deployment (2016)

Updated 2022-09-19.
Field notes and data from IoT Launchpad project deployment activities. #IoT #deployment
Deployment of technology and devices for the IoT Launchpad project. This also links to public data and other data collected as part of the project.

The end of the deployment phase is March 2016.

Launchpad "Smart City" Deployment

Deployments in the "smart city" vertical, ie urban-scale, not in-building.

Bus-shelter-related deployment notes and observations (newest first):

Launchpad In-Building Deployment

Deployments in-building at up to campus-scale. Covering building health (cf "sick building syndrome") and related applications, such as reduction of fuel poverty.


Testing of our building-level radio technology at the top-end of its expected scale, in a district heating research project, to test and push the boundaries. This is mid-level between "smart home" and "smart city".

Note also that COHEAT has experienced a number of post-power-brownout problems. These suggest that Flash is getting corrupted, even the bootloaders, effectively bricking the devices since ICP/SPI is not brought to a connector. Internet research suggests that even with on-aboard BOD (Brown-Out Detection) AVR Flash in common with others may be vulnerable to full or partial erasure of Flash pages, including in the bootloader. Learning:

Separately we (OpenTRV) have noticed that programming (bootloading) the Flash may be unreliable from batteries (~2.4V) even if apparently within spec. Learning:

  • Best practice is to ensure a stable (3.3V+), possibly bench, power supply when bootloading.

Social Housing

As part of the general theme of making buildings work better, we expanded the 'building-health' vertical to include our social housing work. (One of OpenTRV's KPIs is improving the health in 'fuel poor' homes.) Amongst other things that generated a lightweight variant of our concentrator which is an authenticating secure relay from local (ISM) over cellular (GSM).

  • 20151219: lightweight relay / half-concentrator (relaying stats from sensors over ISM onwards over UDP over GSM/cellular) is running on a REV10 coexisting with a boiler hub; all in AVR land, no RPi required.


2016-03-03: an MQTT outbound gateway has been added to the Java concentrator, allowing relatively easy delivery into a number of other systems, eg including Open Energy Monitor and

Concluding Notes on D22

The project initially hoped to perform a significant refactoring of the concentrator code using the Kura runtime in order to make it more modular. In addition the hope was to enable interoperability with the likes of Open Energy Monitor and OpenHAB. The complexity of getting Kura to work, the heavy reliance of available examples on knowledge about the OSGi framework and some internal issues with obtaining a wired internet connection in the EnergyDeck offices, meant that this avenue of investigation was abandoned.

Instead, the interoperability workshop conducted with Open Energy Monitor on the 18th February suggested that a more lightweight option could be pursued, which is what the project team did. The project team delivered the following components:

  1. A MQTT handler that fits in the current Java code base and is able to send OpenTRV frames over MQTT, thus making it possible for any MQTT-enabled devices, like the OEM emonhub component (
  2. A MQTT-HTTP bridge that can forward OpenTRV frames to an online data platform such as EnergyDeck, using the SenML industry standard (

The interoperability workshop also suggested that a possible way forward for the concentrator code could be to contribute OpenTRV plugin components to the Open Energy Monitor emonhub project and use that as a concentrator, rather than come up with a different implementation.

See also How to install the OpenTRV concentrator code on a Raspberry Pi

Concluding Notes on D35Da

The project delivered three components for the data feed part of the project:

  1. The MQTT-HTTP bridge component mentioned in D22 that would run on the concentrator.
  2. A platform proof-of-concept component that can receive data from the bridge in SenML format and that can provide the data out again using the Hypercat standard ( for catalogues and SenML for time series data.
  3. Some library code shared by both components and responsible for serializing and deserializing data according to the SenML and Hypercat standards.

The platform and bridge components implement a simple commissioning process that makes it possible to deploy concentrator code with minimal configuration. This initial proof of concept for auto-commissioning offers many opportunities and could be extended with a number of options, such as:

  • prevent re-commissioning, thus forcing the concentrator to remember the commissioning parameters
  • exchange security keys to enable data signing for step 5, if connection is over HTTPS
  • enable the platform to request configuration changes of for the device to notify the platform of such changes (in a way similar to TR-069)
  • enable the platform to deliver software updates to the concentrator or leaf nodes in a way similar to TR-069

Security Components

Various security elements based on existing well-understood and peer-reviewed technologies have been developed and extended for IoT by OpenTRV. Some of these elements are indicated here.

Code Release

V1.0.0 code release of the key components at the end of the project:

  1. OTProtocolCC 1.0.0 COHEAT protocol support.
  2. OTAESGCM 1.0.0 AES-GCM crypto support.
  3. OTRadioLink 1.0.0 radio and V0p2 board support.
  4. OpenTRV 1.0.0 release against underlying libraries.