KNX Climate Control - Can only decrease. Increase breaks the GUI

[oasacorp]

HA version 0.69.1 using hassbian

I cannot increase the temperature through HA. The thermostat is on KNX bus. However I can decrease the temperature without any problem. I can increase/decrease the temperature through ETS or physically through thermostat. Through HA, I can only decrease. When I increase I am greeted with this picture:

My configuration is as follows:

knx:

climate:

platform: knx
name: Bedroom1
temperature_address: ‘0/0/4’
target_temperature_address: ‘0/0/21’

Tail Log dump: https://hastebin.com/hutoxoyite.coffeescript

When I tail -f the log, I actually see no log created when I click UP immediately. So I do not think the log is of relevance. (I have enabled logger in my config)

Thanks.

[oasacorp]

I used "Call Service" to set temperature higher than the current temperature and it seem to work. All of this clearly indicates that the problem is with UI. (AFAIK). Please advise.

[trisk]

Looks like https://github.com/XKNX/xknx/blob/master/xknx/devices/climate.py#L203 returns None and causes the max_temp entity attribute to be null, unless the xknx object's group_address_setpoint_shift is assigned to the correct value for the device.
The climate.knx platform has:

homeassistant/components/climate/knx.py:CONF_SETPOINT_SHIFT_ADDRESS = 'setpoint_shift_address'
homeassistant/components/climate/knx.py:    vol.Optional(CONF_SETPOINT_SHIFT_ADDRESS): cv.string,
homeassistant/components/climate/knx.py:        group_address_setpoint_shift=config.get(CONF_SETPOINT_SHIFT_ADDRESS),

There is an actual bug in the platform here since the configuration option either should not be optional, or a default value needs to be supplied for CONF_SETPOINT_SHIFT_ADDRESS or max_temp.

[oasacorp]

I had reported the same in DiscordApp. You can verify this by setting the max_temp state and trying to increase the temperature. Thanks for pointing out the
return (self.target_temperature.value - self.setpoint_shift.value * self.setpoint_shift_step + self.setpoint_shift_max * self.setpoint_shift_step)

But if you look at the https://github.com/XKNX/xknx/blob/4e7f30637cb4e2235fc00e5030578510c3b28242/xknx/devices/climate.py#L21 , you can see that the default values are set and later initialized at L32. I will however manually assign these and check if it works.

[trisk]

group_address_setpoint_shift defaults to None, and if you look at https://github.com/XKNX/xknx/blob/4e7f30637cb4e2235fc00e5030578510c3b28242/xknx/devices/climate.py#L81 self.setpoint_shift is assigned by querying the device using that.

initialized_for_setpoint_shift_calculations returns False if self.setpoint_shift.initialized and self.setpoint_shift.value are not set.

[oasacorp]

I left the town. Will check during the weekend. So according to you if I set the setpoint_shift.value,max, and step - it should work right?

[trisk]

You need to set setpoint_shift_address. That is where the other values are read from.

[oasacorp]

So I set everything as per below:

knx:

climate:
  - platform: knx
    name: Test PB
    temperature_address: '0/0/1'
    target_temperature_address: '0/0/2'
    setpoint_shift_address: '0/0/2'
    operation_mode_address: '0/0/3'
    setpoint_shift_step: 1.0
    setpoint_shift_max: 10
    setpoint_shift_min: -10

Still the same result. I can still decrease and the step decrease is in 1 degree instead of 0.5 confirming that my config is executed. But my logfile shows error in the same.

2018-05-25 10:43:58 ERROR (MainThread) [xknx.log] Error while syncing device: <CouldNotParseTelegram description="payload invalid" device_name="Test PB" group_address="0/0/2" payload=""/>
2018-05-25 10:45:52 ERROR (MainThread) [homeassistant.core] Invalid service data for climate.set_temperature: expected float for dictionary value @ data['temperature']. Got None
2018-05-25 10:45:54 ERROR (MainThread) [homeassistant.core] Invalid service data for climate.set_temperature: expected float for dictionary value @ data['temperature']. Got None

I temporarily fixed this by editing
/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/climate and setting the function to return 65.

I hope this is fixed in the future version.

[trisk]

It appears either your setpoint_shift_address or target_temperature_address is not correct for the device. They cannot be the same address.

