Unstable Connectivity with 3.0.0

[cptbalusgit]

I experience unstable connectivity since upgrading to 3.0.0. I regularly loose control/states in Homekit/Home+ App. Stop and Start of Service solves the issue - could be implemented via cron - but obviously not the desired working mode.

Does anyone experience same issue?

KNX GW: SMART CONNECT KNX Remote Access 7.0.743.0 (VLAN1) HK Bridge: Debian auf Raspi4 (VLAN1) Homekit Steuerzentralen: Apple TV 4K (VLAN1), Homepod Mini (VLAN10) --> forced it now to Apple TV 4K in VLAN1

VLAN1 and 10 have access to all VLANs, so not sure it if might be related to this change to Homepod Mini in VLAN10

Settings show securely connected to KNX GW (TCP) and Homekit Bridge reachable. I see all knx bus group adresses live in monitoring still via url.

I can see 2 out of my 99 devices and through url I can control them and they correctly respond. All visible in knx bus monitoring of hkknx. In Homekit/Home+ App they are not responding or showing any state.

Service is running.

● hkknxd.service - HomeKit Bridge for KNX
     Loaded: loaded (/etc/systemd/system/hkknxd.service; enabled; preset: enabled)
     Active: active (running) since Thu 2024-10-31 07:00:32 CET; 5 days ago
   Main PID: 45795 (hkknx)
      Tasks: 13 (limit: 3909)
        CPU: 10min 25.588s
     CGroup: /system.slice/hkknxd.service
             └─45795 /home/admin/hkknx/hkknx --db=/home/admin/hkknx/hkknxdatabase --verbose

Nov 05 10:56:44 hkknx hkknx[45795]: DEBUG 2024/11/05 09:56:44 accessories.go:1303: accessory states: homekit done; waiting 1s
Nov 05 10:56:45 hkknx hkknx[45795]: DEBUG 2024/11/05 09:56:45 accessories.go:1303: accessory states: homekit done; waiting 1s
Nov 05 10:56:46 hkknx hkknx[45795]: DEBUG 2024/11/05 09:56:46 accessories.go:1303: accessory states: homekit done; waiting 1s
Nov 05 10:56:47 hkknx hkknx[45795]: DEBUG 2024/11/05 09:56:47 accessories.go:1303: accessory states: homekit done; waiting 1s
Nov 05 10:56:48 hkknx hkknx[45795]: DEBUG 2024/11/05 09:56:48 accessories.go:1303: accessory states: homekit done; waiting 1s
Nov 05 10:56:49 hkknx hkknx[45795]: DEBUG 2024/11/05 09:56:49 accessories.go:1303: accessory states: homekit done; waiting 1s
Nov 05 10:56:50 hkknx hkknx[45795]: DEBUG 2024/11/05 09:56:50 accessories.go:1303: accessory states: homekit done; waiting 1s
Nov 05 10:56:51 hkknx hkknx[45795]: DEBUG 2024/11/05 09:56:51 accessories.go:1303: accessory states: homekit done; waiting 1s
Nov 05 10:56:52 hkknx hkknx[45795]: DEBUG 2024/11/05 09:56:52 accessories.go:1303: accessory states: homekit done; waiting 1s
Nov 05 10:56:53 hkknx hkknx[45795]: DEBUG 2024/11/05 09:56:53 accessories.go:1303: accessory states: homekit done; waiting 1s

Systemprotocol in url shows "waiting for new task" every 1s, everything in between as shown here: (192.168.10.216 --> Homepod Mini)

DEBUG | 2024/11/05 10:03:01 | status.go:359 | homekit: waiting for new task
DEBUG | 2024/11/05 10:03:02 | status.go:359 | homekit: waiting for new task
...

DEBUG | 2024/11/05 10:05:12 | notification.go:66 | send event to 192.168.10.216:49630:
EVENT/1.0 200 OK
Content-Length: 68
Content-Type: application/hap+json
 
{"characteristics":[{"aid":75,"iid":12,"value":22.899999618530273}]}
...
DEBUG | 2024/11/05 10:05:30 | app.go:777 | ntp: disabled
...
INFO | 2024/11/05 10:07:31 | bool.go:18 | Unable to unpack dpt 1.002 from [0 46 154]
...
DEBUG | 2024/11/05 10:07:56 | status.go:359 | homekit: waiting for new task
...

EVENT/1.0 200 OK
--
Content-Length: 51
Content-Type: application/hap+json
 
{"characteristics":[{"aid":42,"iid":10,"value":0}]}
...
DEBUG | 2024/11/05 10:11:56 | telemetry.go:76 | telemetry: tsdb: no dpt found for 0/0/4
...
DEBUG | 2024/11/05 10:13:38 | status.go:359 | homekit: waiting for new task

