I just tested it and it seems to be working very well. Cudos to manuxio!! Thank you so much. Amazing work!
A star on the repo would me appreciated!
Thanks for this @manuxio - it’s working really well for me - stable so far and very comprehensive! Just what we needed!
Unfortunately 3 of my 9 thermostats are not showing up as controls in HA (but they are present as sensors). I raised an issue in the repo - lmk if I can help with diagnosing the problem.
Thanks again - really great work!
Sorry everyone, I completely missed the updates on this thread.
In the meantime, I made a few improvements to MatteoManzoni’s codebase, but since I’m not fully confident with Python, I moved to contributing to the Manuxio codebase. We’ve begun discussing how to integrate the Modbus solution into the existing architecture.
You can find the related issue here — anyone who’d like to jump in is more than welcome 
thank you guys for this 
its working great!
be wary it’s AI generated slop
But, but…
Can’t AI read the manuals and documentation provided by Rehau, in depth and understanding, look at another integration that provides RS485 and MODBUS integration to HomeAssistant, including all sensors, entities and automation, update the configuration values and naming to match, and nicely format it so it runs well, and then package it for HACS? Add the specifics for hardware required and how to connect it.
Do it like a human would, standing on the shoulder of giants.
Post it on GitHub, not distribute it by email?
Nope…
Gnashes teeth.
LOL, are you serious about calling it “slop”?
Greetings, I need to automate a house where there is a Rehau nea smart 2.0, I plan to buy a knx gateway as well, my goal is to keep the Rehau wired thermostats in the house and create virtual thermostats on the main dashboard and manage it with the central unit, but I need it to synchronize the set points as I change it on the room thermostat so that it synchronizes with the virtual thermostats and when I set the virtual thermostats it synchronizes my rooms to the set temperature, is this possible?
For transparency: I’m the developer of what is, to my knowledge, the only currently working Home Assistant integration for this system. My comments are not theoretical — they come from direct, hands-on development, including dealing with undocumented behavior, integration constraints, and real-world usage scenarios.
Technically, the system does not offer any standout or advanced features. It performs standard zone-based heating control, but there is nothing that clearly differentiates it from other solutions in the same segment.
The mechanical components — particularly the piping — are of good quality. The room displays are elegant from a design perspective. However, they were innovative at the time of release, and today they feel dated when compared to modern alternatives — especially solutions that Home Assistant users can implement using readily available hardware with far greater flexibility.
The electronics appear cost-optimized rather than robust, and the software side is where the limitations become most evident. The control logic is counterintuitive at best. Even relatively simple tasks, such as configuring the scheduler, are unnecessarily complex and poorly explained. Understanding how scheduling rules interact is not straightforward, and achieving predictable behavior often requires trial and error instead of clear configuration logic.
In addition, the company has clearly demonstrated a lack of interest in supporting open ecosystems. To date, there has been no meaningful cooperation with the open-source community, no official documentation made available for integration purposes, and no visible effort to enable third-party interoperability. On the contrary, updates and design decisions have consistently made integration more difficult rather than easier.
If openness, integration capability, intuitive control, and long-term flexibility are priorities, there are alternative systems on the market that provide a more coherent and future-proof experience.
The ‘AI tool’ talk is just a distraction—nowadays every developer use AI anyway. The real thing is the reverse engineering and all the testing we did to make this actually function. In my knowledge , this is the only solution that really works. Sure, it have some limits, but that’s only because REHAU refuses to provide an API or any documentation. We are working in the dark here. If the vendor gives us proper access, we wouldn’t have to reverse engineer nothing. Let’s not mistake vendor-imposed limitatons for a lack of effort from our side.
Hello, folks! Thanks for the great discussion — it gave me some valuable insights.
I am a future NEA Smart user. My setup will be:
Floor 1:
Room 1 — underfloor heating + 1 fan coil
Room 2 — underfloor heating + 1 fan coil
Bathroom — underfloor heating only
WC — underfloor heating only
Room 3 — underfloor heating + 2 fan coils
Floor 2:
Room 4 — underfloor heating + 1 fan coil
Room 5 — underfloor heating + 1 fan coil
Bathroom — underfloor heating only
I would like to have a single Shelly Wall Display in the house and Shelly BLU H&T ZB devices in each room that will broadcast data to Home Assistant. Then HA should communicate with NEA Smart.
From what I’ve read and with some AI assistance, these seem to be the steps:
Heat Pump (Vitocal 111-S)
- Connects to a Raspberry Pi Zero 2W via USB Optolink adapter — the Pi runs vcontrold and pushes data to Home Assistant via MQTT over WiFi
- Also receives a boiler demand relay signal directly from the NEA Smart 2.0 Base, telling it when to produce heat
NEA Smart 2.0 Base
- Controls all 8 underfloor heating zones via zone relay outputs (RZ1-8) to the manifold actuators
- Connects to all 8 room units via ZOBUS (2-wire bus)
- Connects to the U-Module via SYSBUS for the fan coil relay outputs
- Communicates with Home Assistant via WiFi/LAN on your local network
U-Module
- Handles fan coil relay outputs for all 6 fan coils
- Gets its commands from the NEA Smart 2.0 Base via SYSBUS
Home Assistant
- Receives heat pump data from the Pi Zero via MQTT
- Controls and monitors the NEA Smart 2.0 via its local WiFi API
- Receives input from the Shelly Wall Display via WiFi
Do you think this would be possible? Is there something that I am missing?
REHAU Nea Smart 2 — v6.0 is a brand new integration
After months of fighting cloud APIs that kept changing under our feet, the REHAU Nea Smart 2 add-on for Home Assistant has been completely rewritten from scratch. v6 shares zero code, zero topology and zero assumptions with the v5.x line. If you're upgrading from v5, treat it as a different integration — slug, entity IDs and MQTT topics are all new (migration notes in the release page).
What changed in one line: the add-on now talks directly to your REHAU base station on your LAN. No cloud account, no e-mail, no 2FA, no POP3, no OAuth2, no Playwright, no headless browser.
Why we rewrote everything
Earlier versions did what they had to: scraped REHAU's cloud, juggled the auth flow, and went through hoops to keep the link alive. Throughout this year, REHAU has progressively slammed the door on that path — tightening login flows, requiring 2FA via e-mail challenges that POP3 polling could never reliably handle, throttling endpoints, and shipping app updates that quietly broke whatever work-around the integration relied on the week before.
To be plain about it: that's behaviour deeply at odds with everything the Home Assistant community stands for. A homeowner who paid for a heating system should be able to control it from their own house, under their own roof, without an internet connection and without asking permission from the manufacturer. Open, local control is the whole point of HA. Cloud-only integrations exist by necessity, not by design — and when a vendor actively builds higher fences around the cloud they themselves provide, an open-source integration eventually has to either give up or take a different door.
We took the different door. v6 ignores the cloud entirely and reads the REHAU base station's local web interface directly.
What v6 gives you
- One HA device per REHAU installation, all auto-discovered via MQTT
climate.*per room with the right mode mapping (off/heat/auto + REHAU's native presets)- Per-room switches: lock / auto-start / open-window detection
- Per-room fancoil running binary_sensor with the actual motor state (mirrors REHAU's pink fan icon)
- Diagnostic sensors for the full bus I/O (RZ, RELAY, DI, AI, AO) on master + every U-module
- Optional diagnostic sensors for calibration offsets
- A bundled React Web UI, dark + light, EN + IT, installable as a PWA on your phone, with passwordless auto-login from inside HA
- Swagger API docs for the REST surface (
/docs)
How to try it
- Settings → Add-ons → Add-on Store → ⋮ → Repositories
- Paste
https://github.com/manuxio/rehau-nea-smart-2-home-assistant - Install the REHAU Nea Smart 2 Bridge (local) add-on, set
device_urlto your base station's IP, paste your 8-character installer code, and start.
Or click here: [Image]
A small caveat: the base station needs its local web interface enabled (REHAU's AP / local commissioning mode). If yours has only ever been paired to REHAU's cloud, you'll need to re-pair it through the local flow once. A full step-by-step guide with screenshots of the device screens is coming this week.
Thanks
To everyone who tested v5 through its many flavours of breakage, filed issues, hand-edited config files at 1 AM and refused to give up on local control — you kept the project alive long enough to deserve a clean v6. PRs welcome.
Repo: GitHub - manuxio/rehau-nea-smart-2-home-assistant: Betterehau - Custom Climate Control for Rehau Nea Smart 2 for Home Assistant · GitHub Source: same repo, apps/ + packages/ (monorepo) License: MIT