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?
i never tried myself but theoretically following could work - you could add the same item to multiple groups.
String thermostat_target_mode "Thermostat Target Mode" (gUtilityRoomThermostat, gAnotherRoomThermostat, ...) {homekit = "TargetHeatingCoolingMode" [HEAT="HEAT"]}
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.
1 Like
That’s really great news! Is it too much to ask for the list below? 
- Configurable rotation speed for heater/cooler/fan (min, max, step)
- Group of complex accessories
- TV support (big one)
Hi @yfre:
Just realised another small issue please see my other post here: Homekit add-on: device is still controllable even though the thing is offline
Basically the accessory is still controllable in HomeKit even though OpenHAB thing is offline. Would it be possible to show “no response” when the thing behind the HomeKit accessory is offline?
Hi @somy
i dont think it is possible. you have some experience with homebridge. was it possible there? if yes, i could have a look how it is implemented there.
Hi @yfre,
In HomeBridge it’s pretty much up to how the plugin is implemented.
Many of my plugins can certainly show “no response” when it lost connection to the accessory, most plugin detect the device offline by periodically pull state from the device (I think it’s the same with OH bindings).
However the OH plugin I use in HomeBridge doesn’t show no response when OH server is down (only when start up), and it caches values from OH
@yfre please ignore, I solved the issue, it was because I should not mix other accessories in the same group.
Just got another issue (sorry to keep asking), I tried to configure my Xiaomi Gateway light based on the following config:
Group gXiaomiGatewayLight "Xiaomi Gateway Light" {homekit="Lighting"}
Switch Xiaomi_gateway_light_switch <light> (gXiaomiGatewayLight) {homekit="Lighting.OnState", channel="mihome:gateway:286c0788xxxx:286c0788xxxx:brightness" }
Color Xiaomi_gateway_color <colorwheel> (gXiaomiGatewayLight) {homekit="Lighting.Hue, Lighting.Saturation", channel="mihome:gateway:286c0788xxxx:286c0788xxxx:color" }
Dimmer Xiaomi_gateway_brightness <dimmablelight> (gXiaomiGatewayLight){homekit="Lighting.Brightness", channel="mihome:gateway:286c0788xxxx:286c0788xxxx:brightness" }
Dimmer Xiaomi_gateway_colorTemperature (gXiaomiGatewayLight) {homekit="Lighting.ColorTemperature", channel="mihome:gateway:286c0788xxxx:286c0788xxxx:colorTemperature" }
Interestingly when items file reload, all accessories lost connection, if I remove the configuration for this particular light, everything works again. The xiaomi gateway is a bit strange that the color type cannot control brightness, hence I need to add brightness and switch to make it work. However I don’t know what went wrong with my configuration and why does it crash the rest of accessories?
@somy try to do it without ColorTemperature.
according to apple spec it is not allowed to have hue, saturation, brightness with colortemperature
Color Temperature
If this characteristic is included in the ”8.23 Light Bulb” (page 147), ”9.44 Hue” (page 179) and ”9.82 Saturation”
(page 197) must not be included as optional characteristics in ”8.23 Light Bulb” (page 147). This characteristic must
not be used for lamps which support color.
That’s really great news! Is it too much to ask for the list below?
- Configurable rotation speed for heater/cooler/fan (min, max, step)
- Group of complex accessories
- TV support (big one)
update on that one:
- this should work with next snapshot version. the changes are already merged
- this is my next to-do but it will take some time, 2-3 weeks i would estimated
- i have added support to television to java-hap library. so, once the previous point - complex accessories - is implemented, i will add TV support to openhab as well.
1 Like
Hi @yfre just want to report when I removed the color temperature it works! Thanks for the help! However I’m still having a small problem with regards to grouping - when I put the light (group of Switch, Color and Dimmer) inside another group with another HomeKit switchable accessory, the control somehow get mixed. Instead of using the switch in the light group, it uses the switch from its parent group. Just to be concrete, below is the working configuration when I put the accessories in two independent groups:
//Below are Xiaomi SmartHome binding
Group gXiaomiGateway "Xiaomi Gateway"
Number:Illuminance Xiaomi_gateway_light_sensor "Indoor Light Sensor [%s lx]" <sun> (gXiaomiGateway) {homekit="LightSensor", channel="mihome:gateway:286c07889653:286c07889653:illumination" }
Number Xiaomi_gateway_play_sound "" <soundvolume-0> (gXiaomiGateway) { channel="mihome:gateway:286c07889653:286c07889653:sound" }
Switch Xiaomi_gateway_sound_switch <soundvolume_mute> (gXiaomiGateway) { channel="mihome:gateway:286c07889653:286c07889653:enableSound" }
Dimmer Xiaomi_gateway_sound_volume <soundvolume> (gXiaomiGateway) { channel="mihome:gateway:286c07889653:286c07889653:volume" }
Switch Xiaomi_gateway_sound_homekit "Play Sound" (gXiaomiGateway) {homekit="Switchable" }
//Gateway lights
Group gXiaomiGatewayLight "Xiaomi Gateway Light" {homekit="Lighting"}
Switch Xiaomi_gateway_light_switch <light> (gXiaomiGatewayLight) {homekit="Lighting.OnState", channel="mihome:gateway:286c07889653:286c07889653:brightness" }
Color Xiaomi_gateway_color <colorwheel> (gXiaomiGatewayLight) {homekit="Lighting.Hue, Lighting.Saturation", channel="mihome:gateway:286c07889653:286c07889653:color" }
Dimmer Xiaomi_gateway_brightness <dimmablelight> (gXiaomiGatewayLight){homekit="Lighting.Brightness", channel="mihome:gateway:286c07889653:286c07889653:brightness" }
//Dimmer Xiaomi_gateway_colorTemperature (gXiaomiGatewayLight) {homekit="Lighting.ColorTemperature", channel="mihome:gateway:286c07889653:286c07889653:colorTemperature" }
However if put “gXiaomiGatewayLight” as a sub-group in “gXiaomiGateway”, when I turn on the light, it uses the switch “Xiaomi_gateway_sound_homekit” instead of “Xiaomi_gateway_light_switch”. So looks to me that when the HomeKit light accessory is created, it search the switch capability in parent group before the sub-group. Is it expected behaviour?
Thank you!
Great, glad to test the changes when they’re out! BTW, any chance also to add " Filter Maintenance Sensor" accessory support? It’s in API but not officially supported in Home app, Eve can certainly read the percentage. The description of the accessory from the homebridge plugin:
it is not expected behaviour. probably is bug. i will touch this part for complex accessory support anyway and can check.
the future it will put both accessory - from parent and from child group - in one accessory in home app.
regarding the filter maintenance - it can easily added. java-hap supports is already. but probably it will make only sense as part of complex accessory as not as standalone accessory. similar to battery service.
so, first complex accessory support and then filter service, battery service, irrigation and tv
Thank you! Very much look forward!!
Just setting up homekit support in OH4.0.3 for a pellet oven.
I am trying to reduce the selections options in homekit for the thermostat - using the following item definitions:
String aduroh2_thermostat_current_mode "Thermostat Current Mode" (gAduroH2) { homekit = "CurrentHeatingCoolingMode" [ OFF="OFF", HEAT="HEAT" ] }
String aduroh2_thermostat_target_mode "Thermostat Target Mode" (gAduroH2) { homekit = "TargetHeatingCoolingMode" [ OFF="OFF", HEAT="HEAT" ] }
I only want the OFF and HEAT option used and shown - but different from the description/guide, adding the [OFF=“OFF”… ] descriptors does not reduce the states to select from in the home App - it only limits the communication of stage to OH to the ones described.
This is how it is described in the homekit-OH documentation:
The custom mapping can be also used to reduce number of modes shown in Home app. The modes can be only reduced, but not added, i.e. it is not possible to add a new custom mode to HomeKit thermostat.
Anyone else who sees this behaviour - and have an idea how it can be reduced in the home app, making it more wife-friendly ?
Huh - works after removing the assesory in homekit, clearing pairings in the console and re-adding in homekit…
1 Like