De Dietrich Smart - My Heat Pump in Home Assistant

Ever looked at the most expensive appliance in your house and realised it’s the only one you can’t automate? That was me with my De Dietrich heat pump. Sensors, plugs, the robot vacuum and even the oven were all in Home Assistant, but the thing that actually heats the house lived alone inside the De Dietrich Smart app.

So I fixed it with De Dietrich Smart for Home Assistant, a custom integration for De Dietrich systems controlled by the Smart TC Wi-Fi thermostat. You log in with your app account, and the thermostat, the hot water and the heat pump itself show up as proper Home Assistant entities.

The Problem: No Local API

My first idea was to talk to the thermostat directly over the LAN. I found it on the network and port-scanned it end to end. Nothing. Not a single open port.

The Smart TC’s Wi-Fi module doesn’t listen for anything. It only keeps an outbound connection to BDR Thermea’s cloud, the group behind De Dietrich, Remeha, Baxi and Brötje. That’s where the app gets its data too. So, like it or not, the cloud API is the only door in without opening up the heat pump and wiring something into its controller.

Luckily, I wasn’t starting from zero. msvisser/remeha_home and the community around its forks had already reverse engineered most of that API for Remeha boilers. And because it’s the same backend for every brand, a De Dietrich account works on it too.

But I didn’t want to just install it. That project is mostly built around gas boilers, it lags behind recent Home Assistant releases, and the forks with heat pump features weigh in at thousands of lines. I wanted something small that fits a heat pump, so I wrote my own.

What It Does

The integration creates a device for the heat pump, one for each heating circuit, and one for hot water:

Thermostat: a climate entity with Auto (follows the clock program; a new temperature overrides it until the next switch), Heat (holds a fixed temperature) and Off (frost protection). The app’s three schedules are presets.
Hot water: a water heater with Schedule, Comfort, Eco and Boost, plus the comfort and eco temperatures.
Heat pump: outdoor temperature, water pressure, status, today’s energy consumed and delivered, COP today and the season’s SCOP.
Heating curve: slope and base temperature per circuit, the setting that matters most for a heat pump’s efficiency.
Heating/cooling switch: Automatic, Heating only or Cooling only, for systems that can cool.

My system has three circuits but only one thermostat. The other two run on the heating curve alone. They still get a climate entity, so you can set their mode and schedule, but without a room temperature that doesn’t exist.

How It Works Under the Hood

It’s plain Python with no extra dependencies, using the HTTP client Home Assistant already ships:

Login: the same Azure AD B2C sign-in the app uses, so it’s your normal email and password. Refresh tokens rotate, so the newest one is saved, and if the session ever expires it quietly signs in again.
Polling: one dashboard request every 60 seconds covers the whole system. Energy figures and heating curves change slowly, so those are fetched every 15 minutes.
Commands: the cloud applies changes a few seconds after accepting them. Home Assistant shows the new state straight away, then re-polls 8 seconds later to confirm it.

My favourite bit came from the heating/cooling switch. The API takes an operatingMode, but nobody had documented which values it accepts, and guessing is a bad idea when every right guess changes your heating. So I let the server’s JSON parser tell me instead:

# Valid JSON up to the value, then a syntax error (the trailing comma)
curl -X POST "$API/appliances/$ID/operatingmode" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"operatingMode":"ForcedCooling",}'

The parser reads the value before it reaches the broken part. An unknown value fails with “could not be converted to OperatingModes”. A known one gets past that check and fails on the syntax error instead. Either way the request is rejected, so nothing ever changes. A dozen candidates later I had the real list: AutomaticCoolingHeating, AutomaticHeating, ForcedCooling and Off.

It’s also written for the climate and water heater changes in Home Assistant 2026.11. It has a test suite that runs it inside a real Home Assistant against a simulated cloud, and CI runs HACS and hassfest validation on every push.

Important Limitations

⚠️ I built this for my own home, and it may not work for yours. I’m sharing it as-is, with no guarantees and no support commitment.

It talks to an unofficial, undocumented cloud API that can change or break at any time.
It has only been tested on my system: an IDU2WH heat pump, a Smart TC, three heating circuits and a hot water tank. Other heat pumps, boilers or hybrid setups may behave differently.
Cooling only hasn’t been tried for real yet. I added it in November, and I’m not cooling my house in November.
The heating curve controls change your installer’s settings. Write the current values down before you touch them.
It’s not affiliated with De Dietrich or BDR Thermea in any way.

If you want truly local control, the realistic route is hardware: an ESP32 with ESPHome talking Modbus to the heat pump’s controller. The cloud was the quicker path to something I use every day.

Try It Out

The code is on github.com/rouralberto/ha-dedietrich-smart. Add it to HACS as a custom repository (type Integration), install De Dietrich Smart, restart Home Assistant, and sign in with your app account. You’ll need Home Assistant 2026.10 or newer.

If it works with your system, or doesn’t, open an issue and attach the integration’s diagnostics. They strip out your email, password and serial numbers, and they’re the fastest way for me to see how your setup differs from mine.

Now the heat pump can finally join the rest of the house in the automations. Heating that knows when a window’s open sounds like a good place to start.