Homekit stops working after some hours. openhab 3.4.0

I upgraded on Monday.

This topic is not solved, right?
At least for me I still have the problems described in this thread. My Homekit loses conection even with mDNS ON or and with mDNS OFF.
I tried OH3.4.4 and now I am on OH4.0 - no change. After some hours Homekit stops working.

Execeuting a ‘bundle:restart org.openhab.io.homekit’ solves the problem immediately.
Isn’t there another solution available? :slight_smile:

My OH is running in a Docker Container on Synology / I am using fixed IPs only / OH4 / mDNS on or off - does not have an effect / ipv6 is disabled

I haven’t had an unexpected disconnect for HomeKit in several months. I am running a custom build of the addon with several commits adding new features that I haven’t had time to polish up PRs for, but I don’t believe any of them should include stability improvements (GitHub - ccutrer/openhab-addons at homekit; beware I rebase this branch each time I update openHAB). The big thing for me was disabling the shared mDNS. I know the root cause for that (openHAB’s network manager rebuilds it on any network interface change, but HomeKit has cache the underlying JmDNSClient, and only restarts itself if the network change is for the interface we’re using), but a fix will be tricky (even if we always restart, or we improve openHAB core to only restart the JmDNSClient when the appropriate interface changes, there’s still a race condition because both objects are notified of the same event at the same time in different threads).

Hi,
I didn’t have any homekit disconnection for months, until I upgraded to from 3 to 4.0.1.

I now get this once every two weeks approximately.

2023-08-11 10:51:09.329 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - HomeKit bridge reacting on network interface changes.
2023-08-11 10:51:09.330 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - removed interface /fe80:0:0:0:18a9:624a:d4e8:2591%wlan0
2023-08-11 10:51:09.332 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - removed interface /192.168.100.200
2023-08-11 10:51:09.332 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - stopping HomeKit bridge
2023-08-11 10:51:09.333 [TRACE] [penhab.io.homekit.internal.Debouncer] - stop debouncer
2023-08-11 10:52:11.440 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - HomeKit bridge reacting on network interface changes.
2023-08-11 10:52:11.442 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - starting HomeKit bridge instance 1
2023-08-11 10:52:11.447 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - no suitable mDNS server for IP /192.168.100.200 found
2023-08-11 10:52:11.448 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - create HomeKit server with dedicated mDNS server
2023-08-11 10:52:11.800 [WARN ] [nhab.io.homekit.internal.HomekitImpl] - could not initialize HomeKit bridge: No such device
2023-08-11 10:57:26.823 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - HomeKit bridge reacting on network interface changes.
2023-08-11 10:57:26.825 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - removed interface /fe80:0:0:0:dea6:32ff:feeb:d740%wlan0
2023-08-11 10:57:26.826 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - removed interface /10.41.0.1
2023-08-11 10:57:26.827 [WARN ] [nhab.io.homekit.internal.HomekitImpl] - trying to start HomeKit server but it is already initialized

So it seems that it is trying to restart the bundle but it can’t because it hasn’t been correctly stopped.

In fact:

openhab> bundle:status org.openhab.io.homekit 
Active

Besides, do you happen to know what that 10.41.0.1 interface is? I have nothing like that in my network.

Hi Matteo
10.41.0.1 must be something on your openHAB machines. it says sometning about wlan0.
to me, it looks like, wlan0 changes the ip from 192.168.100.200 to 10.41.0.1 and back for a very short time.
openHAB homekit see that 192.168.100.200 is down and stops the bridge/addon for that address, while homekit is busy with stopping the bridge, the interface is up again, and homekit starting the bridge, but then the wlan0 is down again (see “could not initialize HomeKit bridge: No such device”)
 and so on.

so. interface and up and down faster than homekit with up/down of the bridge (addon). as result you can get partially started/stopped homekit addon with all possible strange effects.

same setup here. Docker on Synology and latest OH4 Milestone. Every now and then homekit connection is broken :frowning:

Hi @StefanH
same here - maybe it helps you:
I implemeted a workaround for myself and do a restart of homekit binding two times a day. Since I implemented this (OH 3 or 4 running in a Synology Docker) I didn’t had problems anymore.

