Closed dejanovicnnd-symphony closed 2 years ago
Never mind, figured out it's the issue on my side. Feel free to delete issue.
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.
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!
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.
Thanks, @mickeyl for your effort!
I've updated the title and my first comment regarding the scan & usability issue.
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?
https://github.com/Cornucopia-Swift/CornucopiaStreams/issues/3 has also been fixed, so I'm closing this here.
Spoke to soon… core-bluetooth-tool
does not yet expose the capability to connect to a specific UUID. Reopening this.
This should now work w/ ref 12b8cfa06a7aa18d5010f4fe029b3720588de2ad. Please reopen if it doesn't for you.
FWIW, in macOS Monterey 12.3 Apple seem to have reverted this questionable choice! All rejoice!
I've installed this from source code by
make clean && make install
because there were some issues while usingbrew
.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).