First, I haven’t posted here in quite a while, basically not since I began my new adventure into unraveling the outrage economy. I’ve shifted my focus from building tech systems to understanding the social systems driving us apart. As a result I haven’t been doing much tech stuff to write about here.
Secondly, I want to take full responsibility for my own woes that I will describe below. If anyone should know about proper backups and managing such, it should be me. It’s been a bit of a nightmare and cost me a good part of a week I could have spent on other things.
With that out of the way, I want to share a little adventure I had recently. Basically it all started with this little guy:
A failed SD Card.
But before we get to that, let’s take a walk through history.
Back in 2004, I had a problem. One day we accidentally left our garage door open and some stuff was stolen out of the garage. So we had this idea of a device that would close the doors after a time if that happened. That was the initial product requirement: a way to monitor the door status and close it after a time and to be able to adjust the timers or disable them. But then, of course there is scope creep.
I couldn’t find a commercial product that met my needs, one of those needs being to have a system that didn’t need the cloud or an outside service. Besides, I wanted to have some fun, so I build the first version of GarageBot.
This was built on a small embedded microprocessor platform called uCsimm (circa 1999):
The main “computer” was in the form factor of a 30-pin SIMM module. It sits in a baseboard with voltage regulator, connectors for ethernet and serial port and a small through-hole prototyping area. The uCsimm had a Motorola Dragonball (68EZ328) CPU, the same as in early Palm PDAs, 8 MB RAM, 2 MB Flash, a 10 MBit Ethernet controller, and a serial port. The whole boot, kernel, applications, and all files in 2MB (not GB) of flash. Those were the days. But the nice thing about this platform was that it had no hard drives, was very low power, and needed no fans.
I had to design and add the hardware to interface to the door sensors and control the garage door openers myself, along with a couple of LEDs that could give indications of what it was doing since it had no screen. The hardware was pretty basic, using the uCsimm SPI which is exposed via the 30-pin SIMM connector. The code was all in cross-compiled C which was really the only option on that small platform.
Since it had a net connection and full TCP/IP stack, I gave it APIs that allow it to be controlled and queried remotely over the net. And I even wrote an iOS app that could check status and open/close the doors.
That thing ran for 10+ years but the hardware finally died and while I could have replaced it with a spare, I decided to build the second generation garageBot. That was 2014.
Back then, the Raspberry Pi was pretty state of the art for this type of thing. The Raspberry Pi (Model B) of that era was priced at $35. It featured a 700 MHz single-core ARM processor (same family of CPU used in early smartphones, such as the original iPhone and early Android devices), 512 MB RAM, an SD card slot, an HDMI port, USB, and an Ethernet port, originally designed to teach kids basic programming. Quite a lot for $35.
In many ways, this was way overkill for what I needed, but pretty amazing for the price, and it would allow me to use a more modern real version of Linux. To provide the necessary hardware interfacing for the garage doors, there was the PiFace, an expansion board that plugs directly onto the 26-pin GPIO header of the Raspberry Pi Model B. It features 2 changeover relays, 4 tactile switches, 8 digital inputs, 8 open-collector outputs, and 8 LED indicators. Exactly what I needed. Here’s the PiFace and what the two boards look like sandwiched together:
And here’s the finished product in the case in the garage:
It’s about the size of a lightswitch wallplate.
In this version, since the PiFace interface had Python drivers, I rewrote the main GarageBot app in Python from the original C. It uses cherrypi for the webapp API. It’s a pretty simple app with just a few endpoints.
As I noted above, scope creep happens. In this case, I wanted to be able to have it interface with Apple Homekit to control the garage doors with the Apple Home app.
And I found just the thing to do so, Homebridge, an open-source server that emulates Apple’s HomeKit Accessory Protocol. It’s designed to run on a dedicated always-on server on your home network to connect smart devices that do not have native Apple HomeKit support into the Apple Home app and control them via Siri.
Homebridge purports to be a “lightweight” server, and in the end I guess it is, but it does have some heavy dependencies, especially when I had to get it all working on the original 2014 Debian 7 “wheezy” setup. It required jumping though quite a few hoops, but I did get it working on that old setup.
And it ran for a long time. And this takes us back to the SD Card.
Above, I noted that one of the things on the Raspberry Pi Model B was an SD card slot. In a Raspberry Pi setup, the SD card acts as the primary hard drive. Because the board lacks built-in internal storage, the SD card holds the entire operating system, boot instructions, applications, and personal files.
Using an SD card as a primary hard drive puts heavy strain on the card due to the fundamental differences between flash memory and traditional storage. First, there’s a finite life cycle. SD cards use NAND flash memory, which can only be written to a limited number of times before the storage cells degrade. Writing or erasing data physically wears down the microscopic insulation inside the memory cells.
A standard operating system (like Raspberry Pi Linux OS) is designed for mechanical hard drives or Solid State Drives (SSDs) with robust wear management. When run on an SD card, it accelerates degradation through things like log files, swap space, and caches.
According to AI, an SD Card used in this way may last only 1 to 5 years. The little dude pictured above lasted 10+ years.
You must write an operating system image (such as Raspberry Pi OS) to the SD card using a separate computer. One should also backup the SD Card periodically using a separate computer. And I thought I did that. But the only backup I could find was so old as to be worthless.
After trying to restore the contents of the failed SD Card and create a new bootable SD Card for the better part of three days, I finally gave up and just started over.
So this time, I decided to upgrade a little from the ancient 2014 “Wheezy” Linux version, but with the older, slower, original Pi with only 512MB of RAM, I didn’t want to go too far. I settled on a circa 2020 version code-named “Buster” (Debian 10).
This meant I could install newer versions of a lot of the dependencies I needed. One notable upgrade was Python 3 instead of Python 2, which required a few small tweaks to some of the Python code.
A lot of apt-get install, some manual installations with pip3, editing of configuration files, and systemctl goodness, and with some help from Google’s AI, I got the basic GarageBot server (without Homekit) running.
Than’s checkpoint one.
Next up was to get Homebridge running.
This requires Node.Js. I had to get the right version that would work with Buster and also work with Homebridge. Again, with some help from Google’s AI, I went with Node 11.15, which I installed manually from a tar ball.
Then there was installing homebridge itself using npm.
That was a chore. But after a few failed attempts, I was able to install version 1.6.1 successfully.
There is a cool plugin for homebridge for garage door control called homebridge-garagedoor-command.
From that point, there was quite a bit of tweaking code and configurations to get all the pieces to play nicely.
But I got it running, so far so good. This is what it looks like in the Apple Home app:
And it works with CarPlay too:
The last thing I did was enable log2ram and reduce log file maximums and log retention.
It’s been running for a few days. If it continues to be stable, I’ll button it all up and call it done for now.
Some Thoughts on AI
Google’s AI was surprisingly helpful in all this. I’ve been away from day to day software dev for some time now, so I used it a fair bit here. It seemed to have a good handle on the Raspberry PI, the PiFace, the various Linux Pi distributions, and details about revisions and version incompatibilities.
It knew about Homekit and Node.js on the Pi and had some helpful advice on compatibilities. This all would have taken a lot longer without the AI. It helps to have an idea of what to ask, a destination in mind, and the history of setting this all up before.
I never blindly copy and pasted a suggested command or config file change. Having many years experience with Unix and Linux environments of various stripes and software development environments, I had a decent understanding of what any suggested command actually did. There were a few times where I said “No, I’m not doing that” but the AI had surprisingly accurate details about the different platforms and tools, including the Mac OS side for examining and managing the SD Card and the Raspberry Pi / Linux side (and also setting up a virtual Linux environment on the Mac for accessing the ext4 file system on the SD Card, using UTM, not something one would normally have to do, but this was part of trying to recover from the failed SD Card).
I was particularly impressed with the detail to which it knew about Homebridge and the homebridge-garagedoor-command plugin I’m using. It made some detailed config file suggestions for the plugin for features I didn’t know existed and it might have taken me quite some time to discover.
And with a tool like log2ram that I’m not too familiar with, when I wanted to know the difference between something like the SIZE and LOG_DISK_SIZE parameters, it did a good job explaining their function.
Final Thoughts
One thing about a platform like this: when it just works, you don’t think about it too much. I haven’t touched the code or configuration in like five years.
There’s things like bit rot and skill atrophy that come into play.
The surrounding environment changes over time. Because we haven’t “exercised” the scripts, deployment pipelines, backups, or debugging tools, we are blind to whether those tools have quietly broken in the background (e.g. do you even have an SD Card reader/writer anymore).
In tech operations, there is an effect where the longer a piece of software runs flawlessly without intervention, the closer it gets to a catastrophic failure event because the team’s operational readiness to fix it drops to zero.
Companies like Netflix introduced chaos engineering to force operations teams to deliberately “exercise” their recovery tools and break things on purpose in production to guarantee that the safety nets and diagnostic tools still work when needed.
In my case, for this specific catastrophe, I need to make sure I have a backup image, and a way to find where it is. And of course a platform with an SD Card interface that can read/write SD Cards in a way that is compatible with the old Raspberry Pi.
A 2026 Version?
If I was going to set this up today on newer hardware, it would probably be the Raspberry Pi 4 Model B/1GB ($35) and the corresponding Raspberry Pi 5 Digital Input Output Expansion Board ($29). It looks like finding a case as elegant as the one I have with my current hardware is more of a challenge. For my application, a simple garage door controller that queries status and closes a relay, there’s no significant advantage of going through such an upgrade. In fact, there are a lot of reasons NOT to do that. It would mean rewriting the existing Python/PiFace code because the underlying GPIO management code and SPI handling is totally different with the Pi 4. The Pi 4 uses more power and runs substantially hotter. It typically requires passive metal heatsinks or a small fan setup. The biggest thing would be building or modifying a case to hold it all. I’m not looking forward to the day when events may require me to consider these options all over again.
And a Curmudgeon Gripe
Why does all this software, with each new version, get bigger and slower.