Fränkische Profi-Air 360 Flex – Modbus TCP integration and register mapping Home Assistant

Hello everyone,

I'd like to share a project I'm currently working on: integrating a Fränkische Profi-Air 360 Flex ventilation system into Home Assistant using Modbus TCP.

Goal

My long-term goal is to fully integrate the system into Home Assistant, not only to monitor its status but also to implement intelligent automations.

Some planned use cases include:

  • Cooling the house when outdoor temperatures are lower than indoor temperatures
  • Adjusting fan speed based on time schedules or occupancy
  • Humidity-based ventilation control
  • Filter monitoring
  • Energy-optimized operation, for example when excess PV power is available
  • Maintenance and service notifications

Technical Setup

  • Fränkische Profi-Air 360 Flex
  • Modbus TCP enabled
  • Home Assistant Container (Docker)
  • LAN connection via a FRITZ!Repeater within an AVM Mesh network
  • Power supply and energy monitoring via a FRITZ!DECT 210 smart plug

The DECT smart plug currently provides:

  • Power on/off control
  • Power consumption
  • Energy usage
  • Temperature measurement in the ventilation room

Current Status

The following features have already been implemented successfully:

  • Reading the current fan level
  • Reading fan speeds (RPM)
  • Controlling fan levels 0–4 from Home Assistant
  • A dashboard showing the most important values
  • Reverse engineering of the first Modbus registers

One interesting finding is that the target fan level cannot be written using FC06 (Single Register Write).

Instead, the unit expects an FC16 (Write Multiple Registers) command covering a block of 10 registers starting at register 324. Only then is the fan level actually applied by the system.

Dashboard

A screenshot of the current dashboard is attached below.

Next Steps

I am currently trying to identify the following values:

  • Outdoor air temperature
  • Supply air temperature
  • Extract air temperature
  • Exhaust air temperature
  • Humidity
  • Filter status
  • Operating hours
  • Heat recovery information
  • Airflow rates

Looking for Other Profi-Air Users

If anyone here owns a Profi-Air system or has already worked with its Modbus registers, I would be happy to exchange information and findings.

I will continue to document my discoveries and register mappings in this thread as the project progresses.

Welcome to the community!
Looks like it could be a nice project.
A link to the software might be helpful

This may help you with debugging and troubleshooting:

I am aware that the following Integration is not yet capable to integrate the profiair 360 flex.
I spend some time to integrate the 250 and 400 touch versions incl some Advanced features.

We could give it a try to combine also the 360 flex , but i would need your support. Like Web Interface to the 360 flex or api documentation, technical handbook or datasheet,...

Hi Johnny,

First of all, thank you for your work on the ProfiAir Home Assistant integration.

I am currently running a Fränkische ProfiAir 360 Flex and have been testing the Modbus TCP interface directly in Home Assistant. While building my own Modbus integration, I was able to verify several of the registers documented in your project against real hardware.

Confirmed on a ProfiAir 360 Flex:

  • Fan level (read): Register 474
  • Fan level (write): Register 324
  • Fan 1 RPM: Register 162
  • Fan 2 RPM: Register 164
  • Relative humidity: Register 196
  • T1 Outdoor air: Register 132
  • T2 Supply air: Register 134
  • T3 Extract air: Register 136
  • T4 Exhaust air: Register 138

I can also confirm that writing the fan level requires FC16 (Write Multiple Registers). FC06 did not work on my unit. Using FC16 on register 324 successfully changes the ventilation level and starts/stops the fans as expected.

The temperature mapping in your documentation also matches my measurements:

  • T1 = Outdoor air
  • T2 = Supply air
  • T3 = Extract air
  • T4 = Exhaust air

Your documentation has been extremely helpful while reverse-engineering the device.
If you need additional testing on a ProfiAir 360 Flex (bypass status, operating modes, alarms, filter management), I would be happy to help verify registers on real hardware.

One additional observation that might be useful for the integration:
I noticed that fan RPM can be a very good indicator of filter condition. On my unit, the filter replacement timer had not yet expired, but I could clearly see increasing fan RPM drift over time at the same ventilation level. After replacing the filters, the RPM values returned much closer to their original reference values.
This suggests that monitoring the deviation between the commissioning reference RPM (registers 40519 / 40521) and the actual fan RPM could provide an additional indication of filter loading and pressure drop, independent of the time-based filter replacement interval.

