I have a lot of stuff. Not in a hoarder way — in a “I’ve lived in this house for years and have accumulated tools, hardware, cables, and household supplies across a garage, an office, a basement, and several closets” way. Finding things was becoming a minor but persistent daily annoyance.

I’d already solved the cataloging side of the problem. I run Homebox — a self-hosted home inventory app — on my home lab server. Every item is labeled and assigned to a location. The database was there. The problem was retrieval. Opening the app, navigating to search, typing a query — functional, but slow. I wanted something faster. Something I could trigger while standing in the garage with my hands full.

My first instinct was voice. I tried Alexa routines, Google Assistant, a couple of third-party automation bridges. None of them played cleanly with a self-hosted API running on my local network. Eventually I stopped fighting the voice assistants and solved it the way I solve most things — by building it myself using the tools I already had running.

The end result is a pipeline. I tap a shortcut on my phone, a dialog box appears, I type what I’m looking for, and within a few seconds Sonos speaks the answer and a notification lands in my phone tray. It works whether I’m home on WiFi or connected remotely.

Every piece of that pipeline is something I was already running. No new subscriptions, no cloud dependencies added, no third-party accounts. The whole thing lives on hardware I control.

Before getting into how it works, here’s what’s involved and what each component does in context.

When I tap the shortcut, Tasker fires a task that immediately opens a native input dialog — a simple text box. I type what I’m looking for, tap OK, and the task packages my input into a request and sends it to a small Python service running continuously on my home server.

That service receives the search term, authenticates against Homebox, queries the inventory, and interprets the results. Based on how many matches come back, it builds a spoken response and fires it in two directions simultaneously: to Piper TTS (which renders it to audio and sends it to Sonos) and to Home Assistant (which pushes a notification to my phone tray).

The response varies based on what the search returns. Here’s what each outcome looks and sounds like in practice:

One of the more interesting design decisions was handling broad searches gracefully. If I type “cable” I might have thirty items that match. A long list read aloud on Sonos isn’t useful — and Piper TTS will quietly drop responses that are too long anyway.

When results exceed a threshold, the server signals back to the phone with a specific response code instead of a spoken result. Tasker reads that code, recognizes it as a “too many results” state, and re-opens the input dialog automatically. No error message, no failed state — just a second chance to be more specific.

Getting the pipeline functional took longer than the architecture would suggest. The issues were almost entirely in the middle layer — specifically in how Tasker handles variables and HTTP requests. A few things worth documenting for anyone who tries something similar.

This is a small-scale problem with a small-scale solution. But it’s a good example of the kind of thing I find satisfying about running your own infrastructure.

There’s no subscription. No account to log into. No privacy policy to agree to. No cloud service that might deprecate the feature or change the terms. The whole thing runs on hardware I own, software I control, and a network I operate. If something breaks, I fix it. If I want to change how it works, I change it.

If you’re running Homebox and want to build something similar, every piece here is open-source or free: Homebox, Home Assistant, Tasker, Piper TTS, and a Linux server to tie it together. The architecture isn’t complicated. The tricky parts are in the Tasker variable handling — which is now documented above so neither of us has to rediscover them.