Hallo Leute,

ich habe eine Anwendung auf Basis des HearTrateMonitor Beispiels gebaut (mit einem anderen Messystem):
1. DiscoverDevices
2. DiscoverServices
3. GetCharacteristics
4. Start Monitoring

Funktioniert soweit ganz gut.

Allerdings bekomme ich es nicht hin wenn der Client abgeschaltet wird (PowerOff).
Das Abschalten bekomme ich noch mit, weil ich regelmäßig mit RSSIRead auf IsAlive prüfe.
Wenn nicht mehr da, dann setzt ich alles auf Anfang.

Habe mit TBluetoothManagerLE.ClearServices; versucht den Adapter rückzusetzen.

Aber egal was, wenn ich wieder ober 1,2,3,4 mache bekomme ich nicht die Funktionierende Verbinding hin.
Wenn ich die App neu Starte dann gehts.

Wie muss man den BT-Stack stoppen, abbauen, etc. damit man sich erneut verbinden kann ?

Hat irgendjemand ein ähnliches Problem ?

Rollo

DoScan; ?
BluetoothLE1.DiscoverDevices(2500, [HRService]) // It only exposes devices with the Heart Rate service to the BluetoothLE client.

http://docwiki.embarcadero.com/RADSt...vering_Devices
http://community.embarcadero.com/ind...rad-studio-xe7

Hallo hator,

danke für die Hilfe.
Ich denke ich habe das Problem gefunden:

Es war eine Abfrage auf EnableBluetooth

markieren

Code:

{$IFDEF ANDROID}
    if TBluetoothLEManager.Current.EnableBluetooth then
{$ENDIF nANDROID}
    begin
      BluetoothLE1.CancelDiscovery;
      BluetoothLE1.ClearServices;
{$IFDEF ANDROID}
    end
    else
    begin

Das "EnableBluetooth" wird anscheinend nur in Android wirklich ausgewertet,
unter allen anderen Platformen geben abgeleiteten Funktionen jeweils nur hardkodiert

markieren

Code:

Result := False;

zurück.

Dadurch wurde

markieren

Code:

     
      BluetoothLE1.CancelDiscovery;
      BluetoothLE1.ClearServices;

nie aufgerufen, und diese beiden Funtkionen setzen den Stack wohl zurück, so wie gewünscht.
Deshalb habe ich die Abrage nur für AMDROID gemacht.
Ich kann jetzt den BT verbinden, ausschalten, neu verbinden so oft ich will.

Rollo

Ich abe anscheinend immer noch Probleme mit BLE.
Nachdem ein Device gefunden wird MUSS ich durch alle Services und Characteristics durch, ansonsten
scheint die Methode direkt auf Characteristics zuzugreifen nicht zu funktionieren.

Hier muss nichts gemacht werden, andscheinen sucht fmx nur intern die Daten ab und generiert interne
Listen daraus.
Ich vermute das hier ein Bug beim Zugriff auf solche Listen ist, denn es funktioniert meistens, aber
ich bekommen auch regelmässig (nur beim Wiederverbinden), einen Zugriffsfehler den ich nicht näher lokalisieren kann.

Hat jemand ähnliche Probleme mit BT ?

Ach ja, unten in den Loops kann ich so auch die Daten ausgeben lassen (jetzt auskommentiert), aber wenn ich die
Kommentare wegnehme kracht es auch hier schon.
So als ob der Zugriff auf die internen Listen im TBluetoothLE ein Problem hätten.

Wie gesagt, nach Neustart ist alles super, nur wenn Device abgeschaltet und neu Verbunden wird scheint sich im
TBlueToothLE noch etwas zu befinden was nicht ganz korrekt ist.

Ich werde demnächst versuchen TBLuetothLE nicht als Komponente, sondern als Runtime Feld anzulegen, damit ich
das komplett entfernen kann, aber dazu muss ich einiges umbauen.

Rollo

markieren

Code:

//  // Loop through all SERVICES
  for I := 0 to FDeviceCurrent.Services.Count - 1 do
  begin
//    svc := FDeviceCurrent.Services[I];

//    Add(  'Service', svc.UUIDName);
//    Add(  '      ', svc.UUID.ToString);
//    if svc.ServiceType = TBluetoothServiceType.Primary then
//      Add('SvcType', 'Primary')
//    else
//      Add('SvcType', 'Secondary');

    // MUST LOOP through all, so that the desired information is gathered
    // otherwise the characteristics cannot be set reliably
    //
    //  // Loop through all CHARACTERISTICS
    for J := 0 to FDeviceCurrent.Services[I].Characteristics.Count - 1 do
    begin
//      svcC := FDeviceCurrent.Services[I].Characteristics[J];
//      Add(  '-Charact', svcC.UUIDName);
  //    Add(  '       ', svcC.UUID.ToString);

      FTimerTimeout := 0;

      //  // Loop through all CHARACTERISTICS DESCRIPTORS
      for K := 0 to FDeviceCurrent.Services[I].Characteristics[J].Descriptors.Count - 1 do
      begin
//        svcD := svcC.Descriptors[K];
//        Add('--Descr ', svcD.UUIDName);
//        Add('       ', svcD.UUID.ToString);

        FTimerTimeout := 0;
      end;
    end;

  end;

Ich habe noch eine Möglichkeit/Notwendigkeit gefunden:

BluetoothLE.Enable := False; // Beendet den ganzen internen Thread der Komponente
BluetoothLE.Enable := True; // Restartet wieder

Wenn man das nach verlorener Verbindung aufruft wird es etwas besser.
Es hat zumindest die ständigen Zugriffs-Exceptions beim Wiederverbinden erheblich reduziert, aber
die kommen leider immer noch sporadisch vor.

Beim ersten Verbinden funktionierts aber eigentlich immer, sonst passiert eigentlich nicht viel in der App,
deswegen denke ich das es mit dem internen Lesen der Characteristics zu tun hat, oder das beim internen Lesen
die BT-Verbindung abstürzt.


Rollo

offene Fragen über Fragen?

welche Android Version (4.3.x / 4.4.x / 5.x.x) ?

welches Delphi (XE7/XE7.1/XE8/XE8.1) ?

"wo"/"wann" werden die einzelnen BLE Funktionen aufgerufen?

Ganz allgemein:
- Im Wenn möglich nur "OnEnd(Discovery)Events" benutzen, und im OnDiscover(Devices) besser keine weiteren BLE Funktionen aufrufen, "kurzen" Timer starten und im TimerEvent erst weitere BLE Funktionen verwenden. Emba. kapselt die Java/IOS Api noch sehr "variabel" in eigene Threads und/oder nutzt Zwischenschichten. Wenn es nicht auf 0.1sec ankommt, lieber eine sequenzielle State-Maschine bauen und jeden StateWechsel zusätzlich über ein einzelnes 100ms TimerEvent entkoppeln.
- besser vor einem neuem Suchen ein CancelDiscovery zuviel wie eines zu wenig
- bis Android 4.4. ist alles sehr Hersteller und geräteabhängig... z.B. Sony Android4.4.x ist allgemein sehr stabil, Huawei Android 4.4.x sehr empfindlich
- ab Android 5.0.1 ist BLE besser, aber leider von Delphi (noch) nicht direkt per Onboard-FMX unterstützt...
- wenn für gefundene Geräte(also nach DiscoverDevices) der (Re)Connect, also "DiscoverServices" nicht klappt, dann kann man da etwas mit dem Timing spielen... einmal möglichst schnell danach und einmal mit ~300ms Pause dazwischen

...stell doch einfach mal (d)ein TestProjekt hier rein