I am facing a rather interesting case of it’s not a bug, it’s a feature from MDT.
In short:
The MDT can accept a new target temperature for the comfort mode only
The MDT can be programmed to reduce the setpoint temperature by X degrees at night or away mode
Unfortunately, when in night/away mode, the actual setpoint is calculated by distracting the reduction value by the unit. So… If is set the new target temperature e.g. to 18 degrees from HASS, while the heating mode is night, the MDT takes on the value 16 degrees, as I have a 2 degree night reduction.
In turn the new setpoint temperature level is send through the feedback address back to HASS and the visualisation is adapted. This results in a ‘buggy’ behaviour and looks like the temperature just jumps to another value after you set it. (but this behaviour is 100% correct)
I’m asking this question, as I am not yet an expert on HASS and might overlook some of the options.
What could be some of the solutions to avoid the temperature jumps due to the recalculation.
I think in terms of:
Add the reduction temperatures by mode to HASS, so when I set a temperature e.g. at night 2 degrees are added to the value, so that after the reduction by the MDT unit the result temperature is the send temperature. This would require to modify the value after setting but before sending to KNX bus. Not sure if HASS offer that kind of modifiers ?
Another solution would be to remove the reduction. The comfort setpoint would be applies at night or away as well. But then I would need another solution to automate the temperature reductions during those times. This can be done easily in HASS (with a node red flow), but I would lose a part of the core KNX functionality, which for me is important to keep as many of the core operations in KNX.
So if anybody has other interesting ideas, I am one and all ears
It’s currently not supported by the knx climate entity.
So this would need some workarounds in HA or someone willing to dig into it and implement that support in xknx.
Thanks Matthias! Interesting read. I was thinking too much in terms of MDT, but the problem would indeed be very similar for other KNX devices using a temperature reduction, no matter what brand or type.
I am tech savvy and experienced with PHP, but HASS framework and python are new to me, but very much willing to learn. I already had a look at the code for the climate entity on GitHub, but could not identify at first sight the function that processes a setpoint temperature update.
Adding config for night/away reduction and an IF statement to compensate the send value would be great, but perhaps out of my league for now. Guess I won’t have many other options than disabling the reduction (and do this with HASS automation instead of native KNX)
Unfortunately, the KNX device only supports to set a setpoint for the comfort mode as the setpoint for other models is directly derived from it. (so this is a hardware limit and not possible)
Thinking about something else that might solve the problem for now.
Linking the feedback temperature ‘target_temperature_state_address’ to the comfort setpoint group address from the MDT, which has both R and W flags. This won’t prevent the MDT from applying the reduction, but will solve the visualisation. And one will have to accept that you can set and see (only) the comfort temperature from HASS
Why not enable the option in MDT to reset setpoint after HVAC mode change.
This way, as soon as you change the mode from e.g Comfort to Night then the new setpoint is always set to the Comfort setpoint set in the MDT minus the reduction for Night mode (also set in the MDT).
So, if my KNX heating is set the Comfort (22C) and someone (e.g. Wife) changes it to 22.5C using HA, then if the mode is change to Away in HA, the MDT actuator resets the Comfort temperature back to 22C and then reduces it with for example 2C. This way, the result is always 20C of Away mode is activated.
Let me know if you do not know how to enable that using ETS. I can send you a screenshot.
Unfortunately, when in night/away mode, the actual setpoint is calculated by distracting the reduction value by the unit. So… If is set the new target temperature e.g. to 18 degrees from HASS, while the heating mode is night, the MDT takes on the value 16 degrees, as I have a 2 degree night reduction.
But this is not true right? If the mode is set, only then the reduction preset in the MDT is used to reduce the Comfort temperature. After that, you can set a different temperature for the selected mode in HA.
My KNX underfloor heating works flawlessly in HA. I have 4 (1 for every floor): MDT AKH-0400.02 Heating actuator 4-fold, 2TE,24/230VAC
Screenshots from one of the Actuators:
Setup general:
Hello @Tinus / Martijn, Thanks for the very valuable feedback!
Using the setpoint_shift instead of the target_temperature did the trick!
Sending the temperature this way probably causes a relative change instead, which solves the dissonance between the actual and the comfort setpoint!
I created that card myself. All other available cards are not really useful for a underfloor (KNX) heating. It is fairly simple. Just copy-past my code in HA… And, of course, you will need the following from HACS:
Thanks Martijn! Very interesting.
Indeed, I am in the same situation, using underfloor heating with KNX. Time to have a look and play around with some customisation. It sure beats my current proof of concept to track my valves. (which are actually just switching actuators controlled by 1 bit object from the central control units)
I am tech savvy and experienced with PHP, but HASS framework and python are new to me, but very much willing to learn. I already had a look at the code for the climate entity on GitHub, but could not identify at first sight the function that processes a setpoint temperature update..