BluetoothLE: ein Device wird unter MacOS nicht gefunden

[philipp.hofmann]

Hi Rollo,

anbei das angepasste ExplorerDeviceLE-Beispiel, wo beim Discovery die Liste übergeben wird.
Aktuell gehe ich davon aus, dass ich im Wechsel mit und ohne Liste scannen muss und ohne Liste am Namen erkenne, dass das von mir gewünschte Device dabei ist.

Grüße, Philipp

[Delami]

Ich hab festgestellt, das weder die eine (TBluetoothUUIDsList) noch die andere Liste (TBluetoothLEScanFilterList) wirklich verlässlich funktioniert, wenn nach mehr als einer Service UUID gesucht wird (Win und MacOS).
Ich filtere im Anschluss an das scannen manuell:
was nicht über (BluetoothLE.DiscoveredDevices[i].ScannedAdvertiseData.ContainsServiceUUID(MeineLis te[K].UUID)) passt wird aus der Liste gelöscht.
-> BluetoothLE.DiscoveredDevices.Remove(BluetoothLE.D iscoveredDevices[i]);

[philipp.hofmann]

Das habe ich auch schon gemerkt. Ich suche daher immer nur nach genau einem Service und wenn ich mehrere Suche dann wechseln diese sequentiell ab.
Das mit dem Filtern ist ein guter Hinweis. Mal prüfen.

[philipp.hofmann]

Jetzt packe ich in meine Sequence an startDiscovery auch eine Suche ohne Filter und filtere in dem Fall die DiscoveredDevices, wie hier beschrieben. Danke für den Hinweis.
Mir ist nur vollkommen unklar, warum der Filter vorab nicht funktioniert, aber in der Discovered-Methode klappt. Aber was soll's. Wieder was gelernt.

[Rollo62]

Ich schau morgen mal rein.
Ich filtere auch nach Namen, während und nach dem Scan.
Während des Scans kann ich die ScanResponses auffüllen.
Trotzdem erhoffe ich mir vom Service Filter ein PerformancePlus.
Dazu wollte ich notfalls mal bei Ios und And in den Sources wühlen,
Nur fehlt die Zeit ...

[Rollo62]

Hallo Philipp,

sorry, es kommt immer was dazwischen, aber jetzt ...

Es funktioniert bei mir, ich habe nur die UUID geändert
TBluetoothUUID = '{0000FFB0-0000-1000-8000-00805F9B34FB}';
statt
TBluetoothUUID = '{00001818-0000-1000-8000-00805F9B34FB}';

Ich kann 1,2 Geräte finden und Listen, andere UUID's werden ignoriert.
Geschwindigkeit ist gleich (klar ich muss ja auch das 3500ms OnEndDiscoverDevices abwarten,
aber beim Scannen der Services könnte es dann schneller sein (weil schon vorgefiltert).
Trotzdem muss ich wohl auch beim Filter das Lesen der Services abwarten, bis ich verbinden kann.
Also Defakto wird das Vorfiltern wenig bringen, ausser etwas weniger Traffic beim EndDiscoverDevices.


Ich habe bei mir seit langem die Basis im Verdacht "00805F9B34FB", weil diese als Grenze zwischen den GATT und den Custom UUID's fungiert.
Oft werden diese Default-Daten von einfachen Geräten nicht "customisiert", und ich finde z.B. zig Geräte mit der gleichen Forerunner UUID im Büro.
Da machen sich viele Hersteller anscheinend nicht die Mühe ein unique ID zu Erzeugen, wohl auch um Registrierungskosten zu Vermeiden.

Die Vermutung ist dass ein GATT Service Profil, wie dein CPS, als 16-Bit "1818" bei BT SIG registriert ist, und dann als 128-Bit wie oben konvertiert und benutzt werden kann.
Technisch ist es dann halt immer die Gleiche UUID, aber so sicher bin ich da nicht.

Meine Geräte entsprechen dann eigentlich keinem vor-registriertem GATT-Serive-Profil,
also z.B. FFB0, s.o., das liegt einfach im oberen, freien Bereich.
Es scheint aber in der Regel trotzdem zu funktionieren, egal ob BT SIG registrierte UUID, oder nicht.
Ich würde da eigentlich Probleme bei meiner UUID erwarten, wenn der Filter nur die registrierten UUIDs akzeptieren würde, das habe ich aber noch nicht gesehen.

Technisch habe ich nie Probleme damit gehabt, die 128Bit UUID wird immer erkannt, egal ob vordefinierte GATT oder nicht.
Manche Geräte geben da einfach keine oder eine falsche GATT Nr. an, das könnte mal zu Konflikten führen.
Ich habe auch Geräte die dann eine freie, Custom-Basis haben, also der 128-String ist komplett custom GUUID, auch das funktioniert ganz normal und ich meine so wäre das eigentlich gedacht.

Dein CPS Filter Profil ist aber als 16-Bit BT SIG registiert.
Wenn der ScanFilter bei registriertem 16-Bit CPS anders arbeitet, als bei nicht-registrierten ...
Dann hätten die Geräte wohl einen Registrierungs-Filter in den Scan-Filter gebaut, deshalb vermute ich das mal nicht.
Dagegen spricht auch dass ich Geräte mit der Basis '{00000000-0000-1000-8000-00805F9B34FB}' habe,
die sollten dann auch nicht arbeiten.

Vielleicht findest Du ja etwas in dier Richtung ?

Bin noch am Testen wie zuverlässig das jetzt mit der Erkennung ist, aber im Moment scheint es schnell
und sicher zu reagieren.

Benutzt Du in deiner App die FBluetoothManagerLE.StartDiscovery(, oder über System.Bluetooth.Components.TBluetoothLE.DiscoverS ervice( ?
Das sollte sich zwar gleich verhalten, weil es den gleichen Manager benutzt.

Edit:
Das .Free funktioniert, weil tief im BLE das entweder direkt benutzt oder kopiert wird.
Vielleicht ist da aber je nach OS Version der Wurm drin ?

Delphi-Quellcode:

  bluetoothLEDeviceTypeHelpList:=TBluetoothUUIDsList.create();
  bluetoothLEDeviceTypeHelpList.add( TRAINER_SERVICE_WAHOO );
  FBluetoothManagerLE.StartDiscovery(2000, bluetoothLEDeviceTypeHelpList);
  bluetoothLEDeviceTypeHelpList.Free(); //<=========== .Free ===========


...

function TAndroidBluetoothLEAdapter.DoStartDiscovery(Timeout: Cardinal; const FilterUUIDList: TBluetoothUUIDsList;
  const ABluetoothLEScanFilterList: TBluetoothLEScanFilterList): Boolean;
var
  LServiceUuids: TJavaObjectArray<JUUID>;
  LBluetoothLEScanFilterList: TBluetoothLEScanFilterList;
  I: Integer;
begin
  FBluetoothLEScanFilterList := nil;
  LServiceUUIDs := BluetoothUUIDsListToJavaArrayUUID(FilterUUIDList);

  if TOSVersion.Check(5) then
  begin
    if (FilterUUIDList <> nil) and (FilterUUIDList.Count > 0) then
    begin
      LBluetoothLEScanFilterList := TBluetoothLEScanFilterList.Create;
      for I := 0 to FilterUUIDList.Count - 1 do
      begin
        LBluetoothLEScanFilterList.Add(TBluetoothLEScanFilter.Create);
        LBluetoothLEScanFilterList[I].ServiceUUID := FilterUUIDList[I];  //<=========== Kopie ===========
      end;
      Result := DoStartDiscoveryRaw(LBluetoothLEScanFilterList);
    end
    else
      Result := DoStartDiscoveryRaw(ABluetoothLEScanFilterList);
  end
  else
    if LServiceUUIDs <> nil then
      Result := FJAdapter.startLeScan(LServiceUUIDs, FLeCallback)  //<=========== Benutzt mit Kopie ? ===========
    else
    begin
      FBluetoothLEScanFilterList := ABluetoothLEScanFilterList;
      Result := FJAdapter.startLeScan(FLeCallback);
    end;

...
...
...

end;

[philipp.hofmann]

Ich benutze FBluetoothManagerLE.StartDiscovery.

Zitat:

(klar ich muss ja auch das 3500ms OnEndDiscoverDevices abwarten

Sind dies nicht 1.500ms? Ich warte immer 2.000ms damit dies passt. Dies scheint auch stabil zu sein.
Wie gesagt, ich mache jetzt auf dem Mac immer ein

BluetoothManagerLE.StartDiscovery(4000,Erste-Filter-UUID);
BluetoothManagerLE.StartDiscovery(4000,Zweite-Filter-UUID);
...
BluetoothManagerLE.StartDiscovery(4000);

und für den Fall ohne Filter prüfe ich in
BluetoothLEDiscoverLEDevice(const Sender: TObject; const ADevice: TBluetoothLEDevice; Rssi: Integer; const ScanResponse: TScanResponse);
ob ADevice.ScannedAdvertiseData.ContainsServiceUUID(E rste-Filter-UUID)
or ADevice.ScannedAdvertiseData.ContainsServiceUUID(Z weite-Filter-UUID)
...
gilt und nur dann wird das Device eingebunden.

Damit werden alle meine Devices stabil gefunden, auch der Wahoo KICKR V5. Unter allen anderen OS geht es bisher ohne die Suche ohne Filter.
Es ist jetzt aber so eingebaut, dass ich dies jederzeit einfach auf andere OS erweitern kann. Dies sind nur 3 {$IF defined(...)-Stellen im Code.