Ten Years of Home Automation Alone. One Year With an Agent.

---

Ten years on, we are going to talk about home automation here again.

The last post on the subject is dated April 2016. A light sensor on an ESP8266, reporting into Jeedom. In between there was a 1970s house, and an installation that grew without a single line written about it here.

This time the subject is not the build. It is what AI changes in this field, seen from one specific case, mine. Not an enterprise pilot, not a trade-show demo. A family house and ten years of hobbyist habits.

The soldering-iron years

The first home automation post on this blog is from February 2014: driving Chacon mains sockets from a Raspberry Pi. Then an Ambilight on WS2801, then a second one on WS2812b driven by a Teensy. In 2016, six posts in a row on the ESP8266 — flashing it, wireless comms, an I2C display, a temperature probe, a light sensor, and a cat food dispenser.

All of it ran through Jeedom. Every sensor was a board to solder, a firmware to compile, a script to write. One build took a whole weekend, and I documented it the weekend after.

Then the house changed. Bought in 2019, one room renovated a year until 2025, with the installation moving to Home Assistant somewhere in the middle. Hardware followed the building work rather than the other way round. A shutter module when the bedroom was redone, a smart plug when the living room was opened up, thermometers when I wanted to know why the office was unlivable in August.

That method leaves a recognisable signature. The installation advances in bursts, at the pace of the renovation, and it drags along a list of things to do "when I have time". I still have that list.

What is in the house today

The raw device registry, this morning.

Behind those devices: 929 entities, 75 automations, 43 integrations, 14 declared rooms. The core of the fleet is Zigbee. The rest is a long tail that is not going away: a Somfy bridge that only speaks HomeKit, eight Wi-Fi bulbs from a Chinese vendor, an infrared remote for the workshop door, cameras on ONVIF, a three-phase Shelly meter, a text-to-speech engine in a container.

The broken parts belong in the inventory too, otherwise this is advertising. 250 entities out of 929 are currently unavailable or unknown. Most of that is expected. The Wi-Fi bulbs are switched off at the wall, and some devices are seasonal. The rest is debt I had never written down: duplicates left by old pairings, flat battery sensors, a shutter the Somfy bridge lost in August.

A ten-year home automation build is not a system. It is a sediment.

What changed, and by how much

Home Assistant timestamps automations created through its interface. The identifier is a Unix time. 42 of the 75 carry one. The other 33 come from YAML files and cannot be dated this way.

The ratio is twenty to one. It should be read for what it is: a measure of how fast things get created, not of value created. Twenty-two automations in a month is not twenty times better than one a month. Mostly it shows that a batch of subjects had been waiting a long time, and that they all went through at once.

What follows says more than the curve does.

Two speakers, one Wednesday

Two Sonos Era 100 delivered on 16 September. The next day they were in Home Assistant, named per room, attached to the living room and the bedroom, and wired into thirteen routine announcements.

It is not plug and play, and that is where the difference shows. The Sonos integration discovers nothing on its own. It subscribes to the SSDP component, which sweeps the network every ten minutes. Between creating the entry and the first entity appearing, nothing happens. Alone, I would have spent the evening suspecting broken multicast, then fallen back to a manual per-IP configuration — the wrong answer to a problem that did not exist.

I did not find that. The agent went and read the integration's source, saw that it only subscribes, and concluded we had to wait for the next sweep. The diagnosis took as long as asking the question.

The same build hit three more details of the same kind. The speech engine needs fr_FR rather than fr, or the server returns a 500. An announcement on a recent Sonos goes through a separate interface, so the speaker's reported state does not move while it is talking — I concluded three times that nothing was playing. And the announcement script, written before the hardware arrived, targeted guessed identifiers that never existed; a filter quietly made it harmless instead of raising an error.

None of these is hard. Each one costs an evening when you meet it alone, and there were four of them in the same build.

A door entry panel that talked to nobody

The street panel at the gate is a Dahua VTO2202F. It has a camera, a microphone, a call button, and an ONVIF integration that carries the video. The button press reaches no integration at all. ONVIF does not see it.

The event does exist. It travels in a proprietary stream on the panel, eventManager.cgi?action=attach, which you have to hold open and decode yourself. The result is a 225-line Python bridge in its own container that authenticates against the panel, listens to that stream, republishes over MQTT, and announces itself to Home Assistant through auto-discovery.

What that gives the house: when someone rings, both phones get a high-priority notification carrying the panel's view, an "Open" button and a "View" button. Pressing "Open" triggers the door. At the same time, the Sonos announce the call in the living room.

Between "the doorbell reaches nothing" and a working bridge, one evening passed. The agent identified the stream in the manufacturer's documentation, wrote the bridge, wired up auto-discovery and handled the error cases. I supplied the panel's credentials and checked the result.

The bridge carries one guard I am happy with. If the panel forgets to send the end-of-call event, a two-minute timeout resets the sensor. Without it, one missed hang-up would leave the house stuck on "someone is ringing" forever.

I would never have written that bridge. Not because it is hard, but because I would never have started reading a proprietary stream's documentation for a doorbell.

What did not change

Hardware is still hardware. A Zigbee module that loses its network is fixed by throwing a breaker, and it took me three attempts to find the right one. A Somfy accessory dropped by its bridge is re-paired with the remote, standing in the bedroom. A bulb that forgot its Wi-Fi wants five fast power cycles.

Judgment stays on the human side too, and not only for technical calls. The 7:30 p.m. television cut is not an energy optimisation. It is an end-of-day landmark for a child.

And the installation did not get simpler. It gained integrations, containers and dependencies. A fleet that grows faster is still a fleet that grows, and the next posts in this series are mostly about what that costs.

Where this goes

The series follows one plan: an episode per layer of the problem.

1. This episode — the inventory, ten years of sediment, and a measurement of what changed.
2. The cost of trying — why the win shows up on the projects you never started, not on the ones you already did.
3. The shape of the day — gate, television, shutters and the official school calendar: the house holds the frame, and the schedule changed three times in one week.
4. The house that speaks — designing thirteen spoken announcements for kids, which is a writing problem before it is a technical one.
5. Thermal behaviour of a 1970s house — six shutters deciding on their own, the land registry, and the office at 29 °C in the middle of the night.

What I am taking away

• Every layer was laid for a good reason. None of them was laid with the next one in mind.
• A heterogeneous fleet is the norm, not an accident. Nine ecosystems in the hands of a hobbyist who picks case by case is the expected outcome, and no standard has reduced it.

The next episode starts from the question this one leaves open: if skill was not the brake, what was.