Skip to content

Ventilation

  • Decided: 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 → wall cores + power/control cabling required.
  • 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 (models TBD): master bathroom, kid's bathroom, guest toilet, dressing room, laundry room, server room; boudoir — probable, to verify.
  • Extractor fans — control model (decided): 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 — presence-linked start + run-on via the actuator's staircase/run-on function, fed by the wet-zone PIRs (presence); 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 (decided): 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 if its fan is confirmed): no autonomous KNX behavior — actuator channel + manual override only; HA owns a periodic airing schedule (~10 min every few hours, tunable). Server room: HA loop on room/rack temperature; the position's manual button is the fallback; an HA-offline safety net (actuator runs the fan continuously when HA's heartbeat disappears) is a noted option, TBD.
  • Extractor fans — manual override (decided): 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. The laundry room gets a minimal position at its door for this rule alone (positions).
  • 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 (decided at 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 — fallback behavior with HA offline (units' own auto mode?) and the concrete remote-control interface of the ComfoSpot 50: TBD, verify with Zehnder options.
  • 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 on the kitchen 2.2 street tier, 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. Leave 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.
  • Room-level placement: room inventory.