Such a diagnostic sensor might help users detect clogged filters earlier in environments with high dust, pollen, or particulate loads.

One additional note: At the moment, we are experiencing very high outdoor temperatures here, so I am currently unable to properly test heat recovery efficiency, bypass behavior, and winter-mode related functions under realistic operating conditions. The unit is mostly running in summer conditions, which limits validation of the heat exchanger performance and some of the advanced thermal control features. I plan to revisit these tests once outdoor temperatures drop and the system is operating in normal heat recovery mode again.

Best regards,

Hi Torsten,

Thank you for the detailed feedback and for taking the time to verify registers against real hardware — that's extremely valuable for the project.

I cross-checked your numbers against the official Fränkische Modbus XML documentation. Most registers match exactly:

  • Fan level write: Register 324 ✓ (matches our implementation)
  • Relative humidity: Register 196 ✓
  • T1–T4 (Outdoor/Supply/Extract/Exhaust): 132/134/136/138 ✓

However, there's a discrepancy on the fan RPM registers. The Fränkische XML lists:

  • Exhaust fan speed: IO101
  • Fan supply air: IO103

After accounting for the 1-based addressing convention used in the XML, that maps to our currently implemented offsets 100/102 — not the 162/164 you measured.

Since five out of your six reported registers match our implementation and the manufacturer documentation exactly, I suspect one of two things:

  1. Your 360 Flex is running a different firmware revision with a shifted register layout, or
  2. The values you saw at 162/164 happened to look like plausible RPM readings but came from a different source

Could you confirm two things for me?

  1. What firmware version is your unit running? (readable via register 40025 / our offset 24)
  2. If you get a chance: does register 100/102 (instead of 162/164) also show plausible RPM values (roughly 800–2900 RPM range) when you query it directly?

If a genuine firmware difference is confirmed, I'd rather model it as a variant in the code than simply overwrite our current mapping — the official documentation is otherwise too consistent with our implementation to change without further evidence.

On a related note — while cross-checking against the XML, I noticed there's a separate register for the current ventilation level status (IO473), distinct from our write register (324). We're not currently reading from it — we only read back our own last-written command. I'll add that as a fix so level changes made directly at the unit are correctly reflected in Home Assistant.

And on your filter-drift idea: great observation, and it fits directly with our existing commissioning reference RPM logic (registers 518/520). Once the RPM register question is settled, I'll add that as an additional diagnostic sensor.

Thanks again for the thorough verification — it's a real help to the project, especially because it's grounded in real hardware testing rather than relying on documentation alone.

Best regards,
Johnny

Hi Torsten,

Thanks again for the register verification work — I've gone ahead and implemented your filter-drift idea as a new diagnostic sensor, comparing live RPM at Stufe 3 against the commissioning reference RPM (registers 40519/40521). It's disabled by default but available for anyone running a flex/flat unit.

Since you're clearly testing on real hardware and have the tooling set up already, would you be willing to gather a few more reference values? These would help make several existing calculations more accurate for the 360 Flex specifically (right now some of them rely on values carried over from the touch-device measurements, which may not transfer cleanly to flex hardware):

Power consumption (Watt) per ventilation level
If you have a power meter or smart plug on the unit, the actual W draw at each of the four levels (ideally with the unit settled for a minute or two at each level, not mid-transition) would let us replace estimated defaults with real measurements — similar to what we already have for the touch devices.

Reference RPM at levels other than Stufe 3
The commissioning registers (40519/40521) only store the Stufe-3 reference. If you could note the steady-state RPM at Stufe 1, 2, and 4 as well (just reading registers 100/102 directly, no extra hardware needed), that would let the filter-drift diagnostic eventually cover all levels, not just Stufe 3.

Airflow / volumenstrom reference, if you have any way to measure or estimate it
Not essential, but if you happen to have manufacturer commissioning paperwork with a m³/h figure for your specific installation, that's useful context too.

No pressure on any of this — whatever you're able to grab is appreciated, and there's no rush given you mentioned summer conditions are limiting some of your other testing anyway. Once you're back to testing heat recovery and bypass behavior in cooler weather, I'd also be glad to get your read on whether the existing efficiency calculations look reasonable on a 360 Flex.

Thanks again for all the hands-on verification — it's making a real difference for the flex/flat support.

Best regards,
Johnny