profi-air (Fränkische Rohrwerke) — local KWL integration with self-learning diagnostics
A Home Assistant custom integration for Fränkische profi-air ventilation units (KWL / MVHR). Fully local, no cloud, no firmware changes to the device.
It started because I wanted my profi-air 400 touch in Home Assistant. It ended up doing rather more than that — the interesting part turned out to be not reading the device, but understanding it.
The bug that shaped the project
My summer night-cooling automation ran every night: fans to level 4, bypass open, pull cool night air through the house. But the sensor tracking “how much did we actually cool?” kept showing Unknown for weeks. The automation was clearly working. The measurement was lying.
It turned out the unit silently drops from level 4 after about two hours, and my automation corrects it within seconds. A 30-second poll occasionally landed exactly in that brief correction window — and the session-based measurement treated each blip as the end of a cooling session, shattering one good night into fragments that never crossed the threshold.
The fix was to stop thinking in “sessions” and measure the net temperature drop across a fixed 22:00–07:00 window, regardless of interruptions. If you’ve ever had an automation that works while the metric about it lies to you, you’ll know why that was satisfying to chase down.
That’s the spirit of the whole thing: not just exposing registers, but making the numbers mean something.
What it does
Control & monitoring (all models)
- Fan level control, bypass control
- All four air temperatures, humidity, VOC/CO₂ where the hardware has them
- Filter and annual-maintenance reminders as proper HA repair issues
- Energy tracking for the HA Energy Dashboard
Self-learning analytics — the part I’m actually proud of
Instead of hard-coded thresholds, the integration builds its own baselines per fan level and per season, then flags deviations from your unit’s normal:
- Filter clogging detection — rising fan RPM at the same level means rising filter resistance. It catches this before the time-based filter interval does, which matters in dusty or high-pollen homes.
- Heat-recovery efficiency drift — notices when the exchanger underperforms its own seasonal norm
- Bearing wear vs. clogging — same RPM baseline, opposite directions, told apart
- Bypass diagnostics — leak detection, actuator hunting, summer bypass recommendation
- Night-cooling effectiveness — K cooled per night, efficiency in K/h, plus an “inactive nights” counter that catches a silently broken automation early
Everything self-calibrates over a few weeks. No calibration ritual required from you.
Supported devices
Protocol is auto-detected — HTTP first (touch), then Modbus TCP (flex/flat). You just point it at the unit’s IP.
| Device | Protocol | Status |
|---|---|---|
| profi-air 250 / 400 touch | HTTP |  Validated on a real 400 touch |
| profi-air 360 flex | Modbus TCP | Confirmed on real hardware |
| profi-air 130 flat | Modbus TCP | Confirmed on real hardware |
| profi-air 250 flex | Modbus TCP |  From documentation — hardware feedback welcome |
| profi-air 180 flat | Modbus TCP | From documentation — hardware feedback welcome |
The flex/flat side was built entirely from the official Fränkische Modbus documentation. Community members with real hardware have since confirmed the 360 flex and the 130 flat — including one register-level bug where newer firmware moved the device-type byte, which took a full register dump to pin down. That’s the kind of help that makes this work.
Install
HACS → custom repository:
https://github.com/johnnyh1975/ha-profiair
Help wanted
If you own a 250 flex or 180 flat — the two models still only validated against documentation — I’d really value a quick report. Even “it sets up and the temperatures look right” is useful data. If setup fails, the error message now shows the raw System-ID, which is usually all I need to add support.
Feedback, issues and register dumps all welcome. 
New — experimental