DesignSpark Electrical Logolinkedin
Menu Search
Ask a Question

RS IoT Blockchain Demonstrators Part 6: GitHub Repository

Notes to accompany the project code published in full to GitHub.

This series of posts looks at the design and build of a set of demonstrators for the bi-annual Electronica trade fair and conference, which show how blockchain technology can be used to create a secure, decentralised data platform and more for the Internet of Things.

In previous posts, we’ve covered the mechanical and electronics build, following which creating a private blockchain network and deploying smart contracts and the Python software which integrates sensors and outputs and interacts with the smart contracts. This final post is to accompany the code which has now been published to GitHub in order to enable reuse in other projects.

Note that although it would be possible to faithfully recreate the demonstrators, it is not anticipated that anyone would, in fact, want to do this and as such this is not a comprehensive step-by-step guide. Rather instead a set of notes to assist in better understanding of how the code is put together and what would need to be adapted when reused in other projects.

If you haven’t already, it would help to read part 4 and part 5 from this series before proceeding.

Base dependencies

The Go Ethereum software, geth, will need to be available on each node and binary builds can be downloaded. A “Geth & Tools” release will be needed for the miner as these include the bootnode application also, which is used to provide a discovery node for the Ethereum network.

Each system in the network will need to have an Ethereum account configured.

Python 3 and pip3 will also be required on each system.

A small utility called ftee will need to be compiled from source and copied to /usr/local/bin.

The default paths are:

/opt/iotbc/bin/ - Python scripts

/opt/iotbc/etc/ - Config files

Network initialisation

The private blockchain network will need to be initialised via a custom genesis block as described in Part 4: Blockchain Network. This will require the addresses of the accounts created on each system since these will be preallocated funds during network initialisation.

The smart contract solidity code will also need to be updated with the appropriate Ethereum account addresses. Once this is done it can be compiled and deployed to the new private network using Truffle, assuming that the Ethereum node (geth) is running and the account configured has funds (these should have been preallocated at initialisation). As the smart contracts are deployed their addresses will be printed out and these will then need to be updated in the config.yml files.

Common configuration

The YAML configuration files used are in the GitHub repo. E.g. would simply be named config.yml and placed in /opt/iotbc/etc/ on the Crash Crash demonstrator. At the very least the following parameters would need to be updated:

  • boot_node - enode URL will be specific to the actual boot node IP address and key

  • account - the address of the locally configured Ethereum account

  • contract - the address for that demonstrator smart contract (emitted upon deployment when running truffle migrate)

The Car Crash system, for example, would also need the CarCrashABI.json file to be in the same directory, with the other use cases requiring their associated ABI file to be in the etc/ directory.

The /opt/iotbc/bin/ directory on all systems would contain the following Python scripts:

  • buttons

  • eth-leds

  • eth-node

These are common to all systems and configured as appropriate by role, e.g. “miner” or “carcrash”. Note that Intel NUC hardware is assumed for the miner and Raspberry Pi 3 B+ for the other systems. If using other hardware platforms, or other GPIOs, the scripts will need to be modified.

All systems will require the following Python libraries to be installed via pip3:

  • paho-mqtt

  • PyYAML

  • pyzmq

  • web3


In addition to running the aforementioned three Python scripts, the miner will also need to run an Ethereum boot node. The enode URL for this will then need to be set in each config.yml file.

The Mosquitto MQTT broker (or some other broker) will also need to be installed.

Car Crash

This demonstrator uses the Accel Click module accelerometer and 8x8 Click module LED matrix. These require the Python smbus-cffi and luma.led_matrix libraries, which can be installed via pip3.

Leak Killer

Since this demonstrator uses Adafruit Dotstar addressable LEDs, it will be necessary to get the Python module sources, patch them for Python 3, compile and then copy to the /opt/iotbc/bin/ directory.

Machine Failure

This uses the DesignSpark.Pmod library.

Temperature Alert

This uses the DesignSpark.Pmod library.


Systemd unit files are also available on GitHub to enable starting applications at boot time.

Note that on all nodes but the miner, the eth-node.service file should be modified to remove the Requires= line altogether, and to remove from the After= line the units, eth-bootnode.service and mqtt-broker.service.

Final notes

The way the Python scripts evolved the use of Zero MQ has ended up being more complex than it likely needs to be, but the solution used seemed to work well and this could easily be re-factored. At the same time there could also be less duplication across scripts, with common elements moved out into a separate Python helper module. The config file format could likely also be improved upon.

Andrew Back

Open source (hardware and software!) advocate, Treasurer and Director of the Free and Open Source Silicon Foundation, organiser of Wuthering Bytes technology festival and founder of the Open Source Hardware User Group.

2 Jan 2019, 8:37