KNX Thermostat override hot/cold tolerance


I have two MDT AKH-0400.03 4-way heating actuators in my home, controlling the underfloor heating. I have them configured using the “simple mode”, not the continuous PI. The issue I have is that the switching hysteresis for this actuator is 0.5 Celsius degrees. This is way too much for the underfloor heating - the temperature raises too much after the thermostat turns it off.

I would like to overwrite (if possible) the hot/cold tolerance for the thermostat. Unfortunately there is no way of changing this in ETS for my heating actuators.
I was thinking of doing an automation running every 15 minutes which checks if any of the thermostats are on and they reached their target temperature and somehow reset the thermostat, consequently reducing the hot tolerance to 0.0 degrees.

I’m not sure where to start. Any ideas?

Hi :wave:!
I’d start by calling my heating plumber. It seems you are trying to fix a hydraulic problem with a brute-force HA automation.
If your room heats up way too much the underfloor heating flow temperature and/or flow rate is way too high. I’d fix that first before looking into changing to PI regulating the floor-heating-valve actuators instead of 2-point switching them.

That said, resetting KNX devices from HA is not supported by the HA KNX integration.

I had an intensive testing phase with my underfloor heating 2 years ago, when moving to our new house :slight_smile: I think, if the acuator is 100% open until the air temperatur in the room ist 0.5 K above target temp, then the floor is already very hot. If you switch off the actuator then, the floor will continue heating up the room for at least 2-3 hours or more (in my case).

My personal opinion is that a 2-point controller is not suitable for unterfloor heating.
I’m very sensitive to room temperature, for me not even PI was “good enough” :sweat_smile: my main problem was, that if the room temperature is above target and decreases, the controller waits until the room falls under target temp and only then starts the heating process. But as the underfloor heating system is very sluggish, the room temp continues decreasing below target temp, often -1 K.
I “misuse” the setpoint_shift function for adding a self-programmed D-part to the PI controller (PID is not implemented by MDT). I’m very happy with the result.

But back to your topic: If you want to follow the way you described, maybe you could manipulate the target temperature, expose that to KNX and let your heating use that as target temp? Something like: If room temp > “real target temp” then add 0.5 K to the manipulated target temp. The actuator should close then.

Thank you for the reply. This is exactly my experience.

The underfloor heating is very sluggish and I totally agree that that 2-point controller is not doing a very good job, but it was the thing I understood out of the 2 options. Do you have an example on how you set up your PID controller? It would be a great starting point for what I’m trying to do.

Also, what params are you using for the PI controller in the MDT actuator?

Im using 4K 120min on my Gira actuator. Some rooms 5K 240min where I want slower response (bathroom for example).

But there are many different (sometimes religiously) opinions.

Thank you for the reply. I’ve checked with my heating plumber and made sure that the flow rates are correct. The issues I’m having are inherent to the underfloor heating system and the fact that I’m using the 2-point switching approach.

The heating is very sluggish and I think the 2-point switching is not the way to go here but it was the one that I could actually understand. For example if I set the target temp to 21.5 the controller waits for the temp to drop to 21.2 and only then opens the circuit and starts the boiler. It takes about 2 hours for the temp to actually rise and during this time the temp drops even lower. When it finally rises to the target temp because of the 0.5 K hysteresis it will continue rising up to 21.8 and only then stop. The floor is now warm and for the next couple of hours the temp will just keep rising.

Do you think a PI approach will alleviate this?

Cool! Thank you!

I’ll go with those values for now to see if I still have that temp over/under shoot. What PWM cycle times are you using?

different for every channel to spread valve openings. The newer MDT controllers can do this out of the box so I’d go with 12-18 minutes. My minimum command value is 20% I think - if it is below it is treated as 0 from the valve channels.

Not sure. In theory it should be possible to keep all valves open 100% and don’t overheat a room - thats when the heating water temperature and flow rates are set to an optimum - so a regulator and valves are not even needed. But real life may vary so you will have to just play around and give it a try imho

Do you have an example of how you added the D-part to the PI controller? I’m experiencing the same with my heating system as well

I don’t have a D part, nor have I seen any knx heating actuator that would support that out of the box.
What are you experiencing?

I do this with AppDaemon. An AppDaemon App looks for the values in the past (time is configurable), calculates the derivative and shifts the setpoint for the PI controller.
You find this app here:

and the config for the apps here:

It works for me, but: I’m not a good programmer, so it’s a hacky solition :slight_smile:

Sorry for just throwing a bit of code on you. So, I see some pros and cons on that and I’d like to say a few words to alternatives.
Main “pro” of my solution: If HA or AppDaemon is unavailable, die KNX controller will still work and control my room temperature. Maybe its target temp is a bit offset (max. 1-2 K), but I can adjust that buy shifting the “original” target temp which is KNX-internally.
Main “con” is pretty obvious, it involves HA, AppDaemon and InfluxDB. It’s not exactly what you call plug and play.
I think there are some alternatives:

  • Use a KNX device with an integrated PID controller, such as a Home Server (too expensive in my opinion)
  • Run the temperature controller in HA. There are some threads in this community about that. One of the solutions has an “auto-calibration” function, but I don’t know if that works well. Con: If HA is unavailable, your heating is “out of control”
  • Programm a more “HA-internal” solution with a similar approach to mine. Avoiding AppDaemon and InfluxDB should reduce possible points of failure