Better climate support for HASS

[Julius2342]

3/4 of all feedback i got wished better climate support. Looks like we need better climate support.

I suggest the following configuration:

climate:
   - platform: xknx
     name: Kitchen.Temperature
     temperature_address: '6/2/1'
     setpoint_address: '6/2/2'

     frost_protection_address: '6/2/3'
     comfort_address: '6/2/4'
     night: '6/2/5'
     standby: '6/2/6'
     operating_mode: ''6/2/7'

Within HASS [frost,comfort,night,address] will show up as dropdown for "operation_modes".

[mag2bue]

for each mode -> comfort, frost and away, I have a seperate KNX adress

[resoai]

http://www.knx.org/fileadmin/template/documents/downloads_support_menu/KNX_tutor_seminar_page/Advanced_documentation/Heating_E1211a.pdf

According to this document there are following operating modes:

• Frost/heat protection
• Comfort
• Night
• Standby

To be honest I would think that relevant controls should simply appear if there is an "address" set in order to not over-complicate things. This would make a config for my place with 18 thermostats controls barely readable.

[Julius2342]

hmmm.... :) you are about to convince me....

[resoai]

To be honest I know very little about how thermostats work in KNX and am simply making assumptions :) Perhaps we could have a look at the implementation in OpenHAB? I'm sure they have it figured out.

[Julius2342]

is there any knx representation of "away" ?

And do these modes exclude each other? (So can it be "night" and "comfort" in parallel ?) [Just realized p. 18 explains this ... ]

[Julius2342]

The problem i have, i do not fully understand this setpoint thing within KNX.

As far as i see it:

• There is a setpoint temperature, which is the temperature under normal conditions. (Sometimes also referred as "basis-setpoint?" )
• But then there are some "modifiers" like comfort which makes it warmer without changing the setpoint?

[resoai]

Yes, they exclude each other, the mode can only be set to one of them. I could not find any mention of "away". Please have a look at the operating manual for a Jung room controller, maybe this would help.

en_4093KRMTSD_V02_10052016_td.pdf

[resoai]

Setpoint shift is basically the deviation (plus or minus) from the base temperature appropriate (set) for the particular operating mode. This is how I understand it.

[Julius2342]

what a terrible concept ...

[Julius2342]

so we should add group addresses for each state and add the exclusiveness-logic on top. Will do :)

[resoai]

It makes a lot of sense actually. You can set the operating mode for the whole house yet you want to keep one room always colder. I know it feels very wrong at first and it took me some time to get used to it.

[resoai]

Unfortunately I don't have ETS software but from I can see from the files left for me from the installer, the "operating mode" is just one address.

[Julius2342]

probably you can encode the modes also in several bits of the same byte

[resoai]

While reading in the KNX manual they call it "Enumerated Types":

05_Interworking_E1209.pdf

Enumerations are used for datapoints with a clearly limited number of values and no
precise hierarchical order. If a datapoint uses an enumerated data type, all possible
states shall be described. If invalid / undefined values are sent, no malfunctions may
occur.
Examples are: Toggling between “Comfort”, “Standby” and “Night” operating modes in
room thermostats.

Perhaps the attached file could help (4.20 Common HVAC Datapoint types)

05_Interworking_E1209.pdf

[mag2bue]

To manage it, we need 3 optional switches. (1bit 0 or 1)

e.g. see page 45-47
German: http://www.mdt.de/download/MDT_THB_Heizungsaktor_02.pdf
English: http://www.mdt.de/download/MDT_TM_Heating_Actuator_02.pdf

In ETS, I need for each 1bit address to put ON/OFF

• comfort
• night
• frost
  -> standby is a status of all -> OFF

[Julius2342]

see my updated suggestion.

[mag2bue]

perfect! :-)

[mag2bue]

@Julius2342

I have technical question:

drop-down: if I select e.g. night - > only "address of night" will be switched ON, all the other are to OFF?
what is the technical background for "operating_mode" heating or cooling?

Or you control it by DPT HVAC Mode 20.102 ? see page 47/48

[resoai]

Guys, this is the actuator you are talking about here, not the RTR which a climate component is. Climate component has to provide a level of abstraction, meaning that user sets a temperature/operating mode/setpoint shift and KNX figures the rest. I have a bunch of actuators for heated floors and KNX decides on the position of the valves etc.

