First off, this is just my experience and my opinion. I tried many (if not all) alternatives before ending up ussing homebrdige-openhab2-complete.
I know there are forks of the official OpenHAB HomeKit add-on that support more (not all) HomeKit accessory types: not satisfied using forks or manual updates, still other known issues with homekit in openhab that are not yet resolved (losing items, MAC address not stored, …)
I know it’s possible to use Node-RED and a homekit plugin, I tried and it worked good for a while (I don’t recall what my last problem was). Yet it takes quite some time to learn and maintain node-red.
There is no better platform for HomeKit, than homebridge. It has a very active community and contains many, many plugins to support unofficial devices/integrations directly in HomeKit. For someone like me who doesn’t use any of OH’s UI’s to control the devices this a real plus.
The config of homebridge is really easy. It has a great UI to install and configure plugins.
Then there is homebridge-openhab2-complete which is a plugin for homebridge that allows you to add your openhab item as a new accessory in HomeKit just by putting a name+type+OH item ID in the config. After restarting homebridge the new accessory automaticallly appears in the Home(Kit) app.
The combination of openHAB + homebridge + homebridge-openhab2-complete is by far the best experience I have had in terms of (accessory support), UX (in setup) and stability.
I could find any posts on this forum about homebridge-openhab2-complete, so I wanted to share my positive experience with it to honor the dev. Thank you @steilerDev
Thank you for your kind words and the shout-out @piejanssens!
Since I started the development only a couple of weeks ago, there might still be some issues. So please let me know (with a Github issue) if you run into any problems or unexpected behavior. I will try and address those right away.
Also your feedback is valuable if you have use cases (combination of openHAB items to HomeKit accessories) that I might have overlooked, or don’t make sense to you. Just let me know if there is anything and I will try to sort it out (also still missing some accessory types though).
Cheers,
Frank
P.S.: Also check the releases, I have currently some spare time and add features on a regular basis
@steilerDev any interest or possibility of revamping the openHAB HomeKit plugin?
From a software engineering perspective, is it that the structure of OH fundamentally precludes one from developing a stable plugin? Did you try this before moving to NodeJS?
Often developers are tempted to just “start over” without trying to address the actual issues, so I’m trying to get a sense as to whether that is the case here.
I would prefer to have an integrated solution with less moving parts and it looks like development of the built-in plugin isn’t advancing, hence the questions. It would be great if there was some way to integrating your work into OH2 as a traditional add-on, whether there is a NodeJS layer in there or not…
I look forward to your thoughts and sharing your experiences on development…
This looks pretty cool. I’m curious, how is it different from previous homebridge-openhab implementations? For starters it looks very well documented which is awesome and rare in the open source world.
I fully embraced the node red option - it has a few benefits that I see in being able to use all of node red rather than just link homekit and openhab. For example I have some homekit items that link to http calls in node red. I know this can be done in openhab but I’m not personally capable.
Check out over here for some new activity on this.
This homebridge plugin looks cool! I’m always watching several different options, I’ll add this to my list!
@ns2001: I think this is a more fundamental question to ask. The HAP (HomeKit Accessory Protocol) required to interact with Apple’s Eco-System is very complex. It takes Apple in its official documentation around 150 pages to explain all details of the protocol. Therefore I think implementing and maintaining the whole protocol stack as a plugin for OH is too much to ask for an Open Source project. Even the famous Homebridge NodeJS server uses the Open Source implementation done by another developer and ‘just’ adds necessary stuff to run the protocol stand-alone and offers a plugin service.
Since I wanted to just focus on integration, I decided to use the very stable Homebridge platform as a foundation and OH’s REST service to interact with the system.
One way I thought about the problem - and someone who has experience with developing OH plugins is very welcomed to jump in - is to bundle Homebridge and all necessary dependencies in an official plugin that can run ‘inside’ OH and just expose the accessory configuration. However (as mentioned in my documentation as a motivation for this project) binding OpenHAB items to HomeKit Accessories is not trivial, since HomeKit often requires multiple OH items inside one HomeKit Accessory. Therefore configuration based on the .items files is not trivial (unless you force some kind of naming scheme on items which would make the integration way harder).
Btw.: I think de-coupling HomeKit from OpenHAB is generally speaking a good thing. OH is very resource heavy if there is a large item and rule set, easily requiring a whole RPi system. If there is the option to offload HomeKit to a dedicated infrastructure that could make things more stable.
@steilerDev@Tim_Harper Thanks for your thoughts, very enlightening, and also for your time and contributions to these projects which are immensely useful.
The issue here is indeed a fundamental one. There appear to be many (meta) forks, with developers taking different approaches. It’s fine to dig in and try an approach, but it seems like a waste of human resources to maintain several parallel paths each with potential drawbacks…
I am a developer myself (kernel/network/backend) and an avid openHAB user as well, and I’m torn as to what is the more robust, cleaner, better solution. I’m also willing to commit some time, but I’m not sure what effort I should back and hence this line of inquiry.
It might be worth sharing everyone’s experiences with one another and coming up with a unified way forward so that development is rapid, up-to-date, and seamlessly integrated with OH, at least from the perspective of a user. If we can do that and get buy-in from the leads on various forks, I am willing to contribute my own time as well.
Surely there are a lot of details out there regarding stability of various setups (OH+homebridge, OH+native binding, etc.) and after all of these user posts and feedback combined with your user experiences one would think that a unified approach forward should be possible.
I’m experimenting with setups, but I’m not seeing some of the issues others have described in the forums. That said, my setup is quite simple thus far.
A compilation of the pro’s and con’s based on the above criteria seems like a good place to start. Perhaps a new thread as well.
I’m the only one that is contributing fixes and improvements to HAP-Java at the moment. Pro: My fork is the most robust. Con: It’s also the most experimental as it’s changing the fastest.
If the standard HomeKit Open hab plugin serves you right now, use it.
I just converted from homebridge-openhab to your plugin this week and then found this topic in the forums.
I have to say I really love your work, because in the past some things in my config drove me crazy.
So I have some feature requests. Is there a way to add a number-item for the Battery-Level in % instead of battery warnings in form of a switch-item? homebridge-hue gets this done very well.
There is a lack of the Garage Door Opener
I use the homebridge-http-garagedoor for now but would love if you could implement it aswell. My garage is a rollershutter with the states 0 and 100, you just need to convert the 100 to an 1 and you´re good to go, because the garagedoor looks for a 1 for closed.
thanks for your feedback. Consider opening an issue in Github for the battery thing (helps me track everything and I don’t always get notifications here).
Actually I just released V0.10.0 with garage door support. Feel free to check it out, it behaves similarly to the window covering system with support for Rollershutter, Number and Switch items.
I updated to version 0.10, implemented the garage door and it works great! Just uninstalled the http-garagedoor.
I opened the issue as you’ve seen already, looking forward for more features in the future.
With iOS 12.2 comes the new accessory “tv” let’s see how that goes along with openhab.
First of all thanks a lot for this binding and all the hard work!
I am currently in the process of migrating from homebridge-openhab2 to -complete 0.10.0.
Unfortunately I have issues with my most common HomeKit controlled item: Dimmers. When I was still using homekit-openhab2 my dimmers would go to 100% when asking Siri to “Switch on the light”. When controlling them by the sliders in the Home app, they would react smoothly.
With -complete the dimmers behave differently. When I say “Switch on the light” the dimmer is set to 0% brightness (no matter what the dimmer level was before switching it off). If I use the sliders in the Home app, the following happens: Say the dimmer is OFF and I set the slider to 50%. The physical dimmer then almost immediately goes to 50% brightness and stays that way. But the slider immediately jumps back to 0% and after a couple of seconds jumps to 50%.
I am using HomeMatic dimmers.
Is anyone experiencing similar issues and can I do something about that?
Hi @jewesta, sorry for the delayed response. Where you one of the open issues on Github? Because someone experienced simliar issues and those should be fixed on the master branch. It would be great to see if this fixes the issue for you as well. I’m planning to release the update during the weekend.
Hey @steilerDev, no need to apologize. Thanks for getting back to me on this! No, I’m not the author of those issues. But I’m following them closely and I’m glad to hear there is a potential fix for the “lights on” --> 0% brightness issue. I’m on a Mac and installed npm via Homebrew. I’m currently trying to figure out how to install the openhab2-complete version from the master. I’m being cautious because I managed to screw up my npm installation some time ago and do not want to do that again. But I’ll gladly test it once I figure that out.
Your plugin is great, btw. Never regretted switching from homebridge-openhab2 to -complete!
@steilerDev : Thank you very much for this contribution. I am running homebridge in docker + homebridge-openhab2-complete. But for light and switch it seems to receive NULL in state, but it is actually working if set as light in json.config. See screen shot from log attached.
This example works fine with light in Homebridge, but not switch:
Switch KaelderVaerVestGulvvarme “Gulvvarme” (gH) {channel=“ihc:controller:haldIHC:ThKaelderVaerVestGulvvarme”}
It works fine with the buildin Homekit support as both switch and light. The Item HAS a value and I know this because I have tried flipping on/off using the openHAB web interface.
@steilerDev : I have now been using your adapter to homebridge and it works fine. I have not testet all types yet, though. Thanks for this contribution👍
Homekit needs a unique identifier and it seems you are deriving that from the name shown in Homekit. Unfortunately, it means you cannot have e.g. two “Ceiling” light in separate rooms. Instead, you could hash the openhab item name to provide a unique identifier to Homekit. This is the way the openhab Homekit adapter works and it never gives duplicate error. Will you consider this?
Also trying this route - only use HomeKit as control UI and it works great.
Hopefully we’ll see TV support soon (HomeBridge already supports it for a long time).
Yes and no, I am deriving the GUID from the name specified in the configuration. This will be the initial name shown in HomeKit, but you can always rename your items in the App without causing collisions. I did this, since adding ten items named “Outlet” would make a distinction difficult, that is why I decided to enforce the requirement to have unique names.
Thanks for your feedback and enjoy!
@steilerDev First of all, thanks! This was really easy to get set up and communicating with both HomeKit and OpenHab.
I’ve bumped into two issues. The first is the “siri turn on the kitchen light” issue where it sets the dimmer to level 0 instead of 100%." I added a comment to the existing issue, but please let me know if there is anything you want me to try to help troubleshoot or resolve that.
The second is that my temperature sensors are reporting in Fahrenheit, but somewhere along the way they get interpreted as Celsius, with Home displays as fahrenheit. So it’s 170 degrees in my kitchen. I thought adding "tempUnit": "Fahrenheit" might fix that, but it didn’t.
Any idea how to change that? Is there a global setting in config.json for temperature unit? I couldn’t find anything via google.
I thought adding