Logbook

homelab principles

My homelab principles:

One Pi, one project. Limit the number of things you want to mess with. Dedicate hardware to each.

Don't ever build anything that depends on an SD card lasting until tomorrow.

If you get bored with a project, re-image the media and repurpose the hardware to something new.

Don't be shy about using computers that are too slow for the task. You'll get to see error messages that other people only experience at scale.

homelab inventory, October 2023

The relevant bits of my homelab, for reference, prompted by a series of threads on Mastodon.

The basic idea is that I have a bunch of low power computers and I'll run one project on each of them. This means that if something goes horribly wrong - or if I get bored - it's easy to start over from scratch without interfering with something else.

All of these are on a Tailscale network, and currently they are all at home in the attic.

Pi Zero running MMDVM and pi-star as a DMR radio access point and hot spot. There is a newer version of the pi-star console available in a fork, and newer MMDVM code, but this gets treated more or less as an appliance.

Pi 3 running the PiAware stack from Flightaware, as a ADS-B 1090 MHz airplane location decoder. This setup needs a better antenna as I am not hearing as many airplanes as I think I should.

Pi 400 running OpenWebRX plugged into an Airspy HF+ SDR and Youloop antenna, decoding FT8 and tuning AM/FM/HF/VHF. This setup could use a faster computer - right now 2 cores run at 100% every FT8 cycle. This is the likely upgrade path for the Pi 5 I have on order.

Pi 4 running Home Assistant. I want to understand Home Assistant better and actually have it control bits of the house - or at least just some things in the attic. For now though it has been quite stable.

Pi 4 running "honk", a tiny ActivityPub server. I'm on an old version of honk, and I'd like to rebuild this setup from scratch so that I can start running a current or latest version of the code.

Pi 2, currently idle. I suspect it would be plenty fast to run pi-hole, a custom DNS resolver.

And a list of projects that I'd like to do:

A RISC-V machine, for grins. I bought a motherboard back in the day, but it arrived so delayed that I missed the holiday window that I was going to hack on it.

A Github or gitea runner, plumbed into Home Assistant in some way, so that I can trigger automation based on git activity.

An MQTT hub to feed Home Assistant. MQTT is a nice protocol for message passing, and mosquitto is small and runs on minimal hardware. Since I last looked, it appears that some standards for message formatting and channel naming have emerged.

Node-RED, to scratch the visual programming itch. I used this years ago and it's only gotten more capable.

A redo of my "honk" ActivityPub server, set up properly so that I can track latest rather than be stuck on an old version.

Maybe Proxmox running on arm64 as a test? It looks like there's an unofficial fork. If it's stable enough, that could give me some virtual machines to land little projects on.

A new ADS-B antenna for PiAware, ideally one that I build myself out of some parts I bought.

A faster machine (Pi 5?) for OpenWebRX or the OpenWebRX+ fork that supports even more radio protocols.

So many projects, so little time.

self-hosted monitoring with Uptime Kuma

"Uptime Kuma" is a self-hosted monitoring tool, which has a very nice design and which fits in a small memory and compute footprint. This makes it a good fit for household and homelab operations.

https://uptime.kuma.pet

I'm still figuring out a permanent home on my home network / tailnet for it, but for the moment I have it running on my laptop which means I get to see some relatively more frequent failure conditions as the network goes on and offline when I power down or move between locations.

"Uptime Kuma" can do the usual sorts of things you might want to do with a simple network monitor, including ping, DNS lookup, HTTP fetch, very simple pattern match on web pages, and the like. It won't let you run an arbitrary command on a schedule though, and the web site pattern matching happens without any parsing of the HTML page, so some fancy setups might be hard.

I'm currently using it to monitor network infrastructure like my home router and a few ATT systems on the traceroute path to the rest of the Internet. A separate dashboard watches to see that my PiAware ADS-B airplane monitor is getting good data; it wasn't when I started watching things, so there was a weekend side-quest to move the receiver to get a better view of the sky.

I haven't set up any active alerts or alarms yet. There are feeds into a bunch of systems including SMS, Home Assistant, Telegram, and Slack.

One of the virtues of Uptime Kuma is that the development community is very mindful of resource consumption, and things like memory leaks or inefficiencies that would prevent it from running on an old Pi or a free tier on a container service like https://fly.io have been fixed.

An alternative to this if you have more resources to throw at the task (and more features with it) is OneUptime which is also available as a hosted system. The open source version of OneUptime wants 8 cores (!) to run on, so that kind of ruled it out for my uses.

https://github.com/OneUptime/oneuptime

Another alternative is HealthChecks which drives the telemetry and monitoring with a Python and Django application. This too has a hosted free tier of service or can be run in your homelab self-hosted.

https://healthchecks.io

In truth my homelab setup (which is mostly a pile of Raspberry Pi systems) doesn't have much downtime, and even if it did the consequences would be minimal. Still it's nice to get a quick overview when everything is working, and some speedy look at where to go next if something isn't quite right.