vibescoder
cd ..

Friday Fixes: Teaching the Homelab Where It Lives

·8 min read
homelabhome-automationself-hosteddebuggingproxmoxbuilding-in-public

I started with the kind of homelab hygiene task that sounds harmless right up until it touches every machine in the house.

The ThinkCentre had become the quiet center of the smart home. It runs Proxmox. Proxmox runs Home Assistant, Uptime Kuma, AdGuard, the dashboard, and the local agent router. The RTX 5090 workstation still does the heavy lifting, but the always-on box decides whether I can see the house, wake the workstation, and trust the alerts.

That made one question feel more urgent than it should have. If I reboot this little box, does the house come back cleanly?

The ThinkCentre reboot passed the first test

We started with the boring part. Boring is good.

Before rebooting, I checked Proxmox, the Home Assistant OS VM, disk, memory, and failed systemd units. Everything looked clean. The HAOS VM was running. The guest agent responded. The current Home Assistant address matched the new network.

Then I rebooted Proxmox.

It came back cleanly. SSH returned. Proxmox reported no failed units. The HAOS VM autostarted. The guest agent came back. Home Assistant took a moment to move from NOT_RUNNING to RUNNING, which is normal during startup, but it finished without drama.

That reboot also exposed the first piece of stale documentation. The homelab skill still pointed to the old Home Assistant VM address from the previous network. The live guest agent showed the current address, so I updated the skill documentation and pushed the fix. The next agent will not rediscover that fact the hard way.

Uptime Kuma was healthy but monitoring the wrong neighborhood

The next check was Uptime Kuma. At first, it looked missing.

I checked the main homelab host because the docs said Kuma lived there. It did not. No container. No service. No listener on the expected port.

The real Kuma instance lives in a Proxmox LXC on the ThinkCentre. Once I looked there, the service was fine. The container was healthy. The UI was reachable through an SSH tunnel. The Socket.io API accepted the stored credentials. All eleven monitors were active.

But active does not mean useful.

Several monitors still pointed at the old network. The same bug hit the Proxmox push scripts that feed Kuma disk, memory, swap, temperature, and Home Assistant supervisor health. They were pushing to the old Kuma address. After the reboot, every stale assumption showed up at once.

I updated the Kuma HTTP monitors to the current ThinkCentre service addresses. Then I updated the Proxmox /usr/local/bin/kuma-* push scripts to send heartbeats to the current Kuma LXC. I ran each push script manually and watched Kuma recover.

Ten monitors went green. One stayed red for a real reason: Home Assistant had no current backup. That is exactly the kind of red I want from a monitor.

Home Assistant learned how to wake the 5090 box

The old remote-start path depended on a Samsung SmartThings hub sending a Wake-on-LAN packet. That was one more thing to retire.

Home Assistant is a better place for that button. It is always on, it sits on the same LAN, and I already reach it from my phone. I enabled the wake_on_lan integration and added a Wake AI Workstation script that sends a magic packet to the workstation NIC.

Then we tested it.

The first test failed. I had to turn the workstation back on manually.

That sent us down the right diagnostic path. I confirmed the Home Assistant script fired. I captured the packet on the workstation while it was running. The packet reached the correct interface and contained the correct workstation MAC repeated in the payload. That proved Home Assistant, routing, broadcast, and the script were all fine.

The remaining problem lives below the OS. The current workstation is an ASUS ROG STRIX X870-I GAMING WIFI board with an Intel I226-V LAN interface. Linux reports Wake-on-LAN enabled, and I added a shutdown hook to reassert wol g during poweroff in case the driver or NetworkManager clears it late in shutdown.

It still did not wake from full poweroff.

That is annoying, but it is a useful kind of annoying. We now know the software path works. The remaining fix is almost certainly in firmware: PCIe wake, PME wake, ErP, deep sleep, or fast boot settings on the motherboard.

The router became part of the infrastructure

The stale Kuma and Home Assistant addresses made the real root cause obvious. Too many critical things depended on DHCP luck.

The router is a TP-Link BE800, and TP-Link calls DHCP reservations “Address Reservation.” The setting lives under the router’s advanced DHCP server controls. Once we confirmed the router supports it, we reserved the addresses that now count as infrastructure:

  • The AI workstation
  • The Proxmox host
  • The Home Assistant VM
  • The Kuma, AdGuard, dashboard, and local agent router containers
  • Both Spark cluster nodes
  • The Mac mini that should not float around the network either

The Spark nodes were worth calling out separately. Their private high-speed fabric addresses do not belong in the router. Those are direct node-to-node links. Only their LAN-facing interfaces need router reservations.

After the reservations were in place, I verified the live MAC and IP pairs from the machines themselves. The router table matched reality.

That is the point where a homelab starts feeling less like a pile of devices and more like infrastructure.

Home Assistant still remembered the old house

The last cleanup pass focused on Home Assistant itself.

The HA instance had moved from one location to another. Anything tied to the old x.x.86.x network was stale by definition. I audited the registries and found two broken integrations still pointing at old addresses:

  • An Elgato Key Light Air named Cambria Office
  • A TP-Link HS100 plug named Bedroom Lights

Both were in setup retry. Both pointed at the old network. Their entities were unavailable or disabled. I removed the stale config entries, device records, and entity records with backups in place.

Then I found the quieter kind of stale state. Two Sonos device registry records still had old configuration URLs. They were not broken integrations, but they were still old-location references. I removed those stale URLs too.

One cleanup pass broke Home Assistant startup because I scrubbed old IP strings too aggressively from auth metadata. That was the kind of mistake that makes you glad you backed up the storage files first. I restored the auth file, removed only the stale refresh-token records that referenced the old network, repaired the device registry schema, and started Home Assistant again.

The final check was clean. Home Assistant was running. The live registry files no longer contained the old network. Backup files still do, by design, because backups should preserve what they backed up.

The fix was not one fix

This session looked like housekeeping. It ended up touching almost every layer of the homelab:

  • Power control moved from SmartThings to Home Assistant.
  • Monitoring moved from “service is up” to “service is watching the right addresses.”
  • DHCP moved from best effort to reserved infrastructure.
  • Home Assistant stopped carrying stale devices from the old location.
  • Documentation caught up with the actual topology.

The funniest part is that the only thing still unresolved is the thing that looked simplest. Send magic packet. Wake computer. Done.

The packet works. The workstation does not wake yet. That means the next fix probably happens in BIOS, not YAML.

I will take that trade. I would rather have one clear firmware problem than ten invisible network assumptions waiting for the next reboot.

By the Numbers

  • 1 Proxmox reboot - the ThinkCentre came back cleanly with no failed systemd units.
  • 1 Home Assistant Wake-on-LAN script - Wake AI Workstation now lives in the HA UI and mobile app.
  • 11 Kuma monitors checked - ten returned green after the address cleanup, and one stayed red for a real Home Assistant backup advisory.
  • 10 DHCP reservations - the critical homelab devices now have stable router assignments.
  • 2 stale HA integrations removed - the old Elgato Key Light and TP-Link HS100 entries no longer point at the previous network.
  • 2 stale Sonos URLs scrubbed - old-location device registry metadata no longer references the previous subnet.
  • 0 live old-network references - the active Home Assistant auth, config entry, entity, and device registries no longer contain the stale x.x.86.x network.

Comments