[oasacorp]

Unfortunately they are same. It works correctly with the modified code with the config intact.

[trisk]

@oasacorp That is not correct, they are totally different objects and have different addresses. However, some devices apparently do not support a setpoint shift according to http://www.elanportal.com/supportdocs/catalog/KNX%20Climate%202.pdf

[derandiunddasbo]

Same behavior here with a Zennio HeatingBox: Decreasing the temperature via GUI works fine, but increasing breaks the GUI. I.e. the target value disappears and can only be restored by switching to another operation mode. Increasing the temperature via service call works fine.

I also added setpoint_shift_address mentioned in another comment, but it doesn't change anything:

climate:
   - platform: knx
     name: DG Bad Temperatur Raum
     temperature_address: '5/4/0'
     target_temperature_address: '5/4/1'
     setpoint_shift_address: '5/4/2'
     operation_mode_address: '5/4/3'
     operation_mode_state_address: '5/4/4'

I'm still not sure, if '5/4/2' is the correct KNX objekt for setpoint_shift_address. Problem is, there are no other two byte objects exposed by the device and the others seem to be configured correctly for the component.

I don't want to rule out categorically that this maybe a misconfiguration in HA or KNX (ETS) for that device, but I really don't know, how to change the device config in HA or ETS to avoid this behavior.

As changing the temperature via service call is working fine, obviously there is a way to control the target temperature of devices without the setpoint_shift_address (properly) configured.

[trisk]

@cian does xknx need to be updated to support temp min/max properly when the setpoint shift address isn't available?

[mag2bue]

I have exactly the same problem.

If I know correctly, it's because the interface communicates with 1 byte. (setpoint_shift) However, many actuators can not do this. 2Byte could be the solution. This should work with any hardware.

[Melmann]

I have exactly the same problem with a Zennio Quad thermostat.

In ETS, I haven't an object for setpoint_shift_address_state and the object for setpoint_shift_address is on 2 bytes and not readable.

@derandiunddasbo , can you give us an example of your service call to change the temperature ?
@oasacorp , can you detail the modification in the climate.py file ?

Thanks all for your help.

[derandiunddasbo]

@derandiunddasbo , can you give us an example of your service call to change the temperature ?

@Melmann: Nothing fancy, I'm just using the "Services" dev tool from the HA UI for the service call:

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[derandiunddasbo]

The behavior is still the same with the current stable version 0.80.3 and there seems to be no fix for #14531 in the currents betas as well.

[markuska00]

I also have the same problem.
Increasing breaks the ui

[mag2bue]

Version 82.0 same problem :-(
Increasing the temperature is not possible

[derandiunddasbo]

Just a side note: Increasing the target temperature of a KNX climate component affected by this bug is working fine with a Lovelace Thermostat Card.

Unfortunately, the Lovelace card currently doesn't support changing the operation mode for a knx climate component and is as of now no full replacement for a regular climate entity item.

[moustic999]

It is probably a bug in the UI part, maybe this issue should be moved to the UI issur tracker ?

[trisk]

This is not a UI bug. The underlying library is not capable of determining the max_temp value required for raising the temperature.

[derandiunddasbo]

Uhm - that raises the question, what's the purpose of determining the max_temp value for increasing the temperature?

While the (classic UI) climate entity item wants to use the max_temp value, obviously it isn't required, as increasing the temperature via service call or with the Lovalace UI is working fine.

[marvin-w]

I'm having the exact same issue with a KNX Climate component. I'm only using the lovelace thermostat component.

I've set everything in the config as expected but still the UI just looks weird although the updating with the thermostat works, but the operation modes do not.

  - platform: knx
    name: xxx
    operation_mode_frost_protection_address: '3/1/12'
    temperature_address: '3/1/13'
    operation_mode_comfort_address: '3/1/14'
    operation_mode_night_address: '3/1/15'
    target_temperature_address: '3/1/16'

[marvin-w]

I've added a PR (XKNX/xknx#158) to allow overriding the max and min temperature for devices that do not have a setpoint_shift_address.

This should fix the issue with increasing the temperature, but you need to set the new max_temp and min_temp. I'm also curious why decreasing worked as the min_temp also returns None if no setpoint_shift_address is defined.

I also added a mapping between the KNX operation modes and the potential operation modes used in the frontend which will allow us to implement the operation change in the lovelace UI in a next step.

[mgies]

I have the exact same problem. It even persists in HA 0.85.0, so please reopen the issue.

I've read through all the comments, but there seems to be no explanation, why the temperature can be reduced, but not raised. I have not defined setpoint_shift_step / setpoint_shift_max / setpoint_shift_min. If that was the trouble, then turning down the temperature shouldn't work either...

My config looks like this:

• platform: knx
  name: Wohnzimmer.Heizung
  temperature_address: '1/0/5'
  setpoint_shift_address: '1/0/10'
  target_temperature_address: '1/0/6'
  operation_mode_address: '1/0/8'

[Cadish]

I have the exact same problem. It even persists in HA 0.85.0, so please reopen the issue.

I've read through all the comments, but there seems to be no explanation, why the temperature can be reduced, but not raised. I have not defined setpoint_shift_step / setpoint_shift_max / setpoint_shift_min. If that was the trouble, then turning down the temperature shouldn't work either...

My config looks like this:

• platform: knx
  name: Wohnzimmer.Heizung
  temperature_address: '1/0/5'
  setpoint_shift_address: '1/0/10'
  target_temperature_address: '1/0/6'
  operation_mode_address: '1/0/8'

+1

[marvin-w]

As denoted in #14531 (comment) please set the max_temp attribute on your climate device if your device doesn't support setpoint shift calculations to be able to increase the temperature.

- platform: knx
  name: Wohnzimmer.Heizung
  temperature_address: '1/0/5'
  setpoint_shift_address: '1/0/10'
  target_temperature_address: '1/0/6'
  operation_mode_address: '1/0/8'
  max_temp: 32.0

Works perfectly fine for me with 0.85.0.

[mgies]

I just tried 'max_temp: 32.0' - same problem.

It also still doesn't answer why turning the temperature down works...

[mgies]

sorry, this has to be a different issue. using the lovelace-ui preview i can turn the temp up and down flawlessly and it even shows the change when i return to the regular UI.

I have now tried the settings posted above and I have even tried reconfiguring my heating from a 1bit shiftpoint format to 2byte with exactly the same result: can decrease temp but not increase...

EDIT:
I have checked the packets sent by HA on the knx bus. It does not send an impulse to increase/decrease like +/-, nor does it send a step width like +/-0,5K. It simply sends a new value to my 'target_temperature_address: '1/0/6''. The regular UI does this only when decreasing. On increase, there are no knx packets logged. The lovelace-ui does this in both directions. What I have found out, though, is that my heating control completely ignores this temperature value, since it expects a 1bit packet on setpoint_shift_address: '1/0/10' and afterwards confirms the new target temp on target_temperature_address: '1/0/6'

This makes no sense: HA seems not to make use of setpoint_shift_address at all...

[derandiunddasbo]

It simply sends a new value to my 'target_temperature_address: '1/0/6''. [...] What I have found out, though, is that my heating control completely ignores this temperature value

Yep, doesn't make sense for me as well. I asked about this confusing behavior and usage of the target_temperature_address attribute on the community forum, but didn't get any reactions yet:

https://community.home-assistant.io/t/knx-climate-target-temperature-confusion/84832

[mgies]

With a service call it works in the manner HA is currently handling it: climate.set_temperature

The thing is though: my knx heating controller does not accept this. HA thinks it has successfully changed the target temperature, but when i re-read it from the knx controller it returns the previous value.

My controller expects either a 1bit +/- value or a 2byte step value like +/-0,5K. The calculation of the new target temperature is done in my controller and then the target-temperature is sent to the target-temp KNX-group. So HA should only send a shift command and then wait for the response on target-temp KNX group to be sure the target temp has actually been changed.

But HA seems to be completely lacking a climate.shift_temperature service. It seems to me the setpoint_shift_address: '1/0/10' config is completely useless like this.

So there seem to be two things going wrong:

1. When increasing the temp in the GUI, nothing happens. No packets on the KNX bus. Seems like a GUI probelm to me. Maybe the service is not called.
2. When decreasing the temp in the GUI, HA sends a new target temp, which is not acceptet by my controller. Seems like a HA problem: wrong behavior for KNX usage.

[derandiunddasbo]

The thing is though: my knx heating controller does not accept this.

Yes, and why should it. :-) I'm quite sure, the root of this problem is the knx climate component (mis-) using a read only group address for writing new temperature values.

