Ich habe hier div. BT-Teile, welche nach dem Pairing 2 serielle Ports erzeugen.
(Bspw. OBD-II Adapter für's Auto, ESP32, ...)
Auslesen, erkennen & Abfrage der "richtigen Ports" (In/Out) ist soweit nicht das Problem.

Störend / verwirrend ist, das die COMs für BT nach dem Pairing "immer" vorhanden sind.
D.h., es ist egal, ob das entsprechende BT-Gerät eingesteckt, aktiv oder "in Rechweite" ist oder eben nicht.

Falls nicht, geht das bei dem Versuch den Port zu öffnen immer in einen Timeout.
Das fange ich zwar ab / kann das prüfen, aber es dauert immer eine Weile .... ca. 5 Sek. je Port.

Es nervt auf etwas zu warten, was eh nicht da ist.
Gibt es vielleicht eine Möglichkeit zum Scannen / testen wie bei der WLAN-API, ob ein BT-Gerät überhaupt "ansprechbar" ist oder nicht ?
Oder kann man sich da noch irgendwo etwas aus der Registry pfriemeln ?

Prüfst du immer ALLE Ports?

Wenn du zu etwas Bestimmten dich verbinden willst, dann vorher einfach im BT nachsehen, ob es da ist.

Ja, ich prüfe zunächst alle verfügbaren COM's in der REG unter '\HARDWARE\DEVICEMAP\SERIALCOMM\'.
Je nach dem, was da sonst noch mittels USB verfügbar ist, sehe ich IMMER (oder nur) die "ge-Pairten" BT-COM's.
Hier aktuell COM 3/7 und 8/9 für die OBD-II BT-Adapter.


Hab schon in den BT-Demos rumhestöbert, aber nicht wirklich was brauchbares gefunden.
Ich weiss / hab ja 2 Geräte als Paired drin .... aber woher bekomme ich die Info, das es auch "Funk-Kontakt" gibt ?

Die Idee ist, vor evtl. Comport.Open nachzusehen, ob überhaupt was da ist.

Für WLAN hab ich da schon entsprechendes und suche für einen Connect vorhandene SSID's nach gewünschtem Namen, bzw. scanne da explizit noch mal sofern nicht(s) vorhanden.

... das gleiche hätte ich auch gerne für BT.

Auch ein realer Comport ist immer da, egal ob etwas am anderen Ende des Kabels hängt. (OK, dort gibt es beim Öffnen keinen Timeout, weil der Port ja da ist)

Hmmm....

Ob ein BT-Gerät einen Comport hat, findet man in den Profilen.

Welche gräte gerade da sind ... sollten bei der Suche nicht nur die Aktiven gefunden werden?
OK, ob das Gerät dann selber in sich den Port wirklich grade aktiv hat .... joar

Damit wir uns nicht miss-verstehen:
Was da real (von WinDoof aktuell [online] gemeldet wird, ist ja bekannt.
D.h., was z.Zt. an COM's verfügbar ist, kann man ja wie o.g. per Registry mit dem Key '\HARDWARE\DEVICEMAP\SERIALCOMM\' auslesen.
Und wie ich bereits sagte, ist die "Ansprache" und oder Nutzung der verfügbaren COM's auch nicht das Problem.

Hier geht es explizit und dezidiert darum, das einmal "ge-PAIR'te" COMS's per BLUETOOTH eben IMMER "DA" sind.
Bumms-Täterä egal, ob aktiv / vorhanden / in Rechweite des jeweiligen Rechners !

Meine Frage / das Problem / mein Ansinnen war & ist:
-> Wie ermittle ich, ob ein BT-Gerät wirklich "Funktechnisch" erreichbar und überhaupt ansprechbar ist ?

... weil: Wenn nicht, dann kann ich mir den Versuch, zugehörigen COM-Port zu öffnen ohnehin sparen.

Also nochmal:
Für WLAn hab ich das (fast perfekt) implementiert:
- Nach gewünschter SSID suchen ...
- Falls nicht vorhanden, explizit noch (mehrmals) scannen.,
- Connecten ...

... und eben das gleiche für den BlauZahn in grün.

Zwischenmeldung:
Ich hab mir mal von den JEDIs die Bluetooth-API gezockt und minimalistisch geschrumpft.
Funzt zumindestens anscheinend besser (?) & schneller (!) als System.Bluetooth.
Ich sehe, was:
- ge-pairt ist ... oder eben nicht mittels Scan
- die Stati
-> AUTHENTICATED (wenn Paired immer true, sonst nicht)
-> REMEBERED (dito ...)
-> CONNECTED (immer false, ausser ich öffne "auf gut Glück" erfolgeich einen Serial-Port)

Leider fehlt (NICHT NUR MIR ?) irgendwie die Möglichkeit zu erkennen, ob:
- sich ein BT-Gerät "in Reichweite" befindet.
- geschweige denn, das es sich "zu weit entfernt"
D.h., ein erkennbarer Status ala "ist ansprechbar"
oder mittels einer CallBack-Proc "OnArrive" / "OnLeave" wie es das für USB-Geräte gibt ?

Muss man das wirklich "old-fashioned" im Polling abfragen ?

Bin ich nur zu doof da was zu finden ?
Oder gibbet dat garnich ?