[HomeKit] Supporting new iOS 10 HomeKit accessories

[grouchal]

iOS 10 now supports many accessories that are not currently supported by openhab:

• Garage Door
• Locks
• Shades
• Fans
• Outlets
• Sensors
• Doorbells
• etc

I would happily contribute and work on extending the plugin to support some of these especially:

• Garage Door
• Shades
• Outlets
• Sensors

Has anyone started this? If so how can I get in touch and plan the work?

cc @beowulfe

[Mr-iX]

@beowulfe For me the state 100 means fully closed and 0 means fully open. So this explains why the status is reversed. I'm using KNX-rollershutters with the KNX-Binding.

So it seems that this is the normal behavior. Could you please modify the homekit-addon, so that 0 means open. Thanks!

[Trinsic82]

Hi, can anyone send me the latest Homekit add-on as an jar File? Sorry I'm not able to create the Jar file from the GIThub with Eclipse. Thanks for your support

[weakfl]

@Trinsic82 here you go.

[MrBalonio]

Does this include Garage support, I would really like to see this working. Controlling garage with siri would be awesome.

[grouchal]

Looking through the other mentioned issues here and following them into the final Eclipse Smartphone issue and pull requests. I can see the that new semantics approach will not be included in ESH until at least 0.9.0 is shipped.

Judging by the progress of 0.9.0 it would seem that this means the new approach to semantics tagging won’t be available until at least mid 2018.

I would like to propose to @beowulfe that we use the existing method that he has exposed items to openHAB in version 2.0 and just extend that for now to include window coverings and garage doors as his existing code does already.

If his branch could be brought it to the 2.2.0-snapshot for openHAB, many more people could easily provide feedback on the functions, rather than this issue being blocked by the semantics discussion.

I am ready to help on testing and providing bug fixes, if there is a clear path to support for iOS 10 in openHAB. It would be great if we could get these changes into the next version of openhab ;-)

So @beowulfe is your branch good enough to be merged into the main project? If not how can we help? If so - how can we help? ;-)

[Olivierr92500]

Hi everyone, I fully support Grouchal's pragmatic idea to start with the method from @beowulfe and see later if a better method can be found. The topic is more than one year old so if there is a way to improve the software quicly that would help a lot of users. I am no longer a developper but I can help in testing beta release of the library and provide feedback.

[marcelfust]

Hi everyone, if alredy installed the homekit addon, it works fine. Now i want test the snapshot with the window coverings. How is the best way to do it on the rasperry bi, that i don't lose all homekit settings. Thank for the help.

[maihacke]

Just to let everybody know here, there was a problem with inverted position for window coverings. Despite of that it is working fine here. I created a patch/pre-release to fix the inversion problem here https://github.com/maihacke/openhab2/releases Following the discussion here it seems to work for some others: https://community.openhab.org/t/homekit-support-for-additional-accessory-types/19344/25

[SpeedmaxX]

Hi, how did you tag the window-coverings?

[SpeedmaxX]

hmpf I should have read completely, sorry. It‘s in the community-thread

[marcelfust]

you have a link? I don't wich the right way to replace it?

[weakfl]

For the reversed status - I just assumed Openhab's numbers matched Homekit's - 0 is fully closed, 100 is fully open. I did a brief scan of the documentation, and couldn't find anything. Maybe someone more knowledgeable than I can comment on what's expected.

@beowulfe According to the homekit documentation for blinds 0 should be open and 100 closed:

"The target position of a door/window. The value is an uint8 value in percent. For shades/awnings, a value of 0 indicates no shade and a value of 100 indicates most shade. For blinds, a value of 0 indicates most light is allowed in and 100 indicates least light is allowed."

[smiesko99]

Hi

can you help me? i am trying to showing up my xiaomi windows sensor in my apple homekit but i am unable to find tags for this xiaomi string: Contact WindowSwitch_Status { channel="mihome:sensor_magnet::isOpen" } but i do no know o ["door"] or what ever is working also i am unable to get working xiaomi gateway lamp i have it in my homekit app but i am unable to turn it in or off but when i turn it on from xiaomi app they show up like turned on in homekit app

it seems that xiaomi lamp is unable to manage from homekit

do you have any experiences with xiaomi integration ?

thanks

[RogerG007]

but i do no know o ["door"] or what ever is working also i am unable to get working xiaomi gateway lamp i have it in my homekit app but i am unable to turn it in or off but when i turn it on from xiaomi app they show up like turned on in homekit app

The gateway lamp should be no problem:

