Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Cross-Platform-Entwicklung (https://www.delphipraxis.net/91-cross-platform-entwicklung/)
-   -   Delphi BluetoothLE: ein Device wird unter MacOS nicht gefunden (https://www.delphipraxis.net/207660-bluetoothle-ein-device-wird-unter-macos-nicht-gefunden.html)

philipp.hofmann 20. Apr 2021 15:43

BluetoothLE: ein Device wird unter MacOS nicht gefunden
 
Hi,

mit meiner App suche ich per
ble.DiscoverDevices(4000,TBluetoothUUIDsList)
nach BLE-Devices.

Dabei suche ich die beiden folgenden Services:
{00001818-0000-1000-8000-00805F9B34FB}
{00001826-0000-1000-8000-00805F9B34FB}

Ein ganz bestimmtes, neues Device wird unter Windows, Android und iOS anstandslos gefunden. Unter MacOS findet er dieses Device einfach nicht.
Wenn ich mit BlueSee alle BLE-Devices anschaue, dann taucht mein Device in der Liste auf. Andere Devices werden unter MacOS problemlos gefunden.
Ich habe es auch schon mit einem anderen Zeit-Setting ausprobiert.

Wenn ich aber ohne TBluetoothUUIDsList suchen gehe, taucht mein gewünschtes Device in der Liste auf, aber eben auch tausend andere, die ich gar nicht haben will.
Das bedeutet ich muss für MacOS meine Routine, wie ich die gewünschten Devices suchen gehe, komplett umbauen und mir den Namen der Devices geben lassen und auf der Basis entscheiden,
ob ich das Device nutzen möchte.

Was kann hier der Grund sein? Warum kann ich für MacOS genau für dieses eine Device (andere Devices von dem Hersteller, aber ältere Version funktionieren) nicht wie gehabt mit der TBluetoothUUIDsList als Filter suchen gehen?

Grüße, Philipp

Rollo62 20. Apr 2021 17:21

AW: BluetoothLE: ein Device wird unter MacOS nicht gefunden
 
Die UUID Filter hatten bei mir noch nie richtig sauber funktioniert.
Ich meine auch nicht unter iOS/Android, deshalb hatte ich die mal auf Wiedervorlage gelegt.
Es könnte auch sein das nur Macos Probleme macht, kann ich nicht mehr sagen, zuletzt mit XE8 oder so getestet.

Gibt es was das hier mit Rx1042 Testen könnte, z.B ein Beispiel von Embarcadero ?
Das ExploreLEDevices Demo, da könnte ich schnell mal ein Filter reinbauen.

Es gibt da glaube ich zwei Arten der Filterübergabe (Parameter), welche genau benutzt Du dafür ?
Vielleicht ein kleines Beispie wie der Aufruf bei Dir konkret aussehen soll.

philipp.hofmann 20. Apr 2021 18:29

AW: BluetoothLE: ein Device wird unter MacOS nicht gefunden
 
Das Problem ist, dass du ja nicht mit genau diesem Device (es geht um einen Wahoo KICKR V5) testen können wirst.
Alle anderen Rollentrainer funktionieren ja problemlos. Daher wird ein Test-Beispiel nicht so viel bringen.

Rollo62 20. Apr 2021 19:20

AW: BluetoothLE: ein Device wird unter MacOS nicht gefunden
 
Ich kann eine UUID von meinen Geräten hier angeben, das sollte doch egal sein.
Ich arbeite allerdings nicht mit GATT Profilen, sondern mit UUID-128 Bit.
Vielleicht habe ich noch ein GATT-Teil irgendwo rumliegen, da muss ich aber suchen.

philipp.hofmann 20. Apr 2021 19:50

AW: BluetoothLE: ein Device wird unter MacOS nicht gefunden
 
Liste der Anhänge anzeigen (Anzahl: 1)
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 20. Apr 2021 22:57

AW: BluetoothLE: ein Device wird unter MacOS nicht gefunden
 
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 21. Apr 2021 07:11

AW: BluetoothLE: ein Device wird unter MacOS nicht gefunden
 
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 21. Apr 2021 15:18

AW: BluetoothLE: ein Device wird unter MacOS nicht gefunden
 
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 21. Apr 2021 20:42

AW: BluetoothLE: ein Device wird unter MacOS nicht gefunden
 
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 22. Apr 2021 15:25

AW: BluetoothLE: ein Device wird unter MacOS nicht gefunden
 
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;


Alle Zeitangaben in WEZ +1. Es ist jetzt 08:55 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz