Hi all,
I’m trying to migrate HomeKit support from HomeBridge to OpenHAB, and have some difficulties to configure the items. I think most of my challenges are that I’m not at all familiar with OpenHAB syntax and data types, so I’m hoping to get some help here. I’m currently using homebridge-oh2 plugin and the thermostat is configured like the following:
The corresponding items are defined in OpenHAB like the following:
Number WavinUtilityRoomTargetTemp "Utility Room Target Temperature [%.1f °C]" <temperature> (gWavinThermostats) {channel="zmartmodbus:jablotron_tp150:918a900e8b:chn0e8:ManualTemp"}
Number WavinUtilityRoomCurrentTemp "Utility Room Current Temperature [%.1f °C]" <temperature> (gWavinThermostats) {channel="zmartmodbus:jablotron_tp150:918a900e8b:chn0e8:AirTemperature"}
Switch WavinUtilityRoomActive "Utility Room Thermostat Active" <switch> (gWavinThermostats) {channel="zmartmodbus:jablotron_tp150:918a900e8b:chn0e8:ThermostatActive"}
I’d like to define a thermostat that is always set to target mode “HEAT”. The switch “WavinUtilityRoomActive” tells if it’s heating now (when target temperature > current temperature).
I have following questions:
Where should I put the HomeKit tag? I tried to copy {homekit=“xxxx” [xxxx]} but got some syntax error. I tried to put it both before “channel” and after and get the same result
How can I define “TargetHeatingCoolingMode” to be “HEAT” all the time? Is it possible to define a constant in the items file?
I current use a switch to indicate if “CurrentHeatingCoolingMode” should be OFF or HEAT, how can I map the ON/OFF to HEAT/OFF?
I see there is a way to define min/max temperature, is it possible to also define the min steps (like 0,5 or 1 degree)?
Very much appreciate your help or suggestions!
and the you need a rule that maps your mode Switch to HEAT/OFF of the thermostat_current_mode/thermostat_target_mode
e.g. i have this rule
rule "Map Atelier Heating Mode for Homekit"
when
Item control_atelier received update
then
if (control_atelier.state > 0) {
atelierCurrentThermostatMode.postUpdate("HEAT")
atelierTargetThermostatMode.postUpdate("HEAT")
} else {
atelierCurrentThermostatMode.postUpdate("Off")
atelierTargetThermostatMode.postUpdate("Off")
}
end
rule "Map Thermostat Target Mode"
when
Item WavinUtilityRoomActive changed or
Time cron "0 0/15 * 1/1 * ? *"
then
if(WavinUtilityRoomActive.state > 0){
thermostat_current_mode.postUpdate("HEAT")
}
else {
thermostat_current_mode.postUpdate("OFF")
}
thermostat_target_mode.postUpdate("HEAT")
end
I also noticed that you change both target and current mode to HEAT and OFF based on single switch, but it is not correct based on my understanding:
TargetThermostatMode is the mode that you want the thermostat to work
CurrentThermostatMode is the mode that it’s currently running.
1 and 2 can be different - for example when 1=AUTO, 2 can be pretty much anything.
In my case my thermostat is always set to HEAT as TargetThermostatMode (it’s floor heating so only one mode). When the temperature is above the target temperature the valve will be closed so the CurrentThermostatMode can be either OFF or HEAT.
In HomeKit it’s green when the target mode is not OFF even though CurrentThermostatMode is OFF. It turns to yellow when CurrentThermostatMode is HEAT, and blue when CurrentThermostatMode is COOL.
One issue that I’m fighting now is when I set target temperature it revert back to original number:
2022-01-25 16:30:15.161 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘thermostat_target_temp’ received command 22.5
2022-01-25 16:30:15.161 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘thermostat_target_temp’ predicted to become 20
(in my case i have a item of type number that tells hoch much the heating valve is open (0-100%) but you have a switch). this will probably fix the “OFF” issue.
you comments regarding target vs current mode are correct. just in my case i cannot set the target mode on my device, i can only set target temperature. changing of target mode has no impact, therefore i keep both them in sync for homekit
regarding predicated state, it is known feature. you need to add autoupdate=“false” to your item, e.g
Hi @yfre: Thanks a lot for your help! I’ll give a try tomorrow.
Just one thing (maybe not related to this post). I find that I have to delete the OH Bridge in Home app and re-add it every time when OH restarts, otherwise all accessories from the bridge is unresponsive. Is it designed by purpose?
definitely not, it is not designed this way. the pairing should stay after restart.
but similar issue was reported few times. basically the information about the paired device was not stored correctly in openhab configuration. but we could not find the root cause for it and in most cases the issue disappear after some time without any changes.
can you give some more details on your setup, i.e.
OH version
hardware you use - raspberry PI, maybe docker ?
how you restart OH?
do you have “Block deletion of the HomeKit user” enabled in homekit binding settings? can you try to enable it? it was introduce as try to fix this kind of issues.
Hi @yfre, Please kindly find the answers to your questions below:
OH version: 3.2.0
hardware you use - raspberry PI, maybe docker: docker container on QNAP container station
how you restart OH: docker restart (I assume)
do you have “Block deletion of the HomeKit user” enabled in homekit binding settings? can you try to enable it? it was introduce as try to fix this kind of issues. I have now enabled it and haven’t experienced this issue for a few restarts, so definitely a good sign!
Edit: got the issue solved, it’s working well for me!
In items [%.1f °C] the ° was missing Happy now, I’m very much look forward to the grouping feature (group different accessories) so I can move everything to OpenHAB native HomeKit instead of via HomeBridge. Thanks a lot for your help along the way!!!
@yfre, sorry hope you don’t mind another question.
Since I have 11 thermostats, I’d like to ask if it’s possible to somehow only define one item for TargetHeatingCoolingMode and share it with all 11 thermostats? I kind of need a constant which should be set to “HEAT” when the system starts.
Hi, not exactly what I want but thanks anyways.
I basically need to create 11 items all holding the same static value when the system starts, and those items need to be in different 11 groups (each group for 1 thermostat in HomeKit). Maybe there is no real shortcut in OpenHAB.
Sry didn’t make myself clear. Basically I need the items for creating HomeKit thermostats, as it’s a mandatory item for configuring a thermostat. However in my case the value of all 11 thermostats are the same all the time, hence I just want to ask if there is an easier way to somehow declare a constant and use it in all 11 thermostats
You can link 11 different channels to the same Item. Its state will be a bit indeterminate if/when those channels send it updates, it will the most recent. A command to the Item will go to all channels. There are no constants for Item states.
But that’s the openHAB position; I suspect it would confuse Homekit.
You know Items are free?
but if understand you correctly, this item would never change the value, it will be always “HEAT”. so, why not copy paste it into different groups? potentially one additional rule which would send “HEAT” to all 11 items… not nice but should be possible to quickly copy&paste
Hi @yfre thank you! Actually I tried it first thing and it doesn’t work. Anyways I’m a developer so maybe why I hate copy/paste
I’d also like to report a missing feature (I assume you can help). In the HeaterCooler the RotationSpeed doesn’t seem to support min, max and step. I currently use steps as my ventilation only support 5 rotation mode, so I set step to 25 which only allows me to choose 0%, 25%, 50%, 75% and 100%.
correct. you cannot set custom min/max&step for rotation speed, it is not supported by binding.
it is easy to add it to homekit binding,
however, we use Java-HAP library for the HomeKit protocol (GitHub - hap-java/HAP-Java: Java implementation of the HomeKit Accessory Protocol) and this library has min/max/step hardcoded for rotationSpeed.
here i should actually blame myself as i have implemented this class in the Java-HAP and hard-coded this things
and i could add it easily, but, the Java-HAP has no active maintainer - last time PR was merged almost a year ago and i cannot merge PR myself there.
so, fix can be done fast but it will take very long to get it merged in Java-HAP, get Java-HAP released, etc.
what i did for my ventilator, which also has only 4 modes
i can select any % in home app
and i have a rule that adjust the selected % to 0%, 30%, 50%, 75%. so, it make a “jump” in home app to the next supported %… looks strange but i got used to it.
Hi @yfre, thank you for your reply, but your comment “the Java-HAP has no active maintainer - last time PR was merged almost a year ago and i cannot merge PR myself there” worries me a little (not as much as my worry on stock market these days). If the official OpenHAB HomeKit binding depends on a deprecated project with no active development, how do we expect continuity of the functionality in case of HK upgrade etc.? I think HomeKit is one of the most important eco-system out there, so would be very much like OH continuously adapt new features Who knows what Apple will bring in their next iOS upgrade…
@somy after your comments i got worried as well and have asked Java-HAP maintainers today whether we can review and merge more actively… and got promoted to maintainer there so, no execute anymore. i can review and merge Java-HAP changes.