Homekit stopps working after a certain time (~7 days)

my environment:
openHAB 4.x (currently 4.3) running on Synology NAS in Docker-Container

Hi,
I am still facing issues with Apple Homekit and openHAB.
All Apple devices show in HomeKit “not responding” after a while (~ after 7 days).
The only way to get Homekit back working is a restart of openHAB.
I scheduled an automatic restart of homekit twotimes a day in rule…

executeCommandLine(Duration.ofSeconds(6), "sshpass", "-p", "habopen", "ssh", "-oStrictHostKeyChecking=no", "-oUserKnownHostsFile=/dev/null", "-p8101", "openhab@localhost", "bundle:restart", "org.openhab.io.homekit")

… but it does not solve the issue.

I can see in Discovery-App that the openHAB under “_hap._tcp” entry disappears after that certain time and this seems to be the root cause for not responding homekit items - and I am unable to bring it back without restarting openHAB:

I already disabled ipv6 on both NAS network cards.
It makes no difference if openHAB mDNS Service is on or off: Homekit stopps working after some days.

Maybe some of you have an idea, why this is happening?
@yfre - maybe you can help me? :slight_smile:

Any hint is highly appreciated. I am tired of rebooting openHAB on regulary basis.

I read all older threads, e.g.:

…and didn’t find a solution for me yet.

Best regards, Kai

Hello Kai,
this issue is really a mystery.
it was reported by different users. @ccutrer and myself tried to re-produce and to fix it, but it looks like without success.

my impression, it was almost always linked to VMs and quick changes of IP addresses. Sometimes, the IP address remained the same but it was quickly unassigned and assigned again.

we have listener on network changes, it deregister&register homekit bridge from mDNS. the registration process is rather long and sometimes, on quick changes, it is done in the wrong order.

maybe i should just add a switch and disable deregistration on the network change. if the network is stable it shouldnt be an issue

I was one of the affected people in the other thread and worked around the issue by disabling IPv6 on my Synology. Since the fix was published I re-enabled IPv6 and haven’t had a single issue with HomeKit since then.

Note that I do not use Docker, though.

In this case, I don’t think disabling IPv6 on the Synology is relevant because Docker doesn’t use it anyways unless it is specifically enabled.

I found many instances where people have problems with mDNS in Docker because the Container would not see the UDP broadcast messages. I wonder if here something similar happens: The service announcement from OpenHab is sent, but once the caches expire queries from other devices do not arrive in the container.

@April_Wexler Did you enable host networking for the container? This seems to be a prerequisite to get mDNS working.

Thanks for your answer, Eugen.
I am willing to test, if you plan to release a beta-binding with that switch. I am using fixed IP addressed for nearly everything, network changes does to happen very often in my LAN.
I am happy to test and solve that mystery :innocent:

Hi Christian,
yes, I am using host networking: openHAB container does have the same IP as the Synology it is installed on, using port 8080.
Your point with expired cache sounds interesting - but how to test & fix?
I have ipv6 is disabled on all network cards - so it should not be the cause.
greets, Kai

@April_Wexler Do you see this message in the logs?

It should not happen with a static IP and no IPv6.

unfortunately there is nothing in the log.
The only thing I found in the log, is this entry (when I restart the HomeKit binding):

[mekit.internal.HomekitChangeListener] - Created 56 HomeKit items in instance 1 (no change from prior configuration).

But restart of bundle does NOT bring back the “_hap._tcp.” in Discovery App and all devices in Home App (iPhone) do not respond

You’d have to enable trace logging for the HomeKit add-on to see this message.

Also, for me it was sufficient to toggle between the built in mDNS and the one from the extension to make HomeKit work again. No need to restart the bundle or OpenHAB. I guess the extension is sending a new service announcement when this setting is toggled.

You can see both settings in the extension configuration IIRC.

I will try that when HomeKit stops working within next couple of days.
I will report here the status here when I have new logs and new info.
In the meantime: have nice Christmas!

Something worth checking too is whether your WiFi setup is set to auto change channels to try and avoid busy frequencies. It likely isn’t the problem but worth ruling out anyway as I’ve seen this cause network issues in quite a few cases across different projects and it’s quick to test for a persistent problem.

1 Like

i have just published PR to disable bridge restart on network interface changes via configuration.
https://github.com/openhab/openhab-addons/pull/17979

here is the jar file if you want to test before PR gets merged
org.openhab.io.homekit-5.0.0-SNAPSHOT.jar

this could solve the issue with fast network changes.
PR is for OH5.0, so, not sure whether you can test it.

Thank you, Eugen, for providing it. I will give it a try and will test with 5.0snapshot version.
Will it work with 4.3 as well? I will try… :innocent:

@April_Wexler
by default the old behaviour is enabled. you need to switch it off in homekit->advanced

Regarding the PR, not sure if that is the right fix.
You probably looked very close to the log files already, to be sure those don’t give any lead to timing issues?

@April_Wexler would you be able to provide trace level logs of the homekit binding or point to previously trace logs?

I really wonder why the framework get’s informed about the network changes. As you are using docker, deos your docker or host have any log files that show anything usefull regarding the network going up/down. It might even be as simple as a wifi driver, router firmware update or faulty LAN cable and can probably name a few more.

1 Like

Hello @lsiepel & @yfre,
thank you very much for taking the time to take a closer look at my problem.

Unfortunately, I can’t provide any more logs from the container or from openHAB at the moment, as I always have to wait until HomeKit stops working.
So I’m currently now waiting again for the day when HomeKit stops working again.

The only thing I regularly notice is that “_hap._tcp” entry disappears - as described above.

I have a Unifi network with 5 WLAN access points and of course I can’t rule out the possibility of a WLAN channel change. I will try disabling this feature. But there are more than 60 WLAN devices in my network without any problems yet… :thinking:

As “always in IT”: since my last post here HomeKit is running without any issues :frowning:

i have similar setup - Unifi with 4 WLAN access points, similar amount of devices, 100+ homekit items in OH. no additional channel or AP locking configured.
the difference however, my OH is running on odroid natively, not in a VM.
never had the issues with _hap._tcp disappearing.

1 Like

You should have posted earlier :grin:

1 Like

Hello.

Do you have more than one bride?
My issue is still persistent …

Hi Jonas,
i have only one bridge.
please remind me, do you run openHab on VMs, docker, synology?

are you using OpenHAB 4.x or already on version 5.0?
you can try to

  • download Microsoft OneDrive
  • put it into addon folder,
  • disable “Listen to network changes” via openHAB UI-> Homekit settings

Sorry for the lack of information …
I am running openHAB 4.3.0 Build #4407 on a Synology NAS (Docker Container).

Thanks for the link i will try it tomorrow and report back.

EDIT: I tried with the 5.0 snapshot (I assume the addon in your link is provided in the snapshot) and i still get the issue.