macOS Monterey (12.1) - Scan not working & Not possible to connect via Device UUID

[dejanovicnnd-symphony]

I've installed this from source code by make clean && make install because there were some issues while using brew.

After installation I tried to scan but nothing happens (actions never end):

Also I've tried to connect with unique Device UUID, but nothing happens:

UPDATE:
Later I figured out that Im able to connect with Service UUID, but that's not really convenient in my case because I have two devices with different Device UUID, but same Service identifier. I think in any case (not just mine) it's expected to use Device unique identifier rather than Service identifier (which is not unique).

[dejanovicnnd-symphony]

Never mind, figured out it's the issue on my side. Feel free to delete issue.

[mickeyl]

Glad to know it's still working on Monterey. I have some unresolved issues with regards to newer, more strict, sandboxing rules, which prevents proper distribution using Homebew.

[dejanovicnnd-symphony]

My problem is that I've used device UUID to connect on device, but not service UUID as mentioned in readme. In my case it's not really convenient, because I have two devices with different UUID, but same service UUID.

Also I can confirm that scan is not working, Im just not getting any output. Bridge works, but only when using service UUID as I mentioned above.

Thanks!

[mickeyl]

I see. Would you mind reformulating this issue then? Please state how you would like to use it and we can try to make it work for you. Reopening this.

[dejanovicnnd-symphony]

Thanks, @mickeyl for your effort!

I've updated the title and my first comment regarding the scan & usability issue.

[mickeyl]

Ok, this is going to be complicated. We have several issues here and there's good, bad, and ugly things. First the good:

Version 0.2.1 is now available and I've repaired scan for a given service and vastly improved its output. Here's a sample:

 /V/S/D/l/core-bluetooth-tool>. sb -c release && .build/release/core-bluetooth-tool scan fff0                                                                                                                                                   Sa 29 Jan 11:15:13 2022
[2/2] Build complete!
BLE powered on, scanning for [FFF0]...
(P) DE572AFB-CD59-E19C-8248-EA08EDE25346	OBDII
(P) F890A301-A464-D37C-AAFB-9374B546F7FE	UniCarScan iOS
(S) F890A301-A464-D37C-AAFB-9374B546F7FE	UniCarScan iOS	1804	PRIMARY
(S) F890A301-A464-D37C-AAFB-9374B546F7FE	UniCarScan iOS	Battery	PRIMARY
(S) F890A301-A464-D37C-AAFB-9374B546F7FE	UniCarScan iOS	FFF0	PRIMARY
(C) F890A301-A464-D37C-AAFB-9374B546F7FE	UniCarScan iOS	1804.2A07	Read, Write w/o Response
(C) F890A301-A464-D37C-AAFB-9374B546F7FE	UniCarScan iOS	Battery.Battery Level	Read, Notify
(S) DE572AFB-CD59-E19C-8248-EA08EDE25346	OBDII	1804	PRIMARY
(S) DE572AFB-CD59-E19C-8248-EA08EDE25346	OBDII	Battery	PRIMARY
(S) DE572AFB-CD59-E19C-8248-EA08EDE25346	OBDII	FFF0	PRIMARY
(C) DE572AFB-CD59-E19C-8248-EA08EDE25346	OBDII	1804.2A07	Read, Write w/o Response
(C) F890A301-A464-D37C-AAFB-9374B546F7FE	UniCarScan iOS	FFF0.FFF1	Read, Notify
(C) F890A301-A464-D37C-AAFB-9374B546F7FE	UniCarScan iOS	FFF0.FFF2	Write w/o Response, Write
(C) DE572AFB-CD59-E19C-8248-EA08EDE25346	OBDII	Battery.Battery Level	Read, Notify
(D) F890A301-A464-D37C-AAFB-9374B546F7FE	UniCarScan iOS	FFF0.FFF1.Client Characteristic Configuration
(C) DE572AFB-CD59-E19C-8248-EA08EDE25346	OBDII	FFF0.FFF1	Read, Notify
(C) DE572AFB-CD59-E19C-8248-EA08EDE25346	OBDII	FFF0.FFF2	Write w/o Response, Write
(D) DE572AFB-CD59-E19C-8248-EA08EDE25346	OBDII	FFF0.FFF1.Client Characteristic Configuration

Now to the "bad". The bridge subcommand merely delegates its work to CornucopiaStreams, which is another library by yours truly. As selecting a concrete device is a very fair requirement, I've opened an issue over there to track the issue.

At last, the "ugly". Thanks to Apple continually diminishing the value of the command line (and unifying the OS with iOS), starting with macOS Monterey, command line programs using frameworks such as CoreBluetooth are now identifying as "running in the background". Therefore, the usual background rules (no wildcard scanning) apply. This is unfixable as its a limitation by the core framework.

Since scan now works again, I think we can close this issue here and continue over there with the next issue, right?

[mickeyl]

Cornucopia-Swift/CornucopiaStreams#3 has also been fixed, so I'm closing this here.

[mickeyl]

Spoke to soon… core-bluetooth-tool does not yet expose the capability to connect to a specific UUID. Reopening this.

[mickeyl]

This should now work w/ ref 12b8cfa. Please reopen if it doesn't for you.

[mickeyl]

FWIW, in macOS Monterey 12.3 Apple seem to have reverted this questionable choice! All rejoice!