In this post we take a quick look at the gadgets featured during The Curve’s demo at our first in-person event that we hosted the other week as well as a few of the considerations that went into the design, build and software. As there are many misconceptions to the challenges and complexities involved in building and deploying IoT solutions, such as it requiring expensive hardware and bespoke software to match, we wanted to showcase how these challenges and misconceptions can be overcome.
An important element of our demo was that the hardware was largely “off the shelf” and “commodity” hardware either bought from a mainstream vendor in the UK or imported from China.
There are no bespoke/custom circuit boards here – nor any break out boards or other maker-style hardware – the world to an extent has moved beyond complex wiring and logic gates at this level – of course they exist in the chips and perhaps PCBs but for this demo, the only soldering was to wire up the motors on the pumps, and all the other wiring was simply done with wire cutters, crimps and screwdrivers – the skill today in similar application is, mostly (but not exclusively), more in code than electronics and engineering.
Another key point was limiting our use of WiFi and relying on other wireless technologies—most notably the ZigBee mesh protocol, which allows for a large number (50+) of devices to be connected without suffering the fragility of Wi-Fi and the risk of oversaturating a local access point.
Connectivity
Public and corporate networks often restrict traffic to only allow common and “safe” protocols like those used to browse the web. Even then, many use sophisticated firewalls to intercept the traffic and filter it based on the URL or contents.
As with many IoT deployments we did not want to rely on the venue’s WiFi, not only because they have a captive portal which does not often work with more primitive devices, but also because we did not know what limits or restrictions were in place for bandwidth, protocols or payloads.
We opted to bring an unnecessarily robust MikroTik NetMetal AX wireless access point retrofitted with a 4G modem to make it an Internet Gateway – this provided connectivity for all of our gadgets on show and the laptop running the front end.
The gateway has a ZigBee Coordinator connected to it that is central to the ZigBee mesh that was running at the venue as it sends and receives messages to the network with an MQTT broker as the intermediate communication layer.
The gateway provided a VPN tunnel back to our Office on the outskirts of the city centre where the broker and supporting services were running.
The MQTT broker securely exposed a TCP and Web Sockets endpoint over the internet with the latter available to the front-end React web UI.
This was our mesh network topology on the night:
The Buttons
Every attendee was provided with one of these ZigBee buttons along with their Curve lanyard and name badge with the purpose being that these buttons would simulate a large network of connected devices within the room.
The buttons primarily represented a simple input device – in this case they could report a single press, double press and long hold – meaning they could represent 3 proactive states.
Every press or action was reported to the coordinator through the mesh network and back to the MQTT broker.
From this we showed novel ways to consume the data including a “button cloud”, voting mechanism and a “fastest finger first” race.
Thermostats
During this part of the demo we wanted to highlight how IoT can empower the ability to collect data through sensors and devices, which can be retrofitted in scenarios where visibility is limited or may not exist. These challenging and unique scenarios are some of the reasons for the rise in IoT devices.
These straightforward and cost-effective ZigBee sensors measure temperature and humidity, sending it back over the mesh network for proactive monitoring and alerting – it’s that simple!
A flexible, easy retrofit and cost-effective way to monitor environments where temperature matters.
We recorded the temperature outside and inside the venue:
Power Comsumption
Power consumption is often a good proxy for device utilisation – this demo rig was designed to control and measure power consumption.
The wireless relay had 6 output channels – three controlled the feed to each socket respectively and three drove the green indicator lights. The wireless relay reported status back to the MQTT queue, via the gateway and over the internet, and received instructions via messages on the queue to control the three sockets and the three indicators.
We also showcased 5 different power monitors, all commodity ZigBee devices:
- Top left – a 3-phase, sealed unit with independent phase reporting through CT clamps with waterproof connectors.
- Top right – a single or dual phase DIN-mounted monitor with terminal connections for power and up to two CT clamps.
- Dead centre – a three phase compact unit where the CTs are built into the device requiring through-hole wiring.
- To the left – a single phase version of the 3-phase device to the right of it.
- Bottom middle – a DIN rail form factor monitor with external CT clamp.
We ultimately had 3 measures on 3 phases with two sets of measurements carried out by two 3-phase devices respectively.
The Power Monitors with screens were simply to verify the readings.
None of these devices cost more than £100 each and as they are mains powered they each act as a “Router” in the ZigBee mesh meaning that as well as reporting data and readings, they can extend the network by relaying the signal from other devices onwards… imagine a warehouse or office full of instrumented devices with such Routers – one Coordinator would be more than sufficient with the Routers adding 10-100 metres of coverage each time (depending on the building topology) allowing the signal to transcend floors or cells. No need for tens or hundreds of WiFi access points to provide fragile coverage!
When the frontend detected a non-zero load it triggered the green indicator light to flag utilisation.
The multiple inputs and outputs show how a more complex scenario could be instrumented – for example, across a factory floor, power utilisation of heavy machinery could be monitored in real-time providing operators and managers with the ability to track utilisation, detect and address downtime, and predict maintenance periods more effectively.
Drinks Mixer
This rig was arguably the most interesting and has the most real-world interactions and physical crossover, which arguably is the point of IoT – connecting with the “things”.
On the top right, we have a router-as-a-PCB – that is, a MikroTik router PCB board, purchasable as is for integration into an existing system or device. In this case, it is simply a (very robust) WiFi client.
On the top left – an Arduino Opta “PLC” – a microcontroller with 10 ADC inputs and 4 relay output as well as RS485 (modbus), ethernet and optionally WiFi.
In the middle, 3 peristaltic (think hospital drip) pumps.
And at the bottom, a load cell (stress sensing wires) connected to the orange case on the bottom right which contains a suitable ADC converter for the load cell feeding into a wireless micro controller (ESP32C6).
I bought the pumps for automating hot tub testing and dosing in (soon to be) regulated environments such as holiday lets, but they doubled up well as a cocktail maker.
The Opta is an interesting device with a modern programmable controller in a PLC form factor.
Ideally the load cell would feed into an ADC input to have a closed system for enforcing limits and failsafes, but for this use case they were de-coupled.
The Opta took MQTT messages to toggle the outputs alongside reporting its own status.
The ESP32C6 on the Load Cell reported any weight changes on to the MQTT bus.
The front end took input weights for each “ingredient” (vodka, tia maria and coke/pepsi) and cycled a basic statemachine of – take a tare reading, toggle a pump until weight – tare >= target, and move on, then repeat.
At least one audience member enjoyed a bespoke cocktail!
Design Points and Good Practice
As noted above, nearly all of the hardware as ‘off the shelf’:
- The desktop racks were from Amazon – a good find, but not cheap.
- We also had some 1U generic uPVC cases from RS that were not used in the end but very versatile.
- The Arduino Opta was from Farnell.
- The pumps – Amazon again, along with the load cell and orange case (from a set of 6 – 3 sized and 2 colours).
- The ESPs and relay board were imports – along with the current monitors, stats, buttons and other ZigBee devices.
- The power monitors, indicators and DIN rails – Amazon again – as well as the 1-4U mounting plates.
- The Wires, PSUs, connectors and crimps – Amazon as well!
- The MikroTik kit was from LinITX.
All of which was managed by our IoT platform (not actually showcased on the night)!
We have many defensive design principles that are employed on IoT projects – the most visible one here is that every device had a status LED of sorts, be it RGB, Tri-colour or just basic single colour. The application controlled that LED ensuring it faded, pulsed or flashed depending on the status – that gave us two critical data points – the first – what is going on (based on the sequence of the light), and the second, is the microcontroller running happily – if the sequenced halted, the controller likely did too – and that indicates a critical issue, and if not – then we know what the state is. Often a simple loop helps ensure we check connectivity and re-establish it if needed, all while visually indicating the current state of the device. Additionally, each device used a watchdog timer to ensure that if the processor halted the device would restart. And finally, each device reported home regularly over MQTT so we’d know if any went offline.
Each controller had a button that would stop any outputs – be it the power or the pumps – so if something went wrong we were not reliant on software or connectivity to intervene.
Observability is key, and recoverability is next – if those are in place, the application will likely survive most scenarios.
This whole demo was put together in under a week, with ~100 lines of code per device and worked on the night, as well as before and after, which shows how good defensive design in IoT can ensure operational robustness. The ease of the build was enabled by leveraging our existing technology and capabilities.
Tell us about your interesting IoT Project!