MDT Central Operation Unit - Target temperature reduction

[GeryDk (Gery)]

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

Info MDT device:
https://www.mdt.de/en/products/product-detail/sensors/assortment-glas/glass-central-operation-unit-smart.html

[farmio (Matthias Alphart)]

Hi !

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.

See Climate temperature change issues · Issue #1033 · XKNX/xknx · GitHub and the other reference issue.

[farmio (Matthias Alphart)]

Or just use a different mode on the actuator - with separate hvac-mode setpoints.

[GeryDk (Gery)]

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)

[GeryDk (Gery)]

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

[Tinus]

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.

Martijn

[farmio (Matthias Alphart)]

Right, you can just use a sensor to display current setpoint temperature then (maybe use it in a custom card like mushroom).

@GeryDk

but could not identify at first sight the function that processes a setpoint temperature update.

Yeah, knx climate is not really the most beginner friendly platform, I’m afraid
this in HA https://github.com/home-assistant/core/blob/b525259878233fbf355fa2ca1f20358f4c9810df/homeassistant/components/knx/climate.py#L182 calls this

XKNX/xknx/blob/189b8ecd78493ff297806b2c000b89a7506fbeda/xknx/devices/climate.py#L195

@Tinus

Why not enable the option in MDT to reset setpoint after HVAC mode change.

Changing the temperature when not in comfort mode would still result in a wrong value since the deviation has to be accounted for.

[Tinus]

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:

Channel:

Controller:

My KNX config in HA:

    - name: mf_living
      temperature_address: 3/0/80
      temperature_step: 0.5
      target_temperature_state_address: 3/1/80
      setpoint_shift_address: 3/2/80
      setpoint_shift_state_address: 3/2/80
      operation_mode_address: 3/3/80
      operation_mode_state_address: 3/3/81

The only thing I had to set manually using ETS is the read flag for the Setpoint shift state temperature (in my config: 3/2/80).

And this I made in HA frontend to control the Heating (controlling the actuator from the screenshots and configuration above):

Lovelace KNX Thermostat (yaml)

Requirements (HACS):

• Mushroom
• Card-Mod
• Vertical-Stack-In

type: custom:vertical-stack-in-card
cards:
  - type: horizontal-stack
    cards:
      - type: custom:mushroom-template-card
        entity: climate.mf_living
        primary: Living room
        secondary: >-
          {{ states('sensor.mf_living_temperature') }} °C ({{
          states('sensor.mf_living_valveposition') }}%)
        icon: mdi:thermostat
        icon_color: |
          {% if is_state('sensor.mf_living_valveposition', '0') %}
              grey
          {% else %}
              deep-orange
          {% endif %}
        badge_icon: |
          {% if 'Locked' in states('sensor.mf_living_diagnosis') %}
              mdi:lock
          {% endif %}
        badge_color: red
        tap_action:
          action: more-info
        hold_action:
          action: none
        double_tap_action:
          action: none
      - type: custom:mushroom-climate-card
        entity: climate.mf_living
        icon_type: none
        primary_info: none
        secondary_info: none
        show_temperature_control: true
  - type: horizontal-stack
    cards:
      - type: custom:mushroom-chips-card
        alignment: end
        style: |
          ha-card {
            --chip-border-width: 0px;
            --chip-box-shadow: none;
            --chip-background: none;
            --chip-spacing: none;
            --chip-height: 40px;
            margin-top: 0px;
            margin-right: 5px;
          }
        chips:
          - type: template
            content: Comfort
            icon: mdi:home-account
            icon_color: >-
              {% set preset_mode = state_attr('climate.mf_living',
              'preset_mode') %}   {% if preset_mode == 'comfort' %} orange {%
              else %} grey {% endif %}
            tap_action:
              action: call-service
              service: climate.set_preset_mode
              data:
                preset_mode: comfort
              target:
                entity_id: climate.mf_living
          - type: template
            content: Economy
            icon: mdi:leaf
            icon_color: >-
              {% set preset_mode = state_attr('climate.mf_living',
              'preset_mode') %}   {% if preset_mode == 'away' %} green {% else
              %} grey {% endif %}
            tap_action:
              action: call-service
              service: climate.set_preset_mode
              data:
                preset_mode: away
              target:
                entity_id: climate.mf_living
          - type: template
            content: Sleep
            icon: mdi:weather-night
            icon_color: >-
              {% set preset_mode = state_attr('climate.mf_living',
              'preset_mode') %}   {% if preset_mode == 'sleep' %} blue {% else
              %} grey {% endif %}
            tap_action:
              action: call-service
              service: climate.set_preset_mode
              data:
                preset_mode: sleep
              target:
                entity_id: climate.mf_living

