Thermostat Auto-Mode question

[soundman666]

Hello! First, thanks for your work. It looks great!

I have long been waiting for a simpler and more effective interaction between Openhab and Homekit! Now I use Node-Red together with node-red-contrib-homekit-bridged, this is how it allows you to implement the most complete functionality of HVAC devices for HomeKit. My question is: is it planned to fully implement all the properties, for example, CoolingThresholdTemperature for "auto" mode?

[steilerDev]

Thanks! Sure I am very open to extend the functionality of the thermostat. However I don't quite understand how the Heating/Cooling/Auto Mode should affect the device or how to map it to openHAB items in the best way. Getting your feedback on how you would image a mapping would be great.

I guess CoolingThresholdTemperature is just a number, that I should map to a Number Item in openHAB? That should be no problem, how about the other characteristics?

[soundman666]

Thanks for the quick response! I tried to explain the fullest possible implementation of the HAP thermostat here.

Such an approach may scare users of “simple” thermostats who use a Switch-type items. Nevertheless, it seems to me that this is easy to solve by creating a proxy-item that turns OFF to 0 and ON to 1 (if we declare a simple heating thermostat) or ON to 2 (if we are talking about a cooling thermostat).

[soundman666]

Here is an example of my implementation of a "complex" room thermostat in the .items file. I assembled several physical devices (radiator and air conditioner) into one virtual device in order to simplify my user control.

[steilerDev]

Yes, that makes sense. I will definitely look into that. However I probably will have the number item optional to the switch item, since my setup requires switches ;)

But I really like the idea of non-binary states being represented as Number items in openHAB, I could rework the security system to use that approach as well.

[soundman666]

Thank you, Frank! I will look forward to new versions and test them.

Perhaps (as an alternative) it makes sense to consider the possibility of implementing 2 thermostats: simple (with 1 action: heating or cooling, a Switch-type items) and complex (with Numbers items)?

In any case, I beg you to add the CurrentHeatingCoolingState characteristic (since this is not the same as TargetHeatingCoolingState).

[steilerDev]

Could you please explain the last bit (Since I already have Current- and TargetHeatingCoolingState implemented for the switches).

I saw those characteristic to be the 'setter' and 'getter' for the state, saying: If your thermostat is currently heating this will be set to Heating and if you want to stop the thermostat to heat you would change the Target State to Off. That is the current behavior.

[soundman666]

It is not always so. Suppose you set the thermostat in heating mode. At the same time, the thermostat (as a performer) can be in 2 states: IDLE, if the target temperature has already been reached and the heating element is turned off (Characteristic.CurrentHeaterCoolerState.IDLE ie 1) or HEATING (Characteristic.CurrentHeaterCoolerState.HEATING, i.e. 2), if the thermostat is currently on the heating element. And when you turn off the thermostat in Home.app, the value should be Characteristic.CurrentHeaterCoolerState.INACTIVE, i.e. 0;

This allows you to see in the interface Home.app not only the current & target temperatures and thermostat mode, but also its activity.

Something similar you have already implemented for the outlet. If it is enabled, it does not necessarily mean that it is used.

[soundman666]

In both examples, thermostats are turned on in the "Heating" mode. But in the first room, the target temperature has not yet been reached, so the heater is now active (CurrentHeaterCoolerState = 2). In the second case, the target temperature is reached, so the heater is turned off (CurrentHeaterCoolerState = 1). If I turn off the thermostat at all, the CurrentHeaterCoolerState value becomes 0.

The circle changed color from orange to green)) The text also changed a bit. on screen 1 it says "I heat up ...", on the second - "heated ..."

[steilerDev]

Thanks for the input. However when looking at Apple's specification neither Current nor TargetHeatingCoolingState have a differentiation between currently heating and currently not heating but in heating mode. Image a thermostat that is only able to heat. Should I therefore always be in the Heating state and never in the OFF state? The correct expected behavior always confused me.

[soundman666]

Yes, I saw this specification. But, if we can use these IDDLE and INACTIVE states, why not do it? I showed an example of how I use it. It seems to me more effective and it does not contradict anything. I by no means urge you to think as I am. I just ask to give me the opportunity to use the Apple thermostat as efficiently as possible))

[steilerDev]

Alright, I tested a lot over the last couple of days and found the mistake I made during implementation. If you want to check out my latest commit (bf79146) on branch V0.9.0 you can see the rework.

The following is now the case:

• heatingThresholdItem and coolingThresholdItem is now optionally available as a Number item
• heatingItem and coolingItem are still switches that represent, if the thermostat is currently heating or cooling (I probably won't change that, since I find it the most logical mapping, although you can use a proxy item in your environment)
• modeItem is now optionally introduced. This expects a Number item that is representing the current mode of your thermostat (0 = OFF, 1 = Heating, 2 = Cooling, 3 = Auto). This item will be changed through the Home.app controls, BUT this only shows if the Thermostat wants to heat/cool/auto (TargetHeatingCoolingState), not if it is ACTUALLY heating/cooling, this is controlled by heatingItem and coolingItem ( CurrentHeatingCoolingState)

What are your thoughts on that?

[steilerDev]

Merged into master with d25d6df04dbc959da8cd1d74589541e40c89b31f and released as v0.9.0