I’ve added 3 additional devices supported by the Homekit plugin for Openhab2: LeakSensor, Valve, and MotionSensor. No support for battery but it is coming.
I’m pushing builds of the plugins here: https://github.com/hap-java/openhab2-addons/releases/
See my changelog: https://github.com/hap-java/openhab2-addons/blob/homekit/addons/io/org.openhab.io.homekit/CHANGES.md
Docs are updated here: https://github.com/hap-java/openhab2-addons/tree/homekit/addons/io/org.openhab.io.homekit
Awesome to see someone working on this!!
Have you done any work on the big issues with homekit + openhab or are you just adding more service types?
Namely:
Those are my big ones that sent me off to node red since I’m not at the point of editing bindings just yet.
Again thanks! I’ll be watching the progress here!
Right now I’m adding more service types; I might tackle a few of the bugs I’ve encountered as well (exposing offline state properly is high on my list…). I’m about to set up a dimmer with it so I’ll probably solve the 0 to 100 flash bright light if I run in to it (which dimmer do you have?)
I have Insteon dimmers. The issue is that HomeKit often sends “on” along with the level so it’s kind of a race to see whether the “on” command or the dimmer level arrives first. My node red javascript function just drops “on” while passing the number through - unless homekit only sends “on” in which case I save the previous dimmer level which gets passed to openhab.
That may sound more complicated than it is I think. I’m happy to share my javascript function if/when you ask. It’s been working perfectly for like 5 months now…
Ah; yeah that’s crappy. You’ll have your dimmer set to 100% (last value) but switched off, if you turn it on with homekit to 50%, it’ll send “on” then “50%”, which causes it to turn on to 100%, then dim to 50%?
Not super sure how this would best be solved, I’d probably need to see some logs.
Yes - many times it gets 50 first then sticks at 100.
But if you ever want to throw a dance party just grab the dimmer slider on your phone and drag it up and down slowly. One step strobe light!
You’ll make a lot of people around here very happy if this gets to be a more functional binding.
Well, I could make some progress if the dev setup wasn’t in such shambles. 
I’m having a really hard time keeping a working installation of eclipse. Not sure why but things will work one day and then everything is broken the next.
Are the blinds from this version also included in your version?
@Beluk I reverted the blinds support for now, since it caused things to fail in catastrophic ways. I’ll have to investigate more why it fails so hard, I suspect something is broken with WindowCovering support in HAP-Java.
@Beluk I was able to fix the issue in upstream HAP with WindowCovering; the 4th release of my forked homekit plugin has it enabled. Give it a try. I think the plugin is getting very good and robust now.
Thanks for the update, i’m very busy at the moment, but when i have some spare time i will try it out and give you some feedback.
@Tim_Harper I tried https://github.com/timcharper/openhab2-addons/releases/tag/v2.4.0-homekit-4, principally it is working, but the reaction is not good.
After opening Homekit on iPhone it tries to update 1-2 minutes long the items:
After that it tells me that there was no response:
But when clicking on the items they get working:
Unfortunately this happens every time the app is not in the foreground.
Hello,
I am running OH 2.4 stable release. I was really glad to see that the HomeKit add-on started to get updated again.
I have been trying to move away from the bundled HomeKit add-on and use the one that you updated (latest -4 release) to have Thermostat working both directions and be able to use it for window blinds later on.
I did struggle during a few hours to move from the built-in binding to your build but eventually managed to get my single Thermostat paired in Home app.
Unfortunately, it does not work properly, for example, I don’t have the current temperature set point value displayed in Home app when adjusting (I had before), or the Thermostat colour does not seem to get updated following mode changes. Yet, I no longer have the “No response” issues.
With your build, I have error messages that I did not have before, regarding improper Characteristics tags on Items, which appear fine to me.
2019-01-30 11:29:23.133 [ERROR] [al.accessories.HomekitThermostatImpl] - Item F0_Salon_AirCond_SET has unrecognized thermostat characteristic: OLD_TARGET_TEMPERATURE
2019-01-30 11:29:23.135 [ERROR] [al.accessories.HomekitThermostatImpl] - Item F0_Salon_AirCond_HKMO has unrecognized thermostat characteristic: HEATING_COOLING_MODE
Here are the relevant items:
Number F0_Salon_AirCond_SET "Consigne clim. [%.1f °C]" <ac_set> (gAirCond, gAirCond_SET, gF0_Salon, gPersistOnChange, gF0_Salon_AirCond_HK) [ "TargetTemperature" ]
Number F0_Salon_AirCond_TEMP "Température mes. (clim) [%.1f °C]" <temperature> (gAirCond, gAirCond_TEMP, gF0_Salon, gPersistOnChange, gF0_Salon_AirCond_HK) [ "CurrentTemperature" ]
Group gF0_Salon_AirCond_HK "Thermostat Chambre Matthieu" (gHK) [ "Thermostat" ]
String F0_Salon_AirCond_HKMO "Thermostat Heating/Cooling Mode" (gF0_Salon_AirCond_HK) [ "homekit:HeatingCoolingMode" ]
I also get some :
2019-01-30 12:08:01.815 [ERROR] [kit.internal.HomekitAccessoryUpdater] - Received duplicate subscription on F0_Salon_AirCond_SET
@Tim_Harper, do you think any of these errors could be the cause of the wrong behaviour in Home app ?
The whole reason why this happens is Apple’s approach to Accessory, where a Lightbulb accessory needs to have an ‘On’ Characteristic and optional a ‘Brightness’, ‘Hue’ and ‘Saturation’ characteristic, depending if the lightbulb also allows dimming and/or colors. When turning the light to a specific percentage value or even HSB color value, every characteristic is fired. First the ‘On’ characteristic changes to true, then the ‘Brightness’ characteristic changes to your specified value and so on.
In my plugin I tried to solve this issue first by only accepting the ‘Brightness’ characteristic and ignoring the ‘On’ characteristic, however when turning a light off sometimes ‘Brightness’ and ‘On’ gets triggered and sometimes only the ‘On’ characteristic. My solution involves a synchronization step, where every characteristic stores its value globally and also triggers a ‘commit’ function. This function runs as a singleton and waits for 250ms (this is enough time for every possible characteristic to be set). After the wait time it will read the state item from the characteristics and decide how to properly update the OH item. You can see the implementation here (_setState currently at line 56 and _commitState at line 65).
Cheers,
Frank
@Beluk this is because the homekit plugin treats “undef” or “null” as the thing is offline. I recommend you add persistence backend which restores the values. Perhaps this will be configurable in the future.
(EDIT) I just saw you said “this happens every time the thing is not in the background”. I’m not seeing this same behavior in my own tests, and I know of at least one other person who is using the window covering support without any issues. I do suspect that an item’s value might be null in some way, but aside from that, I’m not sure what could be causing it right now. Are there any log messages that may be of help?
Can you describe in detail the ideal firing sequence? Perhaps I can improve it. I don’t have any HSB bulbs.
IE:
When I change the color, then:
When I change the on state, then
etc.
@tarag Thermostat mode has always been really broken for me in Homekit. Please try my latest release, which improves things and gets it working again for me:
WRT to the “duplicate subscription”, you should be able to ignore these. I see them without any impact to functionality. I haven’t really dug in to what’s happening.
Hi Tim,
Great job ! I’m happy to see there is again evolution on this topic.
I did some brief test and it’s looking good !
One small improvement on the sensors I suggest, is to make a specific tag for a door sensor (refering to the Homekit “Door” Service). Behavior is the same as the other sensor but it will show up as a door the HomeApp.
I had tried this in the past when programming homekit, and it did not work. Homekit ignored it and expected me to specify the door type, regardless.
Anyways, if you long press the contact sensor in the Home app, you can change the type. Have a look:
