Home Automation: Home Assistant on KNX

A wired KNX home run like production infrastructure: reverse-engineering audit of the bus, custom ESP32 and ESPHome hardware integration for the intercom and the gate, zero-trust remote access over WireGuard, energy observability from the Linky smart meter, encrypted backups and AI-assisted operations through MCP, all versioned as code.

  • Home Assistant
  • KNX
  • IoT
  • ESP32
  • Embedded Systems
  • DevOps
  • Security
  • Automation
  • Infrastructure

By Marius Ayrault · 22/06/2026 · 3 min read

Personal project. The configuration is versioned in a private repository and run with the same operational discipline as production infrastructure.

The installation

Home Assistant OS is deployed on top of a wired KNX installation: lighting, shutters and dimming communicate over a standardized bus, exposed through a unified interface. Around the bus, about 800 entities: Matter smart plugs with per-socket metering, MQTT sensors, HomeKit bridges for voice control, TV and media control. Everything runs locally, with no cloud dependency.

Architecture: KNX bus and local ecosystem feeding Home Assistant, exposed through a WireGuard tunnel with three access tiers, operated as code

Reverse-engineering the KNX bus

The installation predates the project and its original ETS programming was unreliable. Rather than trusting the documentation (the working rule: truth is the bus, not the file), the audit cross-references the exported ETS project with live bus captures to rebuild the real topology: ghost addresses never wired to any device, a dead lighting circuit, motion detectors never linked to a group address, shutter positions estimated by travel time in the absence of feedback.

Every anomaly was tracked as a numbered problem. The ones requiring ETS access became an evidence-based specification handed to the KNX integrator: proof per device from telegram captures, scoped tasks, expected results written as telegram traces. Meanwhile, orphan wall pushbuttons were recycled through raw telegram triggers in Home Assistant, restoring behavior no actuator was listening to.

Intercom and gate: custom hardware integration

The intercom is a two-wire analog audio unit, no camera and no API, and the gate motor only accepts a dry contact. An ESP32 running ESPHome bridges the gap without replacing anything: a relay wired in parallel with the existing pushbutton sends the opening pulse, capped at 500 ms in firmware, and a rectifier stage tapped on the handset earpiece pair makes the chime readable by the microcontroller. The call signal is too weak for a logic threshold, so detection runs on an ADC measurement compared in software, with the raw level kept exposed as a sensor to catch any drift. A ring fires a critical notification on iPhone, with gate opening as a single Face ID protected action, and the gate is exposed as a HomeKit accessory for voice control.

Zero-trust remote access

Remote access is built on a WireGuard mesh, with no public exposure of the installation and three strictly separated tiers: household members reach nothing but the interface, the maintainer has a dedicated administration channel, and guests stay local only. The whole setup went through a hardening pass and regular access audits, all documented in a runbook. Recurring cost: zero.

Energy observability

The Linky smart meter feeds the energy dashboard through a dual pipeline: long-term statistics injected over the WebSocket API, plus MQTT sensors for live values, with a Python smoke-test script validating both paths. Per-socket metering over Matter is aggregated by utility meters into daily, monthly and yearly cycles, charted by custom ApexCharts data generators querying the recorder statistics API directly. A grid-carbon gauge tracks the share of decarbonized electricity in real time.

Run like production

  • Configuration as code: conventional commits, branch and pull-request workflow, a versioned surface deliberately limited to hand-written files. Secrets, machine state and package-manager output stay out of Git.
  • Runbooks: a 700-line remote-access runbook with a decision record, a revocation procedure, a troubleshooting table and a two-minute periodic check.
  • Updates: monthly automated add-on updates with a partial backup before each install and a failure report; core updates stay manual, on notification.
  • Backups: encrypted weekly snapshots to two destinations, local and cloud, with an explicit split: Git covers the configuration, backups cover the system.
  • Monitoring: tiered alerting on system health and power consumption, with critical notifications that bypass silent mode.
  • Self-healing: link-loss detection triggers integration reloads instead of waiting out reconnection backoffs.

AI-assisted operations

Operations are AI-assisted, and that assistance is configured with the same rigor as the rest of the infrastructure. The repository versions a full project brief that frames the agent: installation context, operating conventions, a restricted permission scope and explicit guardrails distilled from field experience (verify the live state before proposing a change, state the required reload for every modification, confirm any sensitive action). MCP servers expose the live installation to the agent, put to work on audits, diagnosis and drafting. I drive the workflow end to end, make the architecture calls and commit every change with full knowledge of the system. A concrete case of context engineering, where AI multiplies my expertise without ever replacing it.

What the project demonstrates

Networking, protocols, security architecture, embedded electronics, observability and operational automation, applied end to end on real hardware and held to production standards. The same reflexes (audit before change, evidence over documentation, least privilege, runbooks and rollback plans) transfer directly to operating LLM systems in production.