Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
annismckenzie opened this issue Dec 17, 2023 · 5 comments
Closed

Comments

@annismckenzie
Copy link

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
Copy link
Owner

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
Copy link
Owner

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

@annismckenzie
Copy link
Author

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
Copy link
Owner

brutella commented Jan 4, 2024

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

@annismckenzie
Copy link
Author

annismckenzie commented Jan 5, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants