HomeKit No Longer Functioning

Have you tried increasing the logging level for the underlying HomeKit library? The doc page for the addon has the required console command. If you’re not seeing the initialization loglines after that, it’s a good indication that the addon isn’t loading at all.

Ok I hate when people always say it was me asking or being present that made things work, but this time hte shoe is on the other foot! :wink: Now the only caveat is it isn’t working, but it’s giving more than it did before.

So I did put it in TRACE mode before (at least I believe I did, perhaps that is whats different) - but last time it didn’t show the port listener at all which is one of the big things I was looking for. This time however it is.

==> /var/log/openhab2/openhab.log <==
2017-09-29 08:51:35.088 [INFO ] [com.beowulfe.hap.HomekitRoot        ] - Added accessory openHAB
2017-09-29 08:51:35.761 [INFO ] [pl.http.impl.NettyHomekitHttpService] - Bound homekit listener to /0:0:0:0:0:0:0:0:9124
2017-09-29 08:51:35.760 [INFO ] [com.beowulfe.hap.HomekitRoot        ] - Added accessory Office
2017-09-29 08:51:35.802 [INFO ] [ap.impl.jmdns.JmdnsHomekitAdvertiser] - Advertising accessory openHAB
2017-09-29 08:51:35.808 [INFO ] [ap.impl.jmdns.JmdnsHomekitAdvertiser] - Registering _hap._tcp.local. on port 9124
2017-09-29 08:51:35.814 [INFO ] [pl.http.impl.NettyHomekitHttpService] - Resetting connections
2017-09-29 08:51:35.840 [INFO ] [com.beowulfe.hap.HomekitRoot        ] - Added accessory Dining Room
2017-09-29 08:51:35.847 [INFO ] [pl.http.impl.NettyHomekitHttpService] - Resetting connections
===============Shortened/Scrubbed Log - these repeat for all devices enabled==========
2017-09-29 08:51:35.851 [INFO ] [com.beowulfe.hap.HomekitRoot        ] - Added accessory Hallway
2017-09-29 08:51:35.859 [INFO ] [pl.http.impl.NettyHomekitHttpService] - Resetting connections
==> /var/log/openhab2/events.log <==
2017-09-29 08:51:38.427 [thome.event.ExtensionEvent] - Extension 'misc-homekit' has been installed.

So this is the log output, which appears as though it’s functioning. But I’m still not able to see the device. The next thought I would have had is around some type of a network hiccup or problem, but I don’t believe that since I am able to use a Node-RED HomeKit node set, that registers and shows up devices perfectly fine. No they aren’t running on the same port, but in a matter of seconds I can create an item and it immediately shows up on the HomeKit side. So I’m not believing that it’s a network problem. If it is, I think it may not be on my local network, but some sort of internal to OH type of networking problem.

That looks like your problem. Try setting the network interface explicitly using the configuration key org.openhab.homekit:networkInterface

I thought that seemed a bit off. Figured maybe it just reported that as the equivalent of a “localhost” entry.

Where can I alter or set this configuration key? It actually looks based on that format even that it’s attempting to broadcast on IPv6, which my device doesn’t have assigned nor is IPv6 traffic functioning on my home network (blocked by the switch/router).

You can change it in PaperUI via Configuration -> Services -> IO -> Homekit Configuration

Ohhh, ya that is set. I wandered into some deeper configs from some other posts from the Karaf console side. Still no luck in changing it.

It appears to be set correctly in multiple places, but for some reason it’s not loading it this way. I’ve set it via PaperUI as you just indicated. I noticed there was no HomeKit.cfg file loaded into /services from the PaperUI config, so I manually created that file. And I also tinkered at the Karaf Console with the config:edit config:property-set and config:update commands. Use the list option to show it successfully, but still no luck. Anytime I try to restart the bundle, clear the pairings, or anything - I’m shown the same address attachment.

Is there somewhere else I can look for why this isn’t taking the IP correctly? I’m still also puzzled by the address it’s inputting to substitute - it has 8 zeros with dot separators. Nothing really maps up that way, not even IPv6 like my previous thought.

Hmm… I’m not sure. The configs are part of the magical “just works” part of openhab for me - I’ve never dug into how they’re loaded.

@Kai - I hate to tag you into a thread, but I know you’ll at least have the right direction. Who would be able to help take a look at a binding config loading? Hoping you might be able to provide some direction.

Specifically it looks like maybe something has changed in OH core framework or core code that is now causing an issue in getting the proper config to load for this plugin. I know I can’t speak for everyone, but there are A LOT of people who do use this plugin. The work @beowulfe has done is amazing. This operates smoothly and flawlessly for me for quite some time. Up until some time after I updated off the Aug 25 2.2 Snapshot.

There has been a lot of talk of HomeKit integration not working in a lot of places. I don’t know if anyone has specifically dug into this. But I’ve gotten to the point of identifying that at least in my scenario, the config settings are not being loaded properly. Specifically in this case, it’s around binding to the correct IP interface.

So to summarize, your issue is that the configuration is not correctly set?
But

openhab> config:edit org.openhab.homekit
openhab> config:property-list 

shows you the expected values?
Then I do not really have a clue. I also just checked with the debugger that any updates that are done through the Paper UI end up being passed to the Homekit add-on.
Can you reproduce your issues on a fresh installation? Maybe something is screwed up on your installation?
If there is a way to reproduce, please provide the exact steps.

Regards,
Kai

Kai - thanks for taking a look, really appreciate the quick response. Yes everything you said is correct.

I was thinking about testing a fresh install - it’s just always difficult to do (openHABian running on Pine64 in the basement). I may see if I can try spinning up a docker instance like I used to use quickly to test/validate. Hopefully I can do this in the coming day.s

1 Like

Ok sorry for the delay, but I was able to get a test docker container up and running today. I’ve found the same result. Which is good - in that it may not be just my current setup. The bad - it’s still not working. So here is what I’ve found:

Setup a new docker container, created a basic items list with 2 sample items from a .items file. After doing this I added on the HomeKit binding and NOTHING else - to help ensure this is as fresh an install/setup as possible. Less polution from other addons/bindings. Once the system was up and running, I configured the HomeKit binding with an IP of 10.0.10.60 through PaperUI. If I change the IP at all, an interesting quirk is that I also do not see the listener change, at least not in a log line, it simple will indicate that it is Resetting connections and Adding the accessories again. You’ll see this behavior below. Each set of those messages was from an IP change.

Lastly, I dropped down to Karaf again to validate that the config has indeed been set. It seems it’s still not picking this up. It is indeed set, but it’s not actually grabbing that IP info. Docker container is set with MacVLAN so it has it’s own IP and stack, it was set with priveleged mode as well to ensure no problems with configs as needed, and no mappings were made to local filesystems so no permission problems on access. Running OH 2.2.0-SNAPSHOT-arm64 - build #1056.

2017-10-08 11:49:59.956 [INFO ] [com.beowulfe.hap.HomekitRoot        ] - Added accessory openHAB
2017-10-08 11:50:00.040 [INFO ] [com.beowulfe.hap.HomekitRoot        ] - Added accessory Virtual Test
2017-10-08 11:50:00.041 [INFO ] [pl.http.impl.NettyHomekitHttpService] - Bound homekit listener to /0.0.0.0:9125
2017-10-08 11:50:00.046 [INFO ] [pl.http.impl.NettyHomekitHttpService] - Resetting connections
2017-10-08 11:50:00.046 [INFO ] [ap.impl.jmdns.JmdnsHomekitAdvertiser] - Advertising accessory openHAB
2017-10-08 11:50:00.050 [INFO ] [ap.impl.jmdns.JmdnsHomekitAdvertiser] - Registering _hap._tcp.local. on port 9125
2017-10-08 11:50:22.081 [INFO ] [com.beowulfe.hap.HomekitRoot        ] - Added accessory openHAB
2017-10-08 11:50:22.088 [INFO ] [com.beowulfe.hap.HomekitRoot        ] - Added accessory Virtual Test
2017-10-08 11:50:22.092 [INFO ] [pl.http.impl.NettyHomekitHttpService] - Resetting connections
2017-10-08 11:50:32.435 [INFO ] [com.beowulfe.hap.HomekitRoot        ] - Added accessory openHAB
2017-10-08 11:50:32.442 [INFO ] [com.beowulfe.hap.HomekitRoot        ] - Added accessory Virtual Test
2017-10-08 11:50:32.447 [INFO ] [pl.http.impl.NettyHomekitHttpService] - Resetting connections
openhab> log:set trace com.beowulfe.hap
openhab> config:edit org.openhab.homekit
openhab> config:property-list
   networkInterface = 10.0.10.60
   pin = 031-45-154
   port = 9125
   service.pid = org.openhab.homekit
   thermostatAutoMode = Auto
   thermostatCoolMode = CoolOn
   thermostatHeatMode = HeatOn
   thermostatOffMode = Off
   useFahrenheitTemperature = true
openhab> 

If you’d like to reproduce - simply setup a fresh install. Upon initial setup (I choose standard) - then install the HomeKit addon. From here I will configure the Addon under the services section. Lastly I’ll even restart the bundle or even re-install to get a fresh start on it with config. The logging can be set: log:set trace com.beowulfe.hap so you can see these trace level logs. At this point it’s as fresh an install as can be, but still will show the listener binding to 0.0.0.0:9124.

Also it should be noted - I believe the default behavior is that the bindings should be supplied the default address being used by OH - the setting in the HomeKit config is more of an override in case you want it on a different IP. The bottom line though is that if I list it in the Config, it should definitely be binding to that IP but it is not.

I was encountering this exact same bug on my (somewhat) fresh install on a RPI3! I had the Homekit addon installed and configured via the PaperUI, but every restart of OpenHab2 would show the same Bound homekit listener to /0:0:0:0:0:0:0:0:9124 message and, relatedly, all attempts from HomeKit to connect would be ignored. After reading this and several other threads, I was pretty sure that my configuration was correct.

At this point I thought, “well what if I turn it off and back on again?” I had tried restarting OpenHab itself several times, but hadn’t tried restarting the entire hardware system. One sudo reboot later, the Homekit addon bound its listener to the correct port and I was up and running in less than 5 minutes. Is it possible that there’s an interaction between changing the configurations in the UI and those values being passed to the addons that might be kickstarted or corrected by a whole system reboot but not by a OpenHab restart alone?

So, after many hours of struggle with same problem, I finally decided to sign up and ask for help…

I’ve tried pretty much everything i could think of… changing IP’s, changing ports, creating config files for service, for items and everything, tried from several devices (iOS 11, iPhone X, iPad…), service re-installs and not only… and still no luck. :frowning:

21:13:53.771 [INFO ] [mpl.http.impl.NettyHomekitHttpService] - Resetting connections
21:13:53.783 [INFO ] [mpl.http.impl.NettyHomekitHttpService] - Bound homekit listener to /0:0:0:0:0:0:0:0:51826

Configs for the last time were as follows:

openhab> config:edit org.openhab.homekit                                                                                                             
openhab> config:property-list                                                                                                                        
   networkInterface = 192.168.8.151
   pin = 031-45-296
   port = 51826
   service.pid = org.openhab.homekit
   thermostatAutoMode = Auto
   thermostatCoolMode = CoolOn
   thermostatHeatMode = HeatOn
   thermostatOffMode = Off
   useFahrenheitTemperature = false

I get this each time but with different behaviour in Home.app…
Sometimes, it adds the OpenHAB bridge but says “Not supported” and no devices appear
And other times, it just doesn’t add it, although from log, it looks like it almost adds it, but something breaks while adding…

Your help would be much appreciated!

Just want to give this a +1. I am experiencing the exact same issues - I have even had home kit running flawlessly for about a month. All of a sudden “items not responding” and unable to reconnect even after doing all of the above…mine also listening to 0.0.0.0, even though the correct IP is set…