Switch Gateway_Switch "Gateway Light" <light> ["Lighting"] {channel="mihome:gateway:...:brightness"}
Dimmer Gateway_Brightness "Gateway Dimmer" <sun> ["Lighting"] {channel="mihome:gateway:...:brightness"}
Color Gateway_Color "Gateway Color" <rgb> ["Lighting"] {channel="mihome:gateway:...:color"}`

I'm not sure with the window sensors. Have you tried ["Switchable"] ?

[wborn]

There is a bounty on this issue in Bountysource.

[matushromada]

There is a bounty on this issue in Bountysource.

And yet no one else besides me wasn't able to contribute...

[piejanssens]

Maybe because the lack of decision makers and progress on this issue is pushing people towards alternatives such as NodeRED + node-red-contrib-homekit.

[matushromada]

I agree the decision should already be made... I'm using NodeJS and HomeBridge for unsupported items, but it requires extra work and understanding of the plugins to get it working. Still using OH2 native plugin for switches and lights.

[grouchal]

We will soon be able to celebrate the 2 year anniversary of this issue.

To get the problem in focus, there is nothing technical blocking this, we are just awaiting a very very decision making process that is blocking progress here.

As ever I am happy to provide any development and testing support required to move this forward...... but we need @kaikreuzer to remove the blocks here ...

[chri46]

Moved to NodeRED + node-red-contrib-homekit for all homekit integration a while ago. uninstalled OH homekit binding for good.

[SpeedmaxX]

I moved to homebridge fully. Am looking forward to version 2.4 or later to reinstall openhab, but currently it's working good.

[kaikreuzer]

we need @kaikreuzer to remove the blocks here ...

@grouchal Do we? What for?

[grouchal]

@kaikreuzer I think that perhaps some history has been forgotten as this issue has been open so long.

Your Comments (1,2, 3) point to https://github.com/eclipse/smarthome/issues/1093 blocking this issue.

and @beowulfe is waiting for a decision about the future acccording to this comment

I don't have a working version that supports this. I did at one point, but it's broken with updates. I'm reluctant to put much work into it until we've settled on how to map items to homekit accessories - I'd potentially be doing a lot of work that's ultimately thrown away.

So it is clear he is awaiting for the issues in https://github.com/eclipse/smarthome/issues/1093 to be resolved.

In that issue you have written on the 6th Oct 2016:

Thanks for the reminder, I sense the urgency, but I am still not on it :-/ Sorry for asking for that much patience...

Then on 19th Jan 2017:

@grouchal & @EjvindHald: I still have to read the comments in detail, think about them and continue the discussion - I didn't yet find the time. Anybody is invited to make suggestions on the best way forward; so if you have brilliant ideas, please don't keep them for yourselves.

Which invites new ideas but through the thread we know that you are the decision maker who is required to move this forward.

There was a lot of movement in April this year on that thread, but since June when you mentioned haystack it has not received any more attention.

---

So history lesson over, as ever we need some decisions made by you so that @beowulfe can go forward, with a topic that is of interest to quite a few people.

I can understand why people are choosing other solutions when things get stuck for 2 years.

[kaikreuzer]

To complete your history lesson: The last info that I found is https://github.com/eclipse/smarthome/pull/4390#issuecomment-381591821:

@kaikreuzer - that might work. Let me get something working and I'll start a PR for discussion.

and https://github.com/eclipse/smarthome/pull/4390#issuecomment-393373869:

Those look great to me as well. Thanks for pulling those together @digitaldan

So which exactly is the open topic/discussion that I am needed for for clarification?

[andylintner]

@kaikreuzer is right, there is nothing blocking me anymore - except the demands of real life. I'm about 75% of the way into refactoring the item -> accessory process to both use the new metadata service and make it simpler to add new accessory types. Once that's done, I can move pretty quickly on getting the new types in.

[SpeedmaxX]

@beowulfe Great! Thank you!

[kaikreuzer]

Glad to hear that, thanks for the feedback @beowulfe! And please ping me any time in case you get stuck!

[grouchal]

@beowulfe how are you getting on? If I can be of any help - please let me know. I am a java programmer, but it is not clear to me what tasks are outstanding.

WRT to the the inversion of status for RollerShutters in HomeKit - is there a fix planned for this. I have searched for the code so that I can reverse the statuses but can't find it.

Could you either fix the bug, or point me to the code so that I can fix the bug and send you a Pull Request?

[grouchal]

I will close this issue - these changes will happen when they happen, leaving it open doesn't serve any purpose.

I have reviewed the code and made the reverse changes but so have other people and you can find the pull requests in @beowulfe's fork of the repository.

I look forward to a future when all the HomeKit accessories are supported but after 2 years I am not optimistic.

I will try to hack around the code and get the contacts and garage door openers working, until an official version is released.

[piejanssens]

@grouchal It's been a long 2+ yrs since you opened this reasuest, but I am still hopeful myself seeing that @beowulfe has been activie in his fork not so long ago. I would reopen the issue because it's not resolved and it does contain a good amount of history/information (and who knows, one day you might be awarded for longest standing OpenHab issue).

https://github.com/beowulfe/openhab2/tree/homekit-metadata

[Mr-iX]

@beowulfe Is there any progress?

[J-N-K]

There has been some refactoring lately, I‘ll try to have a look after I finished SNMP.

[EjvindHald]

Yes, there has been made some very cool enhancements. See this link