(In the frontend I renamed mode ‘Away’ to ‘Economy’ and ‘Night’ to ‘Sleep’).

Hope this helps!

Martijn

[GeryDk (Gery)]

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!

[GeryDk (Gery)]

@Tinus

image892×210 10.4 KB

What card did you use for this interface? It’s nice!
The default half-circle slider is not so precise when moving.

[Tinus]

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:

• Mushroom
• Card-Mod
• Vertical-Stack-In

You will also need the valve position from KNX.

Here is the code:

Lovelace KNX Thermostat

type: custom:vertical-stack-in-card
cards:
  - type: horizontal-stack
    cards:
      - type: custom:mushroom-template-card
        entity: climate.mf_living
        primary: Living room
        secondary: >-
          {{ states('sensor.mf_living_temperature') }} °C ({{
          states('sensor.mf_living_valveposition') }}%)
        icon: mdi:thermostat
        icon_color: |
          {% if is_state('sensor.mf_living_valveposition', '0') %}
              grey
          {% else %}
              deep-orange
          {% endif %}
        badge_icon: |
          {% if 'Locked' in states('sensor.mf_living_diagnosis') %}
              mdi:lock
          {% endif %}
        badge_color: red
        tap_action:
          action: more-info
        hold_action:
          action: none
        double_tap_action:
          action: none
      - type: custom:mushroom-climate-card
        entity: climate.mf_living
        icon_type: none
        primary_info: none
        secondary_info: none
        show_temperature_control: true
  - type: horizontal-stack
    cards:
      - type: custom:mushroom-chips-card
        alignment: end
        style: |
          ha-card {
            --chip-border-width: 0px;
            --chip-box-shadow: none;
            --chip-background: none;
            --chip-spacing: none;
            --chip-height: 40px;
            margin-top: 0px;
            margin-right: 5px;
          }
        chips:
          - type: template
            content: Comfort
            icon: mdi:home-account
            icon_color: >-
              {% set preset_mode = state_attr('climate.mf_living',
              'preset_mode') %}   {% if preset_mode == 'comfort' %} orange {%
              else %} grey {% endif %}
            tap_action:
              action: call-service
              service: climate.set_preset_mode
              data:
                preset_mode: comfort
              target:
                entity_id: climate.mf_living
          - type: template
            content: Economy
            icon: mdi:leaf
            icon_color: >-
              {% set preset_mode = state_attr('climate.mf_living',
              'preset_mode') %}   {% if preset_mode == 'away' %} green {% else
              %} grey {% endif %}
            tap_action:
              action: call-service
              service: climate.set_preset_mode
              data:
                preset_mode: away
              target:
                entity_id: climate.mf_living
          - type: template
            content: Sleep
            icon: mdi:weather-night
            icon_color: >-
              {% set preset_mode = state_attr('climate.mf_living',
              'preset_mode') %}   {% if preset_mode == 'sleep' %} blue {% else
              %} grey {% endif %}
            tap_action:
              action: call-service
              service: climate.set_preset_mode
              data:
                preset_mode: sleep
              target:
                entity_id: climate.mf_living

Martijn

[Tinus]

Maybe this one you also like . It creates a sensor that returns the number of heatings valves open (rooms that are currently being heated:

 - platform: template
   sensors:
      number_of_floorheating_on:
        value_template: >
          {{ states.sensor | selectattr("state", 'is_number') | selectattr('name','search', 'Valve position') | selectattr('state','ne', '0') | list | count }}
        icon_template: mdi:fire-circle

In my HA interface it is displayed then as follows:

(One door open, 6 lights on, 2 windows open and 5 rooms are being heated)

Or even by rooms (if you assigned the climate entities to the correct area in HA):

  - platform: template
    sensors:
      number_of_floorheating_on_main_floor:
        value_template: >
          {{ states.sensor | selectattr("state", 'is_number') | selectattr('name','search', 'Valve position') | selectattr('state','ne', '0') | map(attribute='entity_id') | map('area_name') | select('in', ['Entrance', 'Guest Toilet', 'Kitchen', 'Dining Area', 'Living Area']) | list | count }}
        icon_template: mdi:fire-circle

(Clicking on that chip disables the heating for that entire floor. In this example Basement heating is disabled)

Have fun
Martijn

[GeryDk (Gery)]

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)

[seriallnumber]

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..

.