Same problem here, with openHAB 2.3:

homekit.cfg:

org.openhab.homekit:networkInterface=192.168.x.y

Karaf:

openhab> config:property-list
   networkInterface = 192.168.x.y

logs:
2018-06-05 14:39:08.037 [INFO ] [pl.http.impl.NettyHomekitHttpService] - Bound homekit listener to /0:0:0:0:0:0:0:0:9123

Any solution?
Thanks.

I can somehow confirm @zackzachariah described behavior. I have it running in docker, works perfect and all of a sudden after 9 hours the Openhab shows up as unsupported in the home app.

After turning off and on the docker container it works again and all lights appear. But they all appear in the room of the OH bridge not in their correct room in the Home app

@Kai to add to this it happens the moment you save the items file that has homekit configured items in it. Homekit items work perfectly in home app and when I save the items file in Visual Studio Code (without changing anything, just added or deleted one blank line) I get this in the logs. the items file is refreshing and all items disappear in Home app.
Turning off and on the docker makes them re-appear but all in the room of the OH bridge, so room info is lost in Home app.

==&gt; /logs/openhab.log &lt;==

2018-08-26 07:27:18.328 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'nikobus.items'

2018-08-26 07:27:18.397 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S1_O1_lichtWC in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.434 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S1_O2_lichtbadkamer in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.449 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S1_O3_lichtkeuken in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.464 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S1_O4_raamtransparant in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.482 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S1_O5_lichtbureauzij in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.498 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S1_O7_lichtgarage in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.597 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S1_O8_lichttraphal in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.611 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S1_O11_lichteetplaats in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.737 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S1_O12_kastkinesis in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.752 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S2_O1_lichtnisbed in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.765 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S2_O2_lichtsterrenhemel in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.777 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S2_O3_lichtterras in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.788 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S2_O4_lichtoversteektuin in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.799 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S2_O5_lichtoversteekvoor in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.810 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S2_O6_lichtspotvoordeur in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.824 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S2_O7_lichtledvoordeur in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.839 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S2_O8_lichtleddressing in ManagedMetadataProviderImpl, because it does not exists.

2018-08-26 07:27:18.854 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:NB_S2_O9_lichtleddouche in ManagedMetadataProviderImpl, because it does not exists.

even though this is a very old thread, I still encountered this issue with openHAB 3. HomeKit was fully functional with openHAB 2 and somewhere on the way to 3 or within the milestone build history something went wrong (in my setup probably, since this topic is already discussed). HomeKit was unresponsive, adding the bridge again failed. Clearing Pairings did not work…

Updating the HomeKit config showed Bound homekit listener to /0.0.0.0:9124

But checking the config as suggested by Kai above, showed the correct values. I set the values via WebUI not via file.

Toggling the “Use openHAB mDNS service” in the webUI configuration made HomeKit listeners bind to the correct interface! Afterwards, the listener is bound correctly regardless of the state of the mDNS switch.

I’m wondering that there is no description on that switch in the documentation, and therefore not for the text based config.

Sadly, after a restart of my Docker container I’m back at
Bound homekit listener to /0.0.0.0:9124
when openHAB mDNS is disabled. Toggling mDNS → working again.
When restarting with openHAB mDNS enabled it appears to be working… Let’s see how stable this is.

What’s the deal with this mDNS setting? Is there any downside on using openHABs mDNS and not a separate instance?

1 Like

Hi all,

I experiance exact the same issue as above and Toggling the “Use openHAB mDNS service” in the webUI configuration made HomeKit listeners bind to the correct interface! Afterwards, the listener is bound correctly regardless of the state of the mDNS switch.

Setup:
Openhabian OH3 latest snapshot on rPI4

kind regards,
J

there is / has been a lot of discussion about mDNS functionality in this thread which is much more recent:

apparently, using openHABs mDNS service should save memory resources. It should work the same way, as the underlying mDNS library is the same. But there are some issues discussed in the linked thread, therefore the author made it optional to use it (switch).

relevant PRs: