Work — Case study
Private home automation, with one honest tradeoff.
A residential installation: Home Assistant running in Docker on a local workstation, controlling the house without a smart-home cloud in the loop — and one deliberate exception, stated plainly.
The setup
Home Assistant Core in an isolated Docker container on a local machine. Configuration, state history, and automation rules all live on local disk. Lights, schedules, and routines evaluate in milliseconds on-premises: if the internet is down, the house still works.
The engineering decision worth reading
The house has a professionally monitored security panel, and there were two ways to connect it:
- A.A voice-assistant SDK bridge. Simple and it worked — but it’s a one-way command gate: it can arm and disarm, and sees nothing. No door states, no motion, no sensor health.
- B.A community integration for the panel vendor’s service. Full telemetry — every sensor becomes a local entity Home Assistant can automate on. The honest catch: it reaches those sensors by polling the vendor’s cloud service, because that’s the only interface the panel exposes.
We chose B, and we chose it with eyes open: sensor telemetry for this panel flows through the vendor’s cloud, while everything else in the house stays local. That’s the difference between marketing and engineering — “100% local” would have been a nicer sentence, and it would have been false. Local-first means knowing exactly where your exceptions are.
What it caught
With per-sensor telemetry flowing, the system flagged a failing battery in a window sensor — the kind of quiet fault that otherwise surfaces as a dead zone in your security coverage months later. A small catch, but it’s the pattern that matters: local automation watching local hardware, reporting to the person who owns it.