kap — home automation¶
Architecture and planning documents for the house automation system: a KNX wired backbone, Home Assistant as the supervision layer, and a custom AI assistant on top.
This is the project draft, meant to be shared with contractors and designers. Everything recorded here is decided unless the page says otherwise: open items are marked TBD, anything still tentative says so (candidate, probable, to verify).
Context¶
- House renovation in progress; walls are currently open — wall-dependent decisions are on the critical path.
- The house will have warm floors and air conditioning — equipment and zoning decided in subsystems/climate.md.
System layers¶
Base functions run on the bus; the server layer is optional on top — the house must stay fully livable with HA offline.
- KNX — wired backbone: wall controls, and room-level control loops.
- Home Assistant — supervision layer on top of KNX (coordination, schedules, dashboards, remote access).
- Custom AI assistant — integrated into HA; intent/conversation layer.
- Exact layer boundary per subsystem: TBD — to be agreed with the KNX and HA integrators.
Document map¶
| Document | Contents |
|---|---|
| subsystems/wall-controls.md | Jung KNX wall controls: three-tier operating concept, mounting and frame conventions, finishes |
| subsystems/climate.md | temperature regulation model, AC equipment and control pattern, warm floors |
| subsystems/voice.md | voice/AI satellite mission, provisioning principles and positions, hardware criteria |
| subsystems/presence.md | presence detection: PIR for circulation zones, mmWave candidates for sit-still rooms |
| subsystems/lighting.md | DALI backbone, facade lighting, plug-in lamp rule |
| subsystems/shading.md | blinds, curtains, awnings |
| subsystems/ventilation.md | HRV units, extractor fans, the HA-owned control loop |
| subsystems/water-safety.md | leak sensors, shut-off valve |
| rooms/index.md | per-room device inventory (zones 1–22 + exterior zones) |
| rooms/house-model.md | spatial model: structure, adjacency, orientation, exterior openings |
| positions/index.md | consolidated switch / controller position register: position codes, wet-room rule, room/zone summaries, full position entries, diagrams, and pending candidates |
| diagrams/ | SVG schematics referenced from the position register |
| changelog.md | what changed in the draft between published versions, newest first |
Reading the open items¶
Five markers, used consistently across these documents:
| Marker | Meaning |
|---|---|
TBD / TBD with <party> |
undecided; where a party is named, that party answers it |
| Verify before drilling: | a physical check that must happen while the walls are open |
| To verify: | a fact to confirm from a datasheet, supplier or bench test — no wall deadline |
| Open: | a sub-question inside an otherwise decided entry |
| Parked: | deliberately deferred; not blocking |
Words that qualify a fact rather than flag an open item — probable, uncertain, unrecorded, pending, under reconsideration — mean exactly what they say and are preserved as written. Undecided wall-control spots are named Candidate n until a code is assigned (positions).
Reading the diagrams¶
- Frame/unit schematics: the outer rounded rectangle is the switch frame; inner rectangles are modules and buttons, each labeled with its point functions.
- Color code: lights = amber, exterior lights = blue, blinds/mechanics = teal, scenes/climate = purple, reserved = neutral gray.
- Dashed outline = conditional or reserved (not yet confirmed); solid = confirmed.
- TBD on a button means the unit itself is decided but that button's function isn't assigned yet.