fix: macOS support #61
Conversation
deviantintegral
force-pushed
the
fix-macos
branch
from
4ec8ea8 to
aa338eb
Compare
| # Enable RX channel notifications first - this triggers the device to send | ||
| # an SMP Security Request, which kicks off the BLE pairing process | ||
| logger.debug("Enabling RX channel notifications to trigger pairing") | ||
| await bleClient.start_notify(self.deviceRxChannelUUIDs[0], lambda h, d: None) |
There was a problem hiding this comment.
I'm wondering if the other UUIDs in this are for different devices, and if this has to actually trigger this on multiple UUIDs and gracefully ignore errors?
Actually, I think we can do that already by calling _enableRxChannelNotifyAndCallback().
There was a problem hiding this comment.
All of the omron devices I have seen have at least the first RX channel as a bluetooth characteristic.
Some of the newer device have a different root uuid like HEM7144t, but I did not include the support for this one in the main branch, as I have not yet found a clean way to include all required changes.
| if args.key is not None: | ||
| if len(args.key) != 16: | ||
| raise ValueError(f"Pairing key must be exactly 16 characters, got {len(args.key)}") | ||
| pairingKey = bytearray(args.key.encode('ascii')) |
There was a problem hiding this comment.
if the pairing key is directly derived from ascii characters, it will be impossible to specify some keys. Either because one cannot type the character in the terminal, or the values outside of ascii range. Would it be possible to enter the key in hexadecimal representation instead?
| logger.info(f"Attempt connecting to {bleAddr}.") | ||
| await bleClient.connect() | ||
| await asyncio.sleep(10) #time delay for user to accept os pairing dialog on win11 | ||
| await bleClient.pair(protection_level = 2) |
There was a problem hiding this comment.
I will have to confirm this, but I suspect that the pairing command here might be required on windows and linux.
Maybe we need to introduce an os dependent codepath here.
|
Really nice that you got it working for mac-os 👍, thanks a lot for the pull request. |
2 participants
My reader glitched out and somehow stopped incrementing time, and I had to reset it. While I was able to get it pairing years ago, either something changed in macOS or I forgot the exact incantations to make it work.
I grabbed the packet log pairing with the official app using Apple's bluetooth profile and pointed an AI at it which identified the difference in the pairing flow. Now:
I still need to check this is working correctly on Linux.