Decentralized heat-recovery ventilation — Zehnder ComfoSpot 50 units, 6 total (3× living room, 1× master bedroom, 1× kid's bedroom, 1× Ekaterina's office). In-wall units: the 230 V feeds to the six unit positions are in place; wall cores still to drill, and control cabling depends on the module placement below.
ComfoSpot ordering spec: units ordered without the optional humidity / CO₂ / VOC sensor boards — demand control comes from separate air-quality sensors on the HA side, and self-deciding units would fight that loop the way self-deciding extractor fans would. External wall panel: plastic (paintable). One wall installation kit per unit, ordered separately from the units — the round PVC tube version: all six openings are core-drilled, and the tube shortens to the wall thickness. The walls are verified to sit within the unit's standard 335–600 mm thickness range. Ordered in Cyprus.
Pavel's office (music studio): separate ventilation unit, model TBD — the room gets acoustic treatment, so the unit must be selected for low noise / acoustic compatibility.
Extractor fans — control model: plain 230 V fans on KNX switch-actuator channels, one channel per fan — model choice (TBD) is constrained to units without integrated humidity/timer logic (self-deciding fans = invisible state, can't be coordinated or silenced). Base behavior lives in KNX for every fan — presence-linked start + run-on via the actuator's staircase/run-on function, fed by the wet-zone PIRs (presence), and periodic or fallback triggers where a class needs one, from a bus-side module (TBD). HA adds the coordination layer on top (humidity boost, schedules, night silencing). Per-room trigger policy: next bullet. Every fan gets its own feed from its actuator channel (switched live + neutral), never teed off the room's light circuit; plus a local isolator near each fan for maintenance per UK-derived practice (exact type — with the electrician).
Extractor fans — trigger policy: three classes. Wet rooms (master bathroom, kid's bathroom, guest toilet): KNX presence start + run-on after vacancy (~10 min, ETS-tunable per room); the guest toilet starts immediately on presence, the bathrooms only after ~2 min of continuous presence so short visits don't wake the fan; post-shower steam is the humidity-boost layer's job (option below). Utility rooms (dressing room, laundry, boudoir): a periodic airing base on KNX (~10 min every few hours) driving the channel's staircase function; HA refines the schedule on top. Cycle values: TBD — ETS phase.Server room: HA loop on room/rack temperature; the position's manual button is the fallback; a KNX-side base too — mechanism TBD (fan runs on HA heartbeat loss vs. a bus-side temperature trigger).
Extractor fans — manual override: every extractor fan gets a manual button at its serving switch position (wet rooms: the mapped outside position per positions) — pressing it toggles the fan and suspends all automation over that fan for a hold period (the KNX presence/run-on base and the HA layers both). Hold duration and mechanism (actuator lock object vs. logic vs. HA-side): TBD — ETS phase. This is distinct from the AC fan-stage no-buttons policy in climate, which stands.
Option (recorded): humidity sensors in the bathrooms — probably HA-domain hardware — driving a humidity-boost layer on the bathroom fans (shower steam peaks after vacancy, which presence triggers alone miss); hardware and placement (BS 7671 zones): TBD.
Control model (concept level): ComfoSpot units run fully autonomous under an HA control loop — HA reads air-quality data from dedicated sources (CO₂, particulates, humidity; sensor hardware TBD) and commands the units remotely (speed, mode); HA also reads service information (e.g. filter-replacement signal). No wall controls for the HRV units (extractor fans have manual-override buttons — see above). Note: this is the one subsystem whose control loop deliberately lives in HA, not KNX — the HA-offline fallback is the units' own integrated panel, preserved as a hard requirement on the control module below.
ComfoSpot remote control — custom module: no Zehnder interface is used. The CS50 exposes none for third-party systems: its internal 4-pin connector (+ / A / B / −) serves Zehnder's own external control panel. A custom module per unit taps that connector — UART, 9600 baud, 9 data bits, 1 stop, no parity, single-master/multi-slave with the 9th bit marking address vs. data — and draws its supply from the same connector. Scope: HA-vendor deliverable, local-only (no cloud), prototyped on one unit before the remaining five; published reverse-engineering of the protocol exists as a starting point, not a specification. Hard requirement: the module joins the bus without displacing the unit's integrated panel, which stays the HA-offline fallback — with HA down the unit holds its last stage and the panel still controls it. HA must set the fan stage and read back stage, filter-replacement signal and fault state. Open: module placement and its transport to HA — inside the unit on Wi-Fi vs. a wired run to a serviceable spot — TBD; the wired option is walls-open-dependent. Noted: opening the unit likely voids the Zehnder warranty.
Optional idea (to verify in the ETS phase): per-room manual HRV speed via the F 50 RC's built-in menu by repurposing the spare internal controller 2's fan-controller objects — HA maps the fan-stage telegrams to ComfoSpot speed. Constraints: the menu entry stays generically labeled (con2 + fan icon), works only with HA online; verify the ETS application allows the controller-2 fan section without an active controller-2 loop.
BBQ grill extractor hood: hood over the grill in the covered BBQ zone (8) — model/type TBD; control path TBD (appliance with its own fan vs. plain fan on a KNX switch-actuator channel — if the latter, the no-integrated-logic constraint above applies); a local manual button at the BBQ-zone counter position is required (positions); a remote mirror remains planned in the kitchen 2.2 street scope, with whether that kitchen mirror is retained still TBD. Relation to the extractor-fan control model: TBD. Power feed, duct route, and control cabling to the hood position.
Kitchen cooker hood: built into the Miele cooker — a standalone appliance, not part of the extractor-fan control model. Whether the model is connectable at all (Miele@home/WiFiConn@ct is model-dependent): to verify. Need: none identified — the hood's job is an at-the-stove interaction; revisit only if a scenario emerges (e.g. an away scene shutting it off). If ever connected: the official HA Miele integration is cloud-based (conflicts with the local-first principle); community local-LAN integrations exist but are young and reverse-engineered.