search

brutella / hap

The HomeKit Accessory Protocol (hap) implemented in Go
Apache License 2.0
346 stars 39 forks source link

Manually setting the accessory ID causes accessory to be unresponsive #50

Closed annismckenzie closed 8 months ago

annismckenzie commented 9 months ago

I'm working on an integration between HomeKit and KNX at home. This all works really really well and your library is a joy to work with! 🎉

I have my bridge deployed to a local k3s cluster and I'd like to make it possible to move the bridge between machines. In theory that should be possible, as you mention in the readme (https://github.com/brutella/hap#multiple-accessories). Ideally, if the state is accessible and the accessory IDs don't change I should be good.

However, as soon as I manually set an ID – even if the bridge only has a single accessory, the pairing apparently doesn't finish and the Home app lists the accessory as unresponsive. When I drop that single line setting the accessory ID, clear the local state (in ./fs) and re-add the bridge, everything works.

Do you have any idea what could be causing this? I've read about the disaster with the Home architecture change in iOS 16.2. I migrated to the new architecture a long time ago – but I also didn't have any Matter devices so it went smoothly without any issues. I've tried unplugging all of the home hubs (HomePods, an Apple TV) and only left the iPad Pro on but that didn't have any impact. I keep all the devices up to date (everything on 17.2 as of this writing).

Where should I be looking to debug this? Thank you again for this awesome project.

brutella commented 9 months ago

The server stores the data in a location on the filesystem. (Specified by the store argument in hap.NewServer(...))

Are copying the content of this folder also the new location?

brutella commented 9 months ago

Oh and btw, if you are interested in controlling KNX devices with HomeKit, you should checkout hkknx.

annismckenzie commented 8 months ago

Oh and btw, if you are interested in controlling KNX devices with HomeKit, you should checkout hkknx.

I know about that one and even tried it out. I just… couldn't get it to work and needed to get my hands dirty building it myself. 😅

The server stores the data in a location on the filesystem. (Specified by the store argument in hap.NewServer(...))

Are copying the content of this folder also the new location?

I should have phrased this differently. Me adding stable and known accessory IDs is only the preparation for when I want to move the installation. But this problem doesn't appear after the move to a different machine, it happens when I try to assign IDs and add the bridge for the first time (no state, any previous bridges removed from my HomeKit installation). Does that make sense?

brutella commented 8 months ago

Please check if the first accessory that you add to the server has the id 1 and not 0.

annismckenzie commented 8 months ago

Thanks for getting back to me. I was working from this scheme:

  1. Give the bridge a known ID using a const in Go as a starting point – the uint64 space is big so I went with 24576970462541 (basically a random number).
  2. To generate the accessory IDs I'd use the KNX group address x/y/z – that's fixed, won't change and it's unique – and this formula: 
    accessoryID := bridgeID + (x * 10.000) + (y * 100) + (z)

(other projects, especially in the Python Home Assistant space, do this differently with a checksum but I went with the easier option)

This will make sure to never generate an accessory ID duplicate, as long as each component is between 0 and 99 which isn't hard in my small KNX installation.

– 2 hours later –

Alrighty, I got it working now. Your hint gave me the clue to where I was going wrong. The accessory ID of the bridge must be 1, otherwise nothing works. Oh dear. My scheme with the KNX group addresses works great:

2024/01/05 12:41:36 Accessory 'Bathroom light 1' has ID: 'x'
2024/01/05 12:41:36 Accessory 'Bathroom light 2' has ID: 'y'
2024/01/05 12:41:36 Accessory 'Kitchen light' has ID: '10xxx'
…

After this is now all working, I tried to move the installation. I copied over the db folder to the second location, moved the pod over and everything's still working properly! 🎉 🎉 🎉 It initially didn't work because the .pairing file is written only when the server is restarted after adding it to HomeKit and so I had missed copying that file.

Should I document my findings in the README.md and send a PR?

Thank you for guiding me – I'm closing this issue.