Closed systemcrash closed 2 years ago
Yes, this was actually how I did it the first time around. I had a lot of trouble encoding/decoding between bytes and string. For example, utf-8 won't work for the public key, you need utf-16. For the identifier, you need to use utf-8. For the permissions bit, I just forced a string conversion and reassembled with an if/else 😂
Base64 encoding would've been the smarter choice, and I'd be happy to PR this in. I will also include an override for the mDNS name, so that it is announced as configured by HomeKit.
E.g.
OK, I took a stab at this, and I'll hopefully have a PR coming soon.
OK, what I have so far is viable. I've tested it with a number of different bit-flags. The extensive comments reveal that there are still a few bits missing. This motivates me to move the HK part to a different framework - like HAP-python. They've got some great code which means you can have multiple endpoints associated via HAP to control the speaker part. Currently, it's only one in this implementation.
Have a look at the differences here, or just go play with it, and see how it works for you.
OK - pushed to master. If you want to fix 2 and 3, I welcome some attention to those bits. I've configure
has nothing for more permanent storage.
@LewdNeko wonder whether we can update this. Have you tried master recently?
@LewdNeko Wonder if you want to take a shot at this. This way, you avoid removing/reinserting all of the strange characters which are not 'file safe' that might appear in IDs today and tomorrow.
I think the pairings should be all be in a single file. It can be whatever format internally, but a text format for simplicity is nice. I propose a single flat JSON file, with each key, ID and permissions base64 encoded.
The alternative is to use binary plists, which we already use in ap2-receiver.
This will at least fix the issue we saw in https://github.com/openairplay/airplay2-receiver/issues/38#issuecomment-881089762