Toggle between target_temperature_state_address and target_temperature_address

[Olum-hack]

Description of problem:
If I set the temperature with HA everything is working fine.
If I set the temperature with other KNX devices with the GA 4/2/25 (1-Bit Shift) it is not shown correct.
The setpoint comfort is remaining and actual setpoint is changing to the new value. I can understand the KNX behavior.
But why the the xknx at HA using the target_temperature_address as input?
I think it should only be a input if no target_temperature_state_address is set.
The target_temperature_state_address should always be the main information.

• using xknx standalone
• [ X] using Home-Assistant knx integration

Version information:

• xknx / Home-Assistant release with the issue: 2022.11.1
• last working xknx / Home-Assistant release (if known):

KNX installation:
MDT Heat Actor AKH-0800.02

Problem-relevant configuration.yaml entries (fill out even if it seems unimportant):

• name: "OG.Eltern Bad.Heizung"
  temperature_address: '4/2/20'
  target_temperature_address: '4/2/21'
  operation_mode_state_address: '4/2/23'
  target_temperature_state_address: '4/2/24'
  temperature_step: 0.5

Diagnostic data of the config entry (only when Home Assistant is used)

Traceback (if applicable):

[marvin-w]

1 bit setpoint shift is not supported by XKNX as it is something proprietary from MDT.

From the docs:

setpoint_shift_mode allows the two following DPTs to be used:

DPT6002 (for 1 byte signed integer)
DPT9002 (for 2 byte float)

You can change the setpoint shift type in the Application program. I have the same device and everything works perfectly :).

[farmio]

I think it should only be a input if no target_temperature_state_address is set.
The target_temperature_state_address should always be the main information.

These are treated equally (in a non-setpoint-shift configuration). The last received value updates the Climate objects value.
If your actuator doesn't actively send a new value to one of these addresses we can't know the target temperature was changed.

[Olum-hack]

The topic is not how to set the temperature.

There are two variables target_temperature_address and target_temperature_state_address.
I thing they should not be equally. If the state parameter is available it should only lisen to that parameter.

[farmio]

Would this even solve the issue?
If you start at 20° and set up to 21 by 1bit, then send 22 to the temperature address - does that clear the 1K you shifted by 1bit or will it add to 23°?

[farmio]

Why is it even showing wrong? When you shift temp the last received value should be from state_address, not from target_temperature_address, isn't it?

[Olum-hack]

Why is it even showing wrong? When you shift temp the last received value should be from state_address, not from target_temperature_address, isn't it?

That is exactly my problem. It always takes the last received value of both. You can see it at the purple chart.

After setting the temperature in HA the shift is removed.

[farmio]

It doesn't make sense to me.
If the shift is removed (internally on the actuator) on receiving a new value on target_temperature_address then that new value is exactly the current target.
If this was not the case, the actuator should send a new value on target_temperature_state_address considering the shift when target_temperature_address was changed, shouldn't it? Does it?

When there is a shift and no new value received on target_temperature_address but only on target_temperature_state_address then target_temperature_state_address is our new target.

So under what circumstances can there be a new value on target_temperature_address, but no update on target_temperature_state_address?
Or even worse, a difference between target_temperature_address and target_temperature_state_address parameters without the actuator sending an update of the latter?

To be honest, I'm hesitant to change this because there is only a single (discontinued) device having one specific setting known to not work with our current implementation. And this specific setting is imho not sticking to KNX specifications. All other devices (and this very device with different settings) seem to work just fine.

[farmio]

Hm... thinking about that, there is a second type of controller not being supported well.
Some can only change temperature of comfort mode, other modes are derived from that with a fixed offset.
So eg.

comfort target = 21
night offset = -3
resulting target state = 18

That is in many kinds the same problem as your controller has: the actual target_temperature_address has an unknown offset from the current target_temperature_state_address. And if we want to change the current target temperature (considering current mode / 1bit-shift) we have to change target_temperature_address by new_value - offset. Imho that is incompatible with current implementation so it would need a new Climate device class in xknx and an option in HA to select which should be used (I haven't completely thought that through though and have none of these controllers to test it locally).

See #1033

[Olum-hack]

Thank you for your help. I was not at home for some days but I think I found a workaround for that topic.
I send a update every 5 minutes for the two parameters from the KNX controller.
Now I changed it. I only send the temperature state every 5 Minutes.

So if the KNX device is not sending the value, I can't see a toggle at HA.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please make sure to update to the latest version of xknx (or Home Assistant) and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.