I originally bought the Raspberry Pi to play with Pi-hole. That was the plan, at least. I wanted to see how DNS filtering worked and get a better feel for what was happening on my network.
Then I started using the Pi for other things. I was SSH-ing into it to check the off-site storage, looking at backup jobs, and trying to remember which machine was running which service. Every time I found another useful command, I thought, “I should put that on the dashboard.”
The information I cared about was spread across the Pi, the NAS, the media server, and the backup drive. I could check each piece, but there was no quick answer to the basic questions:
– Is anything broken right now?
– Did the backups really finish?
– Is the hard drive healthy?
– What are the GPUs doing when nobody is using them?
I wanted a local page that answered those questions without opening five SSH sessions.
The first version was just a status page. It showed CPU load, memory, storage, temperature, and uptime. From there I added SMART checks for the drive, Docker status, network discovery, backup comparisons, and Jellyfin information.
The part I kept coming back to was the GPUs in the NAS. NVIDIA can report the current draw through `nvidia-smi`, so the Pi collects a reading over SSH and stores the samples locally. Those samples become watt-hours over time. The dashboard then estimates a cost using the local electricity tiers.
It is deliberately an estimate. It tells me what the GPU boards are using; it does not pretend to be a whole-home power meter. Being explicit about that turned out to matter more than making the number look precise.
I also added a longer view for the energy data. I can switch between a day, seven days, thirty days, a year, or three years and see the energy, average draw, peak draw, coverage, and a low-to-high cost range. A missing reading is shown as a gap instead of quietly becoming a zero.
I used AI like a second pair of eyes while I was building this. It helped me break down ideas, look for security problems, write the first pass of small collectors, and think through what would happen if a service stopped responding.
It was not always right. I had to test everything on the actual Pi and the actual network. One of the better examples was a GPU failure that looked like an SSH problem. The connection was fine. My restricted SSH key was returning eleven CSV fields while the parser expected twelve, so the dashboard threw the valid row away. Finding that kind of mistake was part of the project.
The security work grew out of the same process. Credentials moved out of the application folder, the dashboard data moved into internal storage, root-only checks were separated from the web service, and the GPU keys were limited to a single command. The external drive is used for NAS backups only; it is not the dashboard’s database or history folder.
The Pi is now the place I go when I want a quick read on the homelab. It shows the current state, keeps history for the things I care about, and tells me when the data itself is stale. It is still a personal project and it still has rough edges, but it is much more useful than the Pi-hole experiment I started with.
The main lesson for me was that adding a feature is easy. Knowing whether the feature is giving me trustworthy information is the harder part. That is what made the project interesting.
