Announcing some improvements to the Homekit plugin for openHAB 2

@sjorge This is planned; current focus is to get the current changes merged in to OpenHab upstream. Then, with HAP-Java 1.2.x we will add better support for optional characteristics, which will then enable us to have richer aggregate devices.

1 Like

The 6th release of the plugin is out. See the changelog:

@Tim_Harper

Thank you for your work on the improvements on the HomeKit plugin. It is relay needed to improve these binding. Your latest version indeed works on my setup where the “original” version from openHAB would not connect. So thank you very much.
I have a point wich could be discussed. I’m using a mixture of Alexa and Siri (maybe with is not so common, but a good solution for me :smile:) and my point is that I have Items tagged for Alexa which I normally do not want to see within HomeKit. So my question or point for discussion is, would it be an option to use different Tags within the HomeKit binding to control which items should been exposed. Maybe an advanced setting to activate the HomeKit specific tags would be an idea.
Wire82

I haven’t set up Alexa support myself. (but plan to). Maybe an ignore tag would be in order.

As an aside, there’s been some discussion and some work about the future of configuring Openhab2 Homekit items is through item metadata.

Yes an ignore tag would be nice.
I also saw that maybe the Alexa skill will also change the way of how the items are recognized.
Is there a discussion about the item metadata tagging?

Andy Lintner had started some work on it, too: https://github.com/beowulfe/openhab2/commit/8ede0bcf1a405b8a41b42f60a2da9de7939c7a57

Hi Tim,
integration of ContactSensors works now.

My item: Contact Sensor_Fenster "Bad Fenster"    <window>    (OG_Bad) [ "ContactSensor" ]    {channel='innogysmarthome:WDS:...........:contact'}

Smoke Sensor is also shown in HomeKit, but without the battery Level. Here my Group:

roup  Flur_Melder     "Flur Rauchmelder" (OG_Flur) ["SmokeSensor"]
Contact Rauch          "Flur Rauchmelder"          <smoke>    (Flur_Melder)          ["SmokeSensor"]                 {channel='innogysmarthome:WSD:................:smoke'}
Switch Flur_Batterie "Flur Rauchmelder Batterie" <battery>  (Flur_Melder)           ["homekit:BatteryLowStatus"]    {channel='innogysmarthome:WSD:..........:battery_low'}

Any Idea?

It’s only going to report when your battery is less than 10%. If you want to test it out, maybe you can Find someway to manually set the battery level (find it to a site map?). You will need to close the Home app, and reopen it, for it to clear the battery status.

Has there been any work on alarms? Ie the ability to set a device as armed/disarmed etc and expose it to homekit?

@psyciknz: no, not yet, but I’ll probably pick that up soon. I first want to get some metadata stuff working so that I can define the proper number of steps for fan speeds, and for allowing you to limit the thermostat range per-thermostat (I have multiple thermostats in my home of different brands, so they have different ranges).

Not to my knowledge

Maybe this does not belong here, but I received no response elsewhere: Can I change the Homekit:HeatingCoolingMode from a voice control like Alexa or Google Home? What would be the (preferably German) command?

@psyciknz: ask and ye shall receive: https://github.com/ccutrer/openhab2-addons/releases/tag/2.5.0-cody2

sorry no support for changing config to specify different enum values for your security system state. use rules if what you have doesn’t match (mine doesn’t, but I had to use rules to do lots of transformations, not just mismatched strings).

Awesome. That was the main reason I pushed most of my homekit items to home assistant.

Thankfully the thing that posts the value from my paradox I wrote so I can set the value to whatever I want.

Thanks, I’ll test it. Is it possible to integrate the battery parameters into the thermostats? That would be very helpful. At the moment I solve this via an extra item with a switch. The integration via the group of thermostats would be more elegant.

Unfortunately, we’re confined to what combinations of characteristics Homekit supports with accessories, and battery-status isn’t one of them. I think you’ll have to continue you with your workaround.

I’ve been going off of this JavaScript HAP-NodeJS file as documentation for supported characteristics and accessories; have a look: https://github.com/KhaosT/HAP-NodeJS/blob/master/lib/gen/HomeKitTypes.js#L3443

hi Tim,

great work - I’ve been using the improvement for a few weeks - runs stable !
Do you consider including “LockMechanism” ?

Thanks Tim for the great improvement. With the 6th release everything works smooth. No delay anymore. Just one small thing i have noticed during testing. If my lights have a dimmer the order of sending command for different light are not equal. This results that the dimmer value does not work.

E.g.:

In my kitchen: (Not working, because dimmer sent before ON value)
1.) Dimmer value is sent
2.) On state is sent

In Bath: (Working)
1.) On state is sent
2.) Dimmer value is sent

May it be possible to also fix that also?

Edit: I just found an issue on Github which also describes this behavior. In my mind it would be enough not to send ON command again if the light is already on.

Do you think it is the fault of the binding or HomeKit?

Well, i’m no expert. But maybe it just Opebhab interpreting things different than the homekit protocol but then there might be something like adapter pattern to get both speaking the same language.

If found another source about this issue.