An advanced Raspberry PI story
I’ve been building some IoT (Internet of Things) devices based on microcontrollers. They talk to a MQTT hub to communicate their state. I want a mechanism where I am testing the devices separately from those already working in production, but in releasing them from test to production I don’t need to make code changes. My solution is separate VLAN and DNS infrastructure, all running on Raspberry PIs.
I’ve built a number of IoT devices based on Raspberry PI 3A devices. These included smart clocks and some surveillance cameras with PIR and temperature sensors. I moved these between environments using the automation tool Ansible. This allowed me to carefully control how production was configured and reproduce devices when I needed more or they failed, nothing lasts forever.
Even using Ansible has issues though as the production playbook can easily become different from the test playbook. Packages outside of my environment also change, and so later builds often fail. For the hobby “ops manager” this is an issue and has resulted in me loosing services for weeks until I get the time to diagnose the issues.
My current set of IoT device projects have taken the approach of using Microcontroller, and I have chosen to use the Raspberry PI Pico (RP2040) and ESP-01 to provide wifi. Development is in C and C++. The Pico is a great little microcontroller board, cheap and with good tool support. It works nicely alongside a RPI 4 as build, flashing and debug probe. My introduction course on setting up a C development environment is available on Udemy.
My development environment is a breadboard and RPI4. Breadboard connections and probes make it a fluid environment. Working designs get transformed into prototype devices on PCB. Often still with probe connections to allow me to reflash the software. At some point I want stable code and to run identical code in production as the final test version, without introducing issues in the release process.
My plan is to logically create a test network that has the same structure as my production network. So when a device looks up my MQTT hub in test or production, it can find the relevant MQTT host.

Physically I don’t want to have separate RPI for production and test for the DNS services. In fact I would like to reuse a pair of RPI already running freeradius in my network. So the DNS needs to logically connect to both the Test and production networks.

My plan is to use freeradius to dynamically allocate VLAN to a wifi enabled device based on MAC address. To configure a RPI4 running Ubuntu to connect to multiple VLANS via the physical ethernet connection. To run multiple instances of DNSMasq on the RPI4 to provide different DNS lookups on each of the VLANS.
In Part 2 I will talk about VLAN connection from a RPI4 and building Ansible automation to configure this.
In Part 3 I will talk about DNSMasq configuration in running multiple instances on a single host and building Ansible automation to configure this.
In Part 4 I will talk about dynamic allocation of VLAN based on MAC addresses. Using freeradius and Unifi Controller and Wifi Access Points.

2 thoughts on “IOT promotion to Production without code changes – Part 1 ”