A few years back I decided to build a mobile sauna & pool with my brother. Although it may sound like a seriously non-digital asset, I ended up equipping it with a 4G connection, car-independent battery, 200W solar panel, led convenience lighting, temperature sensors, door locking indicators, GPS and a small internal display. Lights are controlled with proximity sensors inside the control cabinet, which also houses the display and a BaseN Spime Enabler v1 (SE1).
Initially the SE1 was running a local control loop reading all the sensors, pushing the data to the BaseN Platform and to the local display. From the Platform, it was then easy to see when the sauna or pool were ready to be enjoyed, using a mobile-optimized webpage.
Recently I decided to upgrade the sauna SE1 into a more powerful SE1.5, which is essentially the same BaseN IT5888 Modbus IO controller with a faster and more resourceful ARMv6 host. The main difference to the venerable iMX233 host is that the new combination can actually run a standard BaseN BPOE agent instance. At BaseN we’re already supplying far more powerful SE2 and even SE4 hardware, but when things are well adapted to the IT5888, it is often easier to make incremental lifecycle upgrades.
Now the interesting part of the new remote setup is that it supports our new SES (Spime Enablement Services) framework, meaning that all control and measurement logic can be deployed within our Spime Containers and dynamically run either locally or in a BaseN data center. As this is a small setup, me and our CTO decided that it’s a perfect SES demonstrator, after the nDrone.
The original IT5888 sauna design from 2014 separated all inputs (like the light switches) and outputs (like the local display) to be at the mercy of the local control loop, run in the iMX233. It is a Linux host, but with tiny amount of memory and low processing power, so reading the light switch registers, 1Wire temperature sensors and GPS, then pushing the data to the local display and to BaseN Platform consumed it almost entirely, meaning that switching on a light could take more than one second.
The new host is about 10x faster, so it easily runs our SES Remote Go -environment. Using modern Go language and libraries (compared to legacy SE1 Python) makes sensor and actuator integration much simpler and more elegant.
In SES, Remote is the container running close to sensors and actuators, and it is capable of millisecond-grade control loops. In our sauna demonstrator, it interfaces with all sensors, switches and the display, and runs a control loop that is always synchronized with the SES Sandbox in a BaseN data center. In older non-spime terminology, the Remote interfaces with the Physical Twin, while the Sandbox hosts the Digital one.
Building scalable spime environments requires careful planning and may seem complex in the beginning, but this will pay off significantly when managing the joint lifecycle millions of discrete devices and applications. The SES framework ensures that in future, no logic or piece of programming will be orphaned.
Missed the last nBlog? Read it here.