Over the last few years, I’ve added a fair amount of smart-home technology to my house. Among other things, I can control lights and outlets, monitor the status of various appliances, measure how much electricity and water I’m using, and even cut off the water supply in the event of a leak. All this technology is coordinated through a hub, which I originally accessed through a conventional browser-based interface. But scrolling and clicking through screens to find the reading or setting I want is a) slow and b) boring. I wanted an interface that was fast and fun—a physical control panel with displays and buttons.
Something like the control room in the nuclear power plant in 1979’s The China Syndrome. I was about 10 years old when I saw that movie, and my overwhelming thought while watching Jack Lemmon trying to avert a meltdown was, “Boy, those panels look neat!” So they became my North Star for this design.
Before I could work on the aesthetic elements, however, I had to consider how my panel was going to process inputs and outputs and communicate with the systems in my home. The devices in my home are tied together using the open source Home Assistant platform. Using an open source platform means I don’t have to worry that, for example, I suddenly won’t be able to turn on my lights due to a forced upgrade of a proprietary system, or wonder if someone in the cloud is monitoring the activity in my home.
The heart of my Home Assistant setup is a hub powered by an old PC running Linux. This handles wireless connections with my sensors, appliances, and other devices. For commercial off-the-shelf equipment—like my energy meter—this communication is typically via Z-Wave. My homebrew devices are connected to the GPIO pins of a Raspberry Pi, which relays their state via Wi-Fi using the MQTT standard protocol for the Internet of Things. However, I decided on a wired Ethernet connection between the control panel and my hub PC, as this would let me use Power over Ethernet (PoE) to supply electricity to the panel.
The different types of components used in the control panel include a touchscreen display [A], LED displays [B], Raspberry Pis [C], Power over Ethernet boards [D], and an emergency stop button [E]. James Provost
In fact, I use two Ethernet connections, because I decided to divide the functionality of the control panel across two model 3B+ Raspberry Pis, which cost about US $35 each (a complete bill of materials can be found on my GitHub repository). One Pi drives a touchscreen display, while the other handles the buttons and LEDs. Each is fitted with a $20 add-on PoE “hat” to draw power from its Ethernet connection.
Driving all the buttons and LEDs requires over 50 I/O signals, more than can be accommodated by the GPIO header found on a Pi. Although this header has 40 pins, only about 26 are usable in practice. So I used three $6 I2C expanders, each capable of handling 16 I/O signals and relaying them back via a two-wire data bus.
I don’t have to worry that I suddenly won’t be able to turn on my lights due to a forced upgrade.
The software that drives each Pi also has its functionality separated out. This is done using Docker containers: software environments that act as self-contained sandboxes. The Pi responsible for the touchscreen has three containers: One runs a browser in kiosk mode, which fetches a graphical display from the Home Assistant hub. A second container runs a Python script, which translates touchscreen inputs—such as pressing an icon for another information screen—into requests to the hub. A third container runs a local Web server: When the kiosk browser is pointed to this local server instead of the hub, the screen displays internal diagnostic information that is useful for troubleshooting.
The other Pi has two containers running Python scripts. One handles all the button inputs and sends commands to the hub. The other requests status information from the hub and updates all the LEDs accordingly.
Input and output functions are split across software containers running on the panel’s Raspberry Pis. These communicate with a hub to send commands and get status updates. James Provost
These containers run on top of BalenaOS, an operating system that’s designed for running these sandboxes on edge as well as embedded devices like the Pi. Full disclosure: I’m the edge AI enablement lead for Balena, the company responsible for BalenaOS, but I started using the operating system before I joined the company because of its container-based approach. You can run Docker containers using the Raspberry Pi OS, but BalenaOS makes it easier to manage containers, including starting, stopping, and updating them remotely.
You might think that this software infrastructure is overkill for simply reading the state of some buttons and illuminating some lights, but I like containers because they let me work on one subsystem without worrying about how it will affect the rest of the system: I can tinker with how button presses are sent to the hub without messing up the touchscreen.
The buttons and various displays are mounted in a set of 3D-printed panels. I first mapped these out, full size, on paper, and then created the 3D print files in TinkerCAD. The labels for each control, as well as a schematic of my home’s water pipes, were printed as indentations in each segment, and then I filled them with white spackle for contrast. I then mounted the array of panels in an off-the-shelf $45 “floater” frame.
By a small miracle of the maker spirits, the panel segments and the frame all fit together nicely on the first try. I mounted the finished panel in a hallway of my home, somewhat to the bemusement of my family. But I don’t mind: If I ever have a water leak, I’ll get to press the big emergency button to shut off the main valve with all the aplomb of Jack Lemmon trying to stop a nuclear meltdown!