rule:

rule "Homekit Bundle restart"
when 
    Time cron "0 0 7 1/1 * ? *"  or  // 7:00h 
    Time cron "0 0 16 1/1 * ? *"     // 16:00h 
then
    logInfo("Homekit", "Homekit-Bundle-Restart")
    executeCommandLine(Duration.ofSeconds(6), "ssh", "-p", "8101", "openhab@localhost", "bundle:restart", "org.openhab.io.homekit")   
end

Prerequiste is that you install SSH in your container:

apt-get update
apt-get upgrade
apt-get install openssh-client

add public-key of openhab user to key.properties:

su openhab
ssh-keygen  -> enter -> enter
cp /openhab/.ssh/id_rsa.pub /openhab/userdata/id_rsa.pub  //make file available for usage outside of container

copy public key from openhab user in id_rsa.pub and paste it into keys.properties.
This enables password-free logon via SSH and allows the SSH command execution in the rule above.

Location of the two files you need to work with:
/userdata/id_rsa.pub → take key from user openhab
/userdata/etc/keys.properties → paste key

id_rsa.pub looks like this (key starts with “AAA” and ends with “=”)

ssh-rsa AAA...key...= openhab@openhab4.0.2

paste key (starting with “AAA” and ends with “=”) into keys.properties - it should look like this:

openhab=AAA...key...=,_g_:admingroup

This workaround works fine for me until there is a another solution available :slight_smile:

1 Like

thanks! I’ll give it a try. For now I’ve just installed cron inside the container (ssh and sshpass did already exist) and configured the cronjob like:

0 */8 * * * root /usr/bin/sshpass -p habopen ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -p 8101 openhab@localhost bundle:restart org.openhab.io.homekit

Tested it first to run every minute, which worked out great. Let’s see tomorrow :slight_smile:

Meanwhile I’ve implemented the rule like you, but I restart the bundle even three times a day (every 8 hours). Problem is solved immediately after restart, however the issue seems to come back every day :frowning:

can you see in OG Log the creation of homekit items, when bundle restart was executed?
When I do a bundle restart I see in the log:

2023-09-20 09:28:13.091 [INFO ] [rg.openhab.core.model.script.Homekit] - Homekit-Bundle-Restart
2023-09-20 09:28:15.251 [INFO ] [mekit.internal.HomekitChangeListener] - Created 38 HomeKit items in instance 1 (no change from prior configuration).

This works for me since 2 weeks (without OH reboot).

yep

openhab.log:2023-09-18 00:00:01.071 [INFO ] [mekit.internal.HomekitChangeListener] - Created 4 HomeKit items in instance 1 (no change from prior configuration).
openhab.log:2023-09-18 08:00:03.029 [INFO ] [mekit.internal.HomekitChangeListener] - Created 4 HomeKit items in instance 1 (no change from prior configuration).
openhab.log:2023-09-18 16:00:03.081 [INFO ] [mekit.internal.HomekitChangeListener] - Created 4 HomeKit items in instance 1 (no change from prior configuration).
openhab.log:2023-09-19 00:00:03.029 [INFO ] [mekit.internal.HomekitChangeListener] - Created 4 HomeKit items in instance 1 (no change from prior configuration).
openhab.log:2023-09-19 08:00:01.038 [INFO ] [mekit.internal.HomekitChangeListener] - Created 4 HomeKit items in instance 1 (no change from prior configuration).
openhab.log:2023-09-19 16:00:01.031 [INFO ] [mekit.internal.HomekitChangeListener] - Created 4 HomeKit items in instance 1 (no change from prior configuration).
openhab.log:2023-09-20 00:00:01.025 [INFO ] [mekit.internal.HomekitChangeListener] - Created 4 HomeKit items in instance 1 (no change from prior configuration).
openhab.log:2023-09-20 08:00:03.025 [INFO ] [mekit.internal.HomekitChangeListener] - Created 4 HomeKit items in instance 1 (no change from prior configuration).
openhab.log:2023-09-20 09:08:36.016 [INFO ] [mekit.internal.HomekitChangeListener] - Created 4 HomeKit items in instance 1 (no change from prior configuration).

As you can see, HomeKit items were created today 8am and just one hour later it didn’t work anymore.
The restart at 9:08am was a manual restart (same command on CLI) to check if the issue was really fixed, and it was!

I still see this issue every couple of weeks with OpenHab 4.0.2. The easiest solution for me is to switch OpenHab mDNS service on or off. Which means, the issue happens with both.

Nothing unusual in the logs (trace level enabled). I see a couple of “HomeKit bridge reacting on network interface changes.” messages, but I see them every day without a problem, so I can’t say they are related.

I wouldn’t rule out that this is a self-healing issue and I’m just so unfortunate to hit exactly the time when it’s visible and it may had been resolved automatically some minutes later. On the other hand, I’d seen the unresponsive state for two days earlier this month when I was not at home and didn’t bother to toggle the configuration again.

I run OpenHab on a Synology ARM v7, manual installation. Apart from this issue I’m really happy with it. The power of Java! :muscle:

Edit: My Synology box uses a fixed IPv4 address, but IPv6 is enabled and mDNS uses a v6 ULA which is surprisingly stable. I see this combination of log entries with the exact same address since one month now a couple of times per day:

2023-10-19 08:55:24.823 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - HomeKit bridge reacting on network interface changes.
2023-10-19 09:26:30.861 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - HomeKit bridge reacting on network interface changes.
2023-10-19 09:26:30.862 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - removed interface /fd5b:1fda:6ee5:4c9e:211:32ff:fe75:ce6c%eth0

this can be related to network changes.

  • on network interface down event, openhab addon remove it from mDNS and stops listening to it
  • on network interface up event, openhab addon start listening on this interface and add it to mDNS

sometimes, if these 2 events are happening too quickly the steps sequence get mixed and mDNS remains empty.

please make ensure you have correct IPv4 in openhab->homekit settings. this helps sometimes

1 Like

I have the correct IPv4 address in the HomeKit configuration.
I have no idea what the network interface changes could be. The Synology NAS runs 24/7 on a fixed IPv4 address. Maybe the system changes public IPv6 addresses through privacy extensions from time to time?

Edit: Just to try it I disabled the IPv6 support on the NAS. HomeKit reacted with removing the link local (fe80) and global IPv6 addresses. I will monitor if I still see the many network interface changed messages


2023-10-21 22:35:12.055 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - HomeKit bridge reacting on network interface changes.
2023-10-21 22:35:12.056 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - removed interface /fe80:0:0:0:211:32ff:fe75:ce6c%eth0
2023-10-21 22:35:12.056 [TRACE] [nhab.io.homekit.internal.HomekitImpl] - removed interface /2003:redacted%eth0

I have the same problem for many months
 I have a Synology DS218+ running OpenHAB 4.0 (I had also this issue with OpenHAB 3.x) within a Docker container. IPV6 is disabled and Homekit stops working after a couple of hours. Switching off mDNS and then switching on solves the problem temporarily. I will be happy to find a solution because I cannot use the Homekit binding due to this issue. By the way, is there a way to deactivate /activate mDNS from a rule/unix command ?

The network interface changes logs is not showing up anymore after I disabled IPv6 for my NAS. I don’t think this is good, but at least it eliminates a possible source of issues. I will wait the next couple of weeks to see if the connection from Homekit is stable now.

I can’t say for Docker. Did you check the log files for network interface changes like I did? This may give a hint.
For automated solutions in August some scripting was discussed to restart the Homekit bundle, which also resolves the issue.

I saw the post to restart the homekit bundle. I tried to restart it on a regular basis using the following command outside the container:

sudo docker exec -it openhab /openhab/runtime/bin/client -p xxxx bundle:restart org.openhab.io.homekit

Unfortunately, that did not work when using the Synology Task Scheduler. I need to investigate why it failed.

Thanks for the help

just got the idea - maybe i can add to homekit addon the option to completely ignore interfaces with ipv6. the network change was often reported for ipv6 only
 so, if ipv4 is sufficient, then we can ignore ipv6 in the add-on, or at least make it configurable.

Would it be possible to only bind to the configured address?