[mag2bue]

correct, totally I control already 16 heaters with OpenHab. The topic about we are talking it not to set the setpoint (This works already perfect in HA) I talking about, is to swich between the status. Like ON / OFF

[resoai]

Setpoint temperature works but not setpoint shift :) I was under the impression that for heaters (ON/OFF) you just use a switch component.

[mag2bue]

the setpoint switch e.g. modus "standby" -5k, "night -3k" you have to setup in ETS.

But we need a solution to change the modus ... in my case, I can setup this in ETS by a simple ON /OFF 1bit or HVAC Mode.

[resoai]

Yes, changing modus (operating_mode) via HVAC mode is a must.

[Julius2342]

Lets also add a group address for AC on/off and Heating on/off

[resoai]

Surely we can do anything but it would be nice to perhaps stick with some sort of standard appropriate to KXN room controller?

[mag2bue]

Standard is perfect. -> HVAC
Sorry, maybe there was as well a misunderstanding from my site.

Looking forward to test the functions

[resoai]

Perhaps I am also not (completely) right since I'm still trying to fully understand how KNX climate works and I don't actually have ETS software. One other (offtopic) cool thing would be to enable multiple group addresses for one switch/light.

OpenHab's implementation is messy yet very flexible.

http://docs.openhab.org/addons/bindings/knx1/readme.html

[Julius2342]

@resoai : KNX itself is just a bus (without any active logic). The control of the valves/etc. is done within climate devices (or thermostats). I for example have GIRA Touch Sensor 3 plus: http://www.gira.com/produkte/abbildungen/zoom1/001223_1384961308.jpg

My original idea was to be open to control the valves via hass itself - e.g. via a complete new component. This then could be much smarter than the small devices on the wall. But the current approach of syncing the flags/values with the climate control, we do at least nothing wrong.

[Julius2342]

@mag2bue : I need your help with these binary states.

@resoai @firefrei : Controlling operation modes via HASS with a combined KNX operation mode object (FrostProtection/Night/Standby/Comfort) already works in my environment. Yay :)

Operation Modes

Did i get this right:

• so you have binary addresses for comfort, frost and away.
• You don't have an dedicated address for standby (i assume this is just all other states switched off).
• For switching to away, i would switch off frost, comfort and switch on away.
• For switching to frost, i would switch off away, comfort and switch on frost.
• For switching to comfort, i would switch off away, frost and switch on comfort.
• For switching to standby i would switch off away, frost and comfort.

Setpoint/Target temperature

Do you (like i have) have also two addresses:

• basis set point address. Read/Write for setting the set point in comfort mode.
• target temperature. Read only, calculated from basis set point and operation mode.

[TinusK]

If I change the config to:

  - platform: xknx
    name: mf_living
    temperature_address: 3/0/70
    target_temperature_address: 3/1/80
    setpoint_address: 3/2/81
    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

I get this in the error log:
2017-10-17 12:08:48 WARNING (MainThread) [xknx.log] Could not read value of <Climate name="mf_living" temperature="<Address str="3/0/70" />/None/<DPTArray value="[0xd,0x0]" />/25.6" target_temperature="<Address str="3/1/80" />/None/<DPTArray value="[0xc,0x33]" />/21.5" setpoint="<Address str="3/2/81" />/None/None/None" setpoint_shift="<Address str="3/2/80" />/<Address str="3/2/80" />/None/None" group_address_operation_mode="<Address str="3/3/80" />" group_address_operation_mode_state="<Address str="3/3/81" />" group_address_controller_status="None" group_address_controller_status_state="None" /> 3/2/81

[TinusK]

With the setpoint_shift addresses set, it looks better:

21.5 degrees is my current setpoint. But what is the 23 degrees? Target Temperature? But the target temperature is 21.5 degrees right? Or do I interpret something different/wrong? Changing the target temperature uses steps of 0.5 degrees which is good but starts at 23 degrees but should actually start at 21.5 degrees....

[resoai]

Also, setponint_address needs to be optional (I can’t test it otherwise). From: TinusK Sent: 17 October 2017 11:27 To: XKNX/xknx Cc: Alexey Ivanov; Mention Subject: Re: [XKNX/xknx] Better climate support for HASS (#48) With the setpoint_shift addresses set, it looks better: 21.5 degrees is my current setpoint. But what is the 23 degrees? Target Temperature? But the target temperature is 21.5 degrees right? Or do I interpret something different/wrong? Changing the target temperature uses steps of 0.5 degrees which is good but starts at 23 degrees but should actually start at 21.5 degrees.... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Julius2342]

Should we do a session on discord this evening (Europe time) to address these issues?

(I was in Canada last week at the tor meeting, so could not really proceed. These things may be addressed within XKNX directly, so it would only be a version bump within HASS)

[TinusK]

I'm not at home at the moment... I do not know if I'm available this evening.

[TinusK]

What is ment with Temperature High and Temperature Low?

[Julius2342]

lets check, ill be around on discord :)

[Julius2342]

@TinusK , @resoai , @twistermcneal : Yesterday evening i started to modify the implementation that it no longer depends on the setpoint address. The setpoint shift will be calculated out of the current target-temperature and the current setpoint shift.

@twistermcneal : we discussed last week if this might cause race conditions, esp when changing operation modes. At least my device immediately sends out a new target temperature after switching modes. We should at least try out - and decide later if we need some fancy "blocking" mechanism which tries to detect if device and component are not in sync.

The new implementation will be:

    @asyncio.coroutine
    def set_target_temperature(self, target_temperature):
        """Calculate setpoint shift shift and send it to  KNX bus."""

        [... removed some checks ...] 

        temperature_delta = target_temperature-self.target_temperature.value
        setpoint_shift_delta = int(temperature_delta/self.setpoint_step)
        setpoint_shift = self.setpoint_shift.value + setpoint_shift_delta
        yield from self.setpoint_shift.set(setpoint_shift)

(I also removed target temperature high/low from HASS component.

At the moment i'm fixing unit tests. Will push a version to a new branch later today.

[TinusK]

We discussed this last night... I do hope you got some sleep 😁

[zimgui]

Hi Julius2342, congratulations for your amazing job.
I have a Zennio z38i device to control my climate but is not allowed to read/write in the same setpoint_adress.
Would you create a separate identifier for setpoint_adress_status? That would be great. Thanxs and apologies for my english, is very basic ans rusty.

[Julius2342]

@zimgui : The newest version does no longer need a setpoint. It calculates the new setpoint shift out of the current setpoint shift and the current target temperature.

[zimgui]

That sounds great! I'd wait for 0.57 being released in HASSIO platform to test it. Thanks a lot.

[Julius2342]

I made a pull request in HASS. I will close this issue now, if any new problems (bugs/feature requests) arise, please open a new ticket.

[ghost]

I can successfully decrease the tempertature. But when I increase the GUI breaks. Can any help me? I have raised the issue at https://community.home-assistant.io/t/thermostat-up-increase-button-breaks-the-control-knx/53069 . I have put my config in that as well.

[dzungpv]

My device Zennio KLIC-DI for Daikin VRV does not have any field setpoint_shift_address
or setpoint_shift_state_address only setpoint_address.
I try to config many way but it could not set temperature.

[moustic999]

not sure if this has already been properly implemented, but here is some axplanation about how many devices works with setpoints :
there is 3 way to work

• setpoint 2 bytes object

object : basic setpoint : set the basic temp for comfort mode ( ex : 21°C)
object : shift setpoint ( dpt 9.002 ) -+value in K (ex: +3K-

then the device compute the target temperature depending on the 2 values and the current mode
so in this example target temps reported by the device will be : 21 + 3 = 24

there is no need for xknx to compute any target temp.

• setpoint 1 bit object

will increase / decrease the basic setpoint by 0.5/ 1 K for each received ( 0 decrease / 1 increase )

the new target temperature is computed by the module and does not need to be computed by xknx.

• no setpoint shift.
  Some other device does not support this way, but need to receive the computed target temperature directly.

[moustic999]

look at this doc : file:///C:/Users/id080710/Downloads/Manual_Z41_Lite&Pro&COM_v3.1_c_EN.pdf
on page 98, explanation regarding the different shift mode ( absolute / relative 1bit /relative 2 bytes )