Over the past few years, I’ve added a fair amount of smart home technology to my house. Among other things, it allows me to control lights and outlets, monitor the status of various appliances, measure my electricity and water usage, and even shut off the water supply in the event of a leak. All of this technology is coordinated through a hub that I originally accessed through a traditional browser-based interface. But scrolling and clicking through screens to find the display or setting I wanted is a) slow and b) boring. I wanted an interface that was quick and fun—a physical control panel with displays and buttons.
Something like the control room in the nuclear power plant in the 1979s The China Syndrome. I was about 10 years old when I saw the movie, and my overwhelming thought while watching Jack Lemmon try to stave off a nervous breakdown was, “Boy, those panels look cool!” So they became my guiding light for this design.
Before I could get into the aesthetic elements, however, I needed to consider how my panel would handle inputs and outputs and communicate with the systems in my home. The devices in my home are connected through the open source Home Assistant platform. By using an open source platform, I don’t have to worry about suddenly not being able to turn on my lights due to, say, a forced upgrade to a proprietary system, or wondering if someone in the cloud is monitoring the activity in my home.
At the heart of my Home Assistant setup is a hub powered by an old PC running Linux. This manages the wireless connections with my sensors, home appliances and other devices. For off-the-shelf devices – like my energy meter – this communication is usually done via Z-Wave. My home-built devices are connected to the GPIO pins of a Raspberry Pi, which relays their status over WiFi using the MQTT standard Internet of Things protocol. However, I opted for a wired Ethernet connection between the control panel and my hub PC, as this would allow me to use Power over Ethernet (PoE) to power the control 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 cards (D), and an emergency stop switch (E). James Provost
In fact, I use two Ethernet connections because I decided to split the functionality of the control panel between two Raspberry Pis Model 3B+, each costing about $35 (see my GitHub repository for a full parts list). One Pi drives a touchscreen display, while the other controls the buttons and LEDs. Each is equipped with an additional $20 PoE “hat” to draw power from its Ethernet connection.
To control all the buttons and LEDs, over 50 I/O signals are required, more than a Pi’s GPIO header can accommodate. Although this header has 40 pins, in practice only about 26 of them are usable, so I used three $6 I2C expanders, each of which can handle 16 I/O signals and route them back over a two-wire data bus.
I don’t have to worry about suddenly not being able to turn on my lights because of a forced upgrade.
The software that controls each Pi is also functionally separated. It does this 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 that fetches a graphical display from the Home Assistant hub. A second container runs a Python script that 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 at this local server instead of the hub, the screen displays internal diagnostic information useful for troubleshooting.
The other Pi has two containers running Python scripts. One processes all keystrokes and sends commands to the hub. The other requests status information from the hub and updates all LEDs accordingly.
Input and output functions are distributed across software containers running on the panel’s Raspberry Pis, which communicate with a hub to send commands and retrieve status updates. James Provost
These containers run on BalenaOS, an operating system designed to run these sandboxes on edge and embedded devices like the Pi. Full disclosure: I’m the Edge AI Enablement Lead for Balena, the company responsible for BalenaOS, but I’ve been using the OS since before I joined the company because of its container-based approach. You can run Docker containers with the Raspberry Pi operating system, but BalenaOS makes it easy to manage containers, including starting, stopping, and updating them remotely.
You might think that this software infrastructure is overkill when it’s just reading the status of a few buttons and flashing some lights, but I like containers because they let me work on a subsystem without worrying about the impact on 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 the various indicators are mounted in a series of 3D printed control panels. I first sketched these out full size on paper and then created the 3D print files in TinkerCAD. The labels for each control, as well as a diagram of my house’s plumbing, were printed as indentations in each segment and then filled with white putty for contrast. I then mounted the array of control panels in a commercially available $45 “floater” frame.
By a small miracle of the maker’s mind, the panel segments and frame all fit together nicely on the first try. I mounted the finished panel in a hallway of my house, to the slight amusement of my family. But I don’t mind: If I ever have a water leak, I can press the big emergency button to shut off the main valve with the aplomb of Jack Lemmon trying to prevent a nuclear meltdown!