HA thinks it has successfully changed the target temperature, but when i re-read it from the knx controller it returns the previous value.

This behavior doesn't seem to be consistent for different knx devices. My zennio devices f.e. accept the new value on the read group address and even return it, when re-read. But the value is still ignored, as the heating valves don't move, even if I set very high or low temperatures. When writing the new value to the target temperature write GA, it is accepted and correctly returned on both the write and the read GA.

Of course this is not the devices fault, as one obviously can't expect any correct and reliable results, when writing anything to a read-only address.

When increasing the temp in the GUI, nothing happens. No packets on the KNX bus. Seems like a GUI probelm to me. Maybe the service is not called.

As far as I understood the discussion above, the service is indeed called, but since the new target temperature is calculated using the setpoint_shift_address value in the classic UI, the calculation is failing with an undefined exception, if this attribute is not configured.

The lovelace climate card seems to calculate the target temperature differently, i.e. without using the setpoint shift group address. Thus, increasing the temperature value is working fine in this case (*). This discussion is still missing an explanation, why the temperature calculation in the classic UI depends on a setpoint_shift_address value, while the climate card in the lovlace UI doesn't need it.

(*) Only in the UI of course, because of writing the new value to the wrong GA, as described above.

[derandiunddasbo]

This should fix the issue with increasing the temperature, but you need to set the new max_temp and min_temp. I'm also curious why decreasing worked as the min_temp also returns None if no setpoint_shift_address is defined.

I'm curious as well. :-) Today I configured max_temp for the climate entities. The classic UI is working fine now. And the lovelace card is working fine as before.

The issue that the new target temperature is written to a read only group address still prevents the change to actually become effective on my zennio devices, but for this I opened a separate issue today: #20106

[mgies]

I think this still is an issue...

I have set the max/min_temp accordingly:

climate:
  - platform: knx
    name: Wohnzimmer
    temperature_address: '1/0/5'
    setpoint_shift_address: '1/0/10'
    target_temperature_address: '1/0/6'
    operation_mode_address: '1/0/8'
    max_temp: 32.0
    min_temp: 8.0

Allright, now it seems like I can turn up the temperature up in the GUI.

BUT:

1. This does not answer the question, why the temp can be turned down, but not up, when not setting min_temp and max_temp. This makes no sense to me.
2. There is a new target temperature written to 'temperature_address' (a read only group). My device does not accept this!
3. My KNX device does not even expect/accept a new target temperature at all. I simply expects a shift impulse on 'setpoint_shift_address'. HA does not need to do any calculation, it's simply done in my KNX HVAC controller. So there should be no need for any min/max values, if HA would only have to send 0 or 1. My HVAC controller knows all the values, calculates the new target temp and then sends it to the heating valve...

Maybe it helps to know which HVAC controller I am using:
SCN-RT6REG.01
https://www.mdt.de/EN_Temperature_Controllers.html

[spfuu]

I think this still is an issue...

I have set the max/min_temp accordingly:

climate:
  - platform: knx
    name: Wohnzimmer
    temperature_address: '1/0/5'
    setpoint_shift_address: '1/0/10'
    target_temperature_address: '1/0/6'
    operation_mode_address: '1/0/8'
    max_temp: 32.0
    min_temp: 8.0

Allright, now it seems like I can turn up the temperature up in the GUI.

BUT:

1. This does not answer the question, why the temp can be turned down, but not up, when not setting min_temp and max_temp. This makes no sense to me.
2. There is a new target temperature written to 'temperature_address' (a read only group). My device does not accept this!
3. My KNX device does not even expect/accept a new target temperature at all. I simply expects a shift impulse on 'setpoint_shift_address'. HA does not need to do any calculation, it's simply done in my KNX HVAC controller. So there should be no need for any min/max values, if HA would only have to send 0 or 1. My HVAC controller knows all the values, calculates the new target temp and then sends it to the heating valve...

Maybe it helps to know which HVAC controller I am using:
SCN-RT6REG.01
https://www.mdt.de/EN_Temperature_Controllers.html

Same here. Bug still exists.