The Flow That Wasn't Broken

I run my house on Home Assistant and Homey together, wired up with about a dozen MCP servers so Claude can actually read state and call services instead of me copy-pasting YAML back and forth. This week I asked it a plain question: "any fixes we need to make for the actual homey or home assistant?" What came back was a good demonstration of the difference between an agent that reports what a diagnostic tool says and one that checks.

Homey's own flow checker flagged one automation as broken — "Weekend Wakeup Light," a flow that turns on the bedroom lights off an alarm trigger. Broken automations are common enough that I'd have believed it and moved on. Instead of taking the checker's word, Claude pulled the actual flow definition and cross-referenced the alarm ID it pointed to against the live list of alarms. They matched exactly, alarm still enabled. The flow wasn't broken. Homey's checker was reporting a stale cache — something we'd apparently hit before, which the model remembered and flagged as a known quirk rather than a new problem. That's a small thing, but it's the difference between "the tool says X" and "X is actually true," and it's the failure mode I'd expect most people, human or AI, to skip past under time pressure.

The real bug was smaller and easier to miss: a Shelly Gen4 plug's energy sensor, tracked in kWh, that would periodically report nonsense because the plug's onboard counter resets on certain events and Home Assistant's default sensor doesn't handle that gracefully. The fix was a corrected template sensor with state_class: total_increasing, which tells HA's long-term statistics engine to treat counter resets as resets instead of as data. Wrote it to templates.yaml, reloaded the template integration live (no restart needed), and confirmed the new entity was reporting sane numbers within seconds. Small, contained, verifiable — the kind of fix where you can watch the before-and-after state directly.

Then it found a Bluetooth adapter issue: two host radios stuck in forced-passive scanning mode instead of Auto, which matters because passive scanning misses advertisement packets from low-power BLE devices. It went into HA's Bluetooth integration UI, switched both host adapters to Auto, and verified the change stuck. There was a third scanner in play, though — an ESPHome Bluetooth proxy sitting in the bedroom, relaying signals from a Govee air quality sensor, a Govee under-bed sensor, and my toothbrush. That one's also on Passive, and fixing it the same way would mean editing that device's YAML and pushing an OTA reflash. Claude flagged the option, explained the tradeoff, and stopped — it didn't make the change. I hadn't confirmed I wanted that risk, and a bad OTA push to a device physically taped under a mattress is a genuinely annoying thing to have to go fix in person. When I asked later "is the proxy good now," the answer wasn't "yes, fixed" — it was "the two host adapters are fixed, this one's still on Passive, here's why it's working fine anyway, and here's what changing it would actually require." That's a more useful answer than a clean "done," even though it's a less satisfying one.

The generalizable point isn't about smart homes. It's that verification and reporting are different jobs, and an agent that treats a diagnostic's output as ground truth is only as reliable as that diagnostic. The valuable behavior here was checking live state against the claim in three different places — the "broken" flow, the sensor fix, and the proxy — and giving three different answers: false alarm, fixed and confirmed, and correctly left alone pending my say-so. If it had handled all three the same way — either blindly trusting every red flag or blindly fixing everything it technically could — at least one of those would have been wrong. Knowing which one is what building this against real infrastructure, instead of a demo, actually gets you.