[brutella]

Those log outputs are debug messages and are not the result of an error.

Have you checked if the dns-sd entry for the HomeKit bridge is visible from your iOS device? https://hochgatterer.me/hkknx/docs/help/homekit-connection-issues/

[cptbalusgit]

Didn't check at the time via dns-sd entry. I will close issue, as I now manually forced Apple TV as control center which is on same VLAN as Raspi - all mobile devices are on different VLAN, but have access to Apple TV. Worked smoothly like this in the past, but potentially adding Homepod Mini into the system might have caused the issue as sometimes it seems to automatically switch to Homepod Mini as control center. Will monitor and will reopen if issues occurs again and check dns-sd then.

[cptbalusgit]

So issue occured again - although slightly different. Homekit Bridge is responding with "not reachable" in Homekit App dns-sd entry does not exist No status visible on Homekit/Home+ App Connection to the KNX gateway is ok based on web interface HomeKit bridge can be reached based on web interface

This is knx sending event to iPhone IP 192.168.10.152

{"characteristics":[{"aid":59,"iid":15,"value":90}]}
--
DEBUG | 2024/11/07 19:02:38 | notification.go:66 | send event to 192.168.10.152:51219:
EVENT/1.0 200 OK
Content-Length: 52
Content-Type: application/hap+json

and all sorts of other debug events - no ERROR messages

DEBUG | 2024/11/07 20:00:11 | status.go:228 | bus load: request done
DEBUG | 2024/11/07 20:00:11 | status.go:171 | bus load: request done
DEBUG | 2024/11/07 20:00:11 | status.go:356 | homekit: request done
DEBUG | 2024/11/07 20:00:32 | telemetry.go:76 | telemetry: tsdb: unable to parse 0001
DEBUG | 2024/11/07 20:02:30 | notification.go:66 | send event to [fe80::109f:54e3:6c44:3044%eth0]:61179:
EVENT/1.0 200 OK
Content-Length: 52
Content-Type: application/hap+json
{"characteristics":[{"aid":73,"iid":12,"value":23}]}

I can ping iPhone from raspi via ssh access on raspi. I can ping RasPi from iPhone. So communication between 192.168.10.152 (iPhone) and 192.168.1.79 (RasPi) in general is not an issue. Both Vlan can clearly communicate with each other.

mDNS Ports 5353 and 3671 are explicit open from and to all IPs and networks before any vlan-vlan restrictions happen. On unifi devices vlan-vlan is open unless configured otherwise.

KNX IP GW is configured static with 192.168.1.219:3671 via tcp.

Especially via dns-sd I can see all IoT devices in e.g. vlan80 which is completely isolated and only able to communicate to internet but reachable from vlan10 which is main network for our own mobile devices.

From same vlan10 on W11 Laptop I can access 192.168.1.79:8080 locally and all devices are available with status and I can control them correctly as well.

Have to stop and restart service now. Rest of our family not really willing to live without Homekit for longer :smile:

Any idea on this behavior?

[brutella]

dns-sd entry does not exist

This is a strong indication that your network configuration does not properly route multicast messages between your vlans. I would check that first.

mDNS Ports 5353 and 3671 are explicit open from and to all IPs and networks before any vlan-vlan restrictions happen.

But is multicast allowed between vlans?

[cptbalusgit]

Yes - it is on for all relevant vlans. If I would have a general issue with it, it would not work from the beginning. What changes over days without any changes to Network configuration, that would trigger loss of communication?

I can see all hombridge entries in dns-sd in _hap._tcp. and they are absolutely stable which are running on the same RasPi. I can also see my Bosch Home ControllerII in those entries which is a separate controller feeding Bosch Accessories into Homekit - absolutely stable as well.

It was stable in the same setup with 2.8.2b1. So I don't get what has changed since. I will potentially downgrade as the rest of the household is not happy with the stability at the moment.

I also can access web interface directly from the same mobile iOS device and it works.

So it must be something between hkknx and homekit itself which as control center uses the Apple TV 4K. I can ping Apple TV from RasPi via ssh access on it as well.

So how does hkknx communicate with Homekit control center? And can I somehow check this?

[brutella]

Have you tried installing the latest beta version 3.1.0-b9.3? It includes a mDNS fixed for Linux.

[cptbalusgit]

Just updated to 3.1.0 official release as this is available now. Will close and reopend if issue occurs again. Let's wait and see.

[cptbalusgit]

So it worked now 2 weeks stable without issue. So it seems the mDNS fix for Linux in 3.1.0 works solid.