Many of you know about what I’ve been spending my extra hours on recently - FlapDash, a desktop splitflap display! Reminiscent of old-timey train arrival boards, this fella will click and clack and spin, showing you the time or weather, messages from your friends, when the subway is showing up, and whatever you want to program yourself!
I think it’s about time for me to start building in public - so while we haven’t yet launched our kickstarter or website, I wanted to keep you all posted on what I’ve been learning and doing this week :).
How do all these devices talk to eachother??
Since we’re working with an overseas supplier on creating the hardware and firmware, I’ve been thinking a lot about how to design a system where the firmware on the device can be super lightweight and easy to implement, so the supplier and I don’t end up pissed off at each other. What I’ve aligned on is that every device should be able to be controlled entirely remotely; the device firmware just needs to know how to spin its motors to change the display to the right characters.
The backend for each device will tell it to do things like display these characters right now, and so the device doesn’t need code to display the time, the weather, sports games, or anything like that.
But as you can imagine, I was thinking this would be quite expensive. After all, hosting backend services can SUCK. And if I imagine this scaling to tens of thousands of devices, I’m worried this project will be more of a direct bank transfer from me to AWS.
mqtt
But it turns out there’s this super lightweight messaging protocol that’s been custom built for IoT devices. It’s called MQTT, and it’s incredibly simple: binary packets being tossed about; a 2-byte header compared to HTTP’s 32+ bytes, three Quality of Service levels for different reliability needs, and a hierarchical topic structure.
It’s really quite fancy. Whenever you get a new FlapDash device and connect to the internet for the first time, it’ll register on our backend and be issued a X.509 certificate. Those certificates will allow it to connect to our MQTT broker, which is AWS, and subscribe to two, custom, just-for-you feeds: device/{device_id}/{control, display}, as well as a number of custom feeds.
From then on, it’s connected 24/7, always listening to those feeds. Every now and then, it will receive a binary packet from the control feed saying something like, “Switch your display to time/est, and use the 24-hour-format.” Upon which the device will connect to that public feed being blasted out by our backend, and start receiving jsons like this:
{
“text”: “OCT 12th01:22 AM”,
“modes”: {
“24h”: “OCT 12th01:22 “,
“with_seconds”: “OCT 12th01:22:37”,
“24h_seconds”: “OCT 12th01:22:37”
},
“timestamp”: “2025-10-12T01:22:37.091259+00:00”,
“ttl”: 2,
“metadata”: {
“applet”: “multitimezoneapplet”,
“version”: “1.0”
}
}
It’ll start pulling the right data field; in this case data[“modes”][“24h”] and put that string on the screen.
In this parlance; my backend (and the time applet inside) is a publisher, and the device is a subscriber.
What’s really nice about MQTT truly is there’s a three-dimensional decoupling of publishers and subscribers. Space decoupling means devices don’t need to know each other’s addresses or even existence. Time decoupling allows messages to be stored and delivered when recipients reconnect. Synchronization decoupling enables asynchronous operation so publishers never block waiting for subscribers. This architecture naturally supports the one-to-many and many-to-one communication patterns essential for IoT, where thousands of sensors might feed a single analytics platform, or one cloud service broadcasts commands to an entire device fleet.
I was worried that the costs of the backend would force us to do a subscription model (ugh, I hate those). But based on what AWS is telling me, a 24h, 365 live connection for 1 device would cost me only 4 cents a year, and sending 1 json to a device every second over that year would cost me another 3 cents. Yay!!
I spent this week getting this all set up and working (double yay!!). Now, I get to do the fun bit; making a bunch of tiny little applets!
We’re hoping to get FlapDash out sometime next year. Cheers!