KNX Climate heating actuator MDT v3

Configuration
1

Hi,
as many before, I try to get KNX climat running in combination with MDT heating actuator v3.

I have been reeding so far:

As mentioned in the lower section of the above topic, v3 of the MDT actuators have a different behavior compared to the v3 ones, opening a new topic was suggested.

Maybe someone can help me to get it running, as I failed so far. Within KNX itself, everything is running fine, just the integration in HA is not running so far.

My current ETS config with group variables (not all used, some only for testing issues):

etsConfig
etsConfig1512Ă—595 77.1 KB

First attempt, using target_temperature_address:

climate:
  - name: "Ost EG AZi"
    temperature_address: "12/5/1" # Ist Wert
    target_temperature_address: "12/5/2"
    target_temperature_state_address: "12/5/4" # Aktueller Sollwert
    temperature_step: 0.5
    operation_mode_address: "10/5/6" # Betriebsartvorwahl
    operation_mode_state_address: "10/5/7" # DPT_HVAC Status
    min_temp: 15
    max_temp: 28

Result: Object drops error “Not available” (this error always occurs as soon as target_temperature_address is set

Second attempt:

climate:
  - name: "Ost EG AZi"
    temperature_address: "12/5/1" # Ist Wert
    active_state_address: "12/5/3" # Ventilzustand
    setpoint_shift_address: "12/5/0" # Sollwertverschiebung (lesend) :: KNX address for setpoint_shift
    setpoint_shift_state_address: "12/5/6" # Status Stellwert :: KNX address for reading setpoint_shift
    setpoint_shift_max: 3
    setpoint_shift_min: -3
    target_temperature_state_address: "12/5/4" # Aktueller Sollwert
    temperature_step: 0.5
    operation_mode_address: "10/5/6" # Betriebsartvorwahl
    operation_mode_state_address: "10/5/7" # DPT_HVAC Status
    min_temp: 15
    max_temp: 28

Result: Object is shown correctly, displays all values correctly, but a change of the value has no effect

When changing (moving the bullet on the gauge) following value is written to the bus:

As the setpoint shift is a 1 bit value this can not work.
Can anyone give me a hint, where to find my mistake?

Best regards

2

New user, my pictures did not work…
Result first attempt:
result1

3

Second attempt:
result2

4

Monitor:

Monitor
Monitor1530Ă—57 9.14 KB

5

Hi :wave:!

You could use a different method than 1bit for changing the setpoint in the actuator.

The attempt with target_temperature_address looks ok. I wonder why this doesn’t work. Can you post a ETS Monitor when HA starts with that and HAs log output with debug mode for xknx.telegram?

6

Thanks for the feedback!

I used following configuration:

  - name: "Ost EG AZi"
    temperature_address: "12/5/1" # Ist Wert
    target_temperature_address: "12/5/2"
    target_temperature_state_address: "12/5/4" # Aktueller Sollwert
    temperature_step: 0.5
    operation_mode_address: "10/5/6" # Betriebsartvorwahl
    operation_mode_state_address: "10/5/7" # DPT_HVAC Status
    min_temp: 15
    max_temp: 28

The generated logs:

2022-03-25 10:17:19 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.0.18" destination_address="14/5/11" payload="<GroupValueWrite value="<DPTArray value="[0xc,0x29]" />" />" />
2022-03-25 10:17:36 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.0.40" destination_address="13/5/3" payload="<GroupValueWrite value="<DPTBinary value="0" />" />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="1.0.2" destination_address="10/5/7" payload="<GroupValueRead />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.0.8" destination_address="10/5/7" payload="<GroupValueResponse value="<DPTArray value="[0x1]" />" />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="1.0.2" destination_address="12/5/1" payload="<GroupValueRead />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="1.0.2" destination_address="12/5/4" payload="<GroupValueRead />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.0.7" destination_address="12/5/1" payload="<GroupValueResponse value="<DPTArray value="[0xc,0x29]" />" />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="1.0.2" destination_address="12/5/51" payload="<GroupValueRead />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.0.8" destination_address="12/5/4" payload="<GroupValueResponse value="<DPTArray value="[0xc,0x1a]" />" />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="1.0.2" destination_address="12/5/54" payload="<GroupValueRead />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.0.10" destination_address="12/5/51" payload="<GroupValueResponse value="<DPTArray value="[0x7,0x3a]" />" />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="1.0.2" destination_address="12/5/50" payload="<GroupValueRead />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.0.8" destination_address="12/5/54" payload="<GroupValueResponse value="<DPTArray value="[0x6,0x40]" />" />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="1.0.2" destination_address="12/5/101" payload="<GroupValueRead />" />
2022-03-25 10:17:48 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.0.21" destination_address="12/5/101" payload="<GroupValueResponse value="<DPTArray value="[0x7,0x26]" />" />" />

Group Monitor:

Monitor
Monitor1292Ă—172 96.6 KB

In my eyes this does not look too bad… but the card is still dislays the “Not available” view…

7

After analysing the logs it seemed, that the mistake is located somewhere else, and I found where!

Within the config I define names, e.g. knx.climate.name: “Ost EG AZi”, but HA generates many different entities, like

  • climate.ost_eg_azi
  • climate.ost_eg_azi_2
  • climate.ost_eg_azi_3
  • […]
  • climate.ost_eg_azi_8

An some of them work fine, just as expected! Where/how can I have a clother look what’s behind this entites, and where/how can I delete the ones not working?

8

Here: Open your Home Assistant instance and show your state developer tools.

I’m not 109% sure, but think HA does clean up orphaned entities at some point.

Whenever you change a GA that is used for unique_id a new entity is created. See KNX - Home Assistant

1 Like
9

Found, delete unavailable, everything working fine now, thanks!