Bluetooth Low Energy Delphi 6

[v2afrank]

Hallo,
ich habe hier eine ältere Delphi 6 Anwendung die aber noch fleißig weiter entwickelt wird. Jetzt kommt eine neue Komponente hinzu die Bluetooth Low Energy voraussetzt. Da ich mit Bluetooth noch nie was zu tun gehabt habe fing ich an zu googlen und habe gesehen dass Delphi Berlin jetzt auch wohl Bluetooth Low Energy unterstützt. Ich möchte aber ungern die ganze Anwendung umstellen. Denkbar wäre es den Teil in eine Dll auszuladen, aber ich frage einfach mal nach. Gibt es auch eine Möglichkeit die Low Energy Funktionalitäten mit Delphi 6 zu benutzen ?
Ergänzung. Ich habe diese Komponenten gefunden http://www.btframework.com/ Kennt die jemand ? Scheinen genau meine Erwartung zu erfüllen.

[yogie]

die frage wäre, was da mit BT übetragen wird.
Wenn nur eine serielle Schnittstelle via BT emuliert wird,
merkt das Programm von der zwischengeschalteten BT-Schicht gar
nichts. Ich habe selber schon ein Programm, das bisher mit einer
drahtgebundenen seriellen Verbindung arbeitete auf BT umgestellt.

[v2afrank]

Genau im Prinzip soll die Verbindung eine serielle Schnittstelle ersetzen

[himitsu]

Im Prinzip hann man auch im "alten" Delphi direkt die entsprechenden APIs ansprechen,
aber viele "neuere" Bluetooth-Komponenten werden einfach nicht mehr die alten Delphis unterstützen und selber machen ist nicht ganz so einfach.

Eine DLL mit neuem Delphi erstellen wäre möglich, aber bitte dann nicht selber die Fehler machen, weswegen viele beim Überganz zu Unicode massig Probleme hatten.
Weil der Entwickler der DLL-Schnittstellen dynamische Typen verwendete, anstatt der Statischen. (PChar statt PAnsiChar/PWideChar usw.)

Und wenn das Gerät direkt einen Treiber verwendet, der einen Virtuellen COM-Port bereit stellt, dann hat dein Programm mit dem Bluetooth nichts zu tun.



Auch wenn ich einfach nicht verstehen will, wie man das SPP in BT-LE rein bekommen hat ... eine dauerhafte Verbindung in ein(e) Protokoll/Technik, die eigentlich nur für kurzzeitige Verbindungen ausgelegt ist. :gruebel:
(na gut, man kan zumindetens paar Byte übertragen und dann immer wieder trennen)

[yogie]

Mal im Geräte-Manager nachsehen ob dort ein COM-Port eigetragen ist.
Wenn ja, sollte auf dieser COM-Port-Nummer eine Übertragung möglich sein. Manchmal taucht ein BT-Adapter mit 2 COM-Port-Nummern auf.
Nach meiner Erfahrung, muß man die niedrigere Nummer verwenden.

[v2afrank]

Nein. Ihr habt mich falsch verstanden. Die Hardware gibt sich nicht als COM Port aus. Ich wollte damit nur ausdrücken, dass ich in einer 1:1 Verbindung ein paar Byte sende und empfange so wie ich es auch mit einem seriellen Kabel machen würde.
Ansonsten muss ich schon alle möglichen Bluetooth Empfänger auflisten und den User fragen womit er sich verbinden möchte. Dass ist mit der Komponentensammlung von btframework nicht von Haus aus möglich. Laut deren Support unterstützen die den "Dicover" Mode nur mit treibern von BlueSleil, da die Treiber von Microsoft limitiert sind ?

[Rollo62]

BlueSolei kenn ich jetzt nicht.
Aber bevore do 50Dollar für einen BLE Dongle ausgibst solltest du nochmal wonaders nachschauen.
Die BLE Chiphersteller Cypress, Nordic, TI, etc. bieten schon interessante Lösungen drumherum an.

Rollo

[v2afrank]

Ich möchte ja eigentlich keinen speziellen Dongle voraussetzen. Das Programm soll später im Prinzip mit jedem Laptop und am besten mit den eingebauten Bluetooth laufen. Wobei meine Recherchen ergeben haben dass LE erst ab Windows 8 unterstützt wird. Ist das so ? Kann das jemand bestätigen. Wenn der eingebaute Bluetooth kein LE unterstützt, dann muss der User eben einen anderen kaufen

[Rollo62]

Sowie ich verstehe ist Win8/81. nicht empfohlen, BLE läuft angeblich erst sauber ab Win10.
Da wäre ich etwas vorsichtig.

Rollo

[t.roller]

Zitat:

Zitat von Rollo62 (Beitrag 1339046)

...Aber bevor du 50Dollar für einen BLE Dongle ausgibst...

Rollo

BLE-Dongle 5,95 EUR
http://www.logilink.eu/media/datasheets/BT0015-de.pdf
Profil-Unterstützung BLE PXP(Proximity), FMP(Find Me), ScPP(Scan Parameters), HID (HID
over BLE)
Profil-Unterstützung A2DP, APT-X Stereo, AVRCP, BIP, BPP, DUN, FTP, GAP, GATT,
GAVDP, HCRP, HF, HS, HDP, HID, HOGP, OBEX, OPP, PAN, PBAP,
SPP, SYNCH, SYNC ML, VDP

[mensch72]

BLE als solches für einfachen 1:1 binär Datenstream als "BT-SPP" gibt es ja nicht... In BT4-BLE wird per das zu 99% per GATT-Profile mit Standard- und/oder Private-Services samt entsprechenden Standard und/oder Private-Charakteristics gemacht.

- Ab Delphi XE8.1 funktioniert der BLE Zugriff zumindest unter Android4.4.2+ & IOS8+ sowie +OSx10.9+ OutOfTheBox problemlos.
- Ab Win8.1 funktioniert auch die meiste in aktuellen Notebooks verbaute BT4/BLE Hardware, wenn man unter Windows das BLE-Gerät scannt und "verbindet"
- XE7..bis einschließlich DX10u1 Seattle implemetieren OutOfTheBox das "DiscoverDevices" unter Windows8+ schlicht garnicht, scannen also nicht und liefern nur die vorher schon systemweit fest verbundenen BLE/BT Geräte... für quasi fixe&bekannte 1:n Verbindungen ist das mit etwas Setup-Aufwand OK, aber für Anwendungen, wo man ständig neue/aktuelle BLE-Geräte in der Umgebung scannen und dann live automatisch connecten will, war&ist das so bisher unter Windows8+ mit Delphi unbrauchbar... nicht umsonst sind die DemoVideos für BLE von Emba immer auf einem MAC unter OSx bzw als MobileDevice/OS ;)
- DX10.1 Berlin soll da was verbessert haben, aber ich hatte noch keine Zeit es unter Windows zu probieren, ob der Scan("DiscoverDevices") nun unter Delphi in Windows funtioniert... Ein BLE Scan Demo liefert Emba ja mit :)

-> wenn es mit Delphi6 gehen soll, würde ich eine per USB angeschlossene Hardware als "BLE-Dongle" empfehlen, welche nur einen virtuellen ComPort samt ASCII-CMD-API zur Verfügung stellt.
=> http://www.buyrfid.co.uk/store/index...product_id=107

Zufällig ist es Teil meines Alltagsgeschäfts, BLE für beliebige 8Bit Microcontroler basierte Baugruppen&Geräte zu implementieren:)

MicroChip bietet da mit dem RN4020 Modul eine Lösung, welche simpel seriell angesprochen wird, und vergleichbar früheren "AT-Commands" konfiguriert wird und dann wenn es sein muss sogar zur transparanten 1:1 Datenübertragung(MLDP als "SPP-Emulation") genutzt werden könnte... ich habe mich aber für einen PrivateService entschieden und übertrage mit 2 private Charateristics blockweise je bis zu 20Bytes 1:1 bidrektional eventbasiert("mit Notification")... das reicht für unsere Anwendúng und ist 100% kompatibel mit Android, IOS und OSX, nur für Windows verwenden wir bisher der Einfachheit halber so einen simplen sereiellen USB-Stick, welcher das gleiche Modul drin hat. Das funktioniert mit jedem Delphi, bei uns real genutzt ab D2007.

Man beachte, das 97% der billigen oder festverbauten BT(4)/BLE (USB-)Dongles nur HCI können, und quasi alles vom BT/BLE-Stack/Treiber unter/für WindowsAPI realisiert ist.
Seriell frei programmierbare BLE-Hardware (GATT-Profile, private Services, private Charateristics, Notifications) als USB-Dongle gibt es nur ganz wenige!

[v2afrank]

Danke für Eure Antworten.
Also unsere Anwendung soll ausschließlich unter Windows mit verschiedenen Empfängern kommunizieren wobei immer mal wieder ein Scan gemacht wird und sich mit den entsprechenden Devices verbunden wird. Also ziemlich dynamisch.
Die Empfänger sind dann eben unsere Hardwarekomponenten. Wobei ich momentan sagen würde dass die Anforderung Windows 8 oder höher schon ein KO Kriterium ist. Aber das soll unser Vertrieb entscheiden.
Wo hier anscheinend doch einige Spezialisten sind. BLE kam aus folgendem Grund ins Spiel. Irgendwann soll eine IOS Anwendung geschrieben werden die es den Aplle devices erlaubt mit unserer Hardware zu kommunizieren. Um BT mit IOS zu ermöglichen muss angeblich ein extra Chip verbaut werden oder eben BLE verwendet werden. Diese Extrakosten würden wir uns gerne ersparen. Kann das jemand bestätigen ?

[Valle]

Zitat:

Zitat von v2afrank (Beitrag 1339153)

BLE kam aus folgendem Grund ins Spiel. Irgendwann soll eine IOS Anwendung geschrieben werden die es den Aplle devices erlaubt mit unserer Hardware zu kommunizieren. Um BT mit IOS zu ermöglichen muss angeblich ein extra Chip verbaut werden oder eben BLE verwendet werden. Diese Extrakosten würden wir uns gerne ersparen. Kann das jemand bestätigen ?

Wie meinst du das, "extra Chip"? Die iPhones haben selbstverständlich BLE und andere Bluethooth Standards eingebaut. Diese kannst du über die üblichen Entwicklungsmethoden für iOS-Apps ganz normal verwenden und damit Geräte verbinden.

Wenn ihr die Geräte selbst entwickeln wollt, dann müssen die natürlich einen Bluetooth Chip beinhalten. Da muss man sich dann schon zwischen BLE oder "herkömmlichem" Bluetooth entscheiden, da die beiden nicht miteinander kompatibel sind.

Ich bin ein wenig vertraut mit der BLE Produktreihe von Cypress und kann dir sehr empfehlen. Deren BLE Pioneer Kit ist zum Entwickeln und Lernen von BLE ziemlich praktisch. Ein BLE Dongle für Windows Rechner liegt übrigens bei. (Das ist keine Werbung, ich find die wirklich gut :D )

[v2afrank]

Klar müssen wir einen BT Chip einbauen. Ich bin mir jetzt gerade nur nicht sicher welchen die Hardwarker rausgesucht haben. Von denen kam auch die Aussage mit dem extra Chip. Ich habe mal kurz gegoogelt und es scheint das man den Apple Authentication co-processor einsetzen muss. Es sei den eben man nutzt den LE Moduse

[Valle]

Achso, okay. Soweit ich das verstanden habe, kannst du das SPP-Profil nur nutzen, wenn du diesen Co-Processor einbaust, was wohl einen enormen finanziellen Aufwand darstellen wird.

Mit SPP-Profil sparst du dir natürlich die BLE Bibliotheken für Delphi, denn da nutzt du ja einen Serialport.

Die Frage ist also eher, ob SPP denn das geeignete Profil für eure Anwendung ist. Das mit dem Co-Processor von Apple erscheint mir auch unpraktisch. :?

[himitsu]

BLE selber ist halt auf die 20 Byte pro Packet beschränkt. Alles was mehr braucht, müßte aufgeteilt und in mehreren Packeten übertragen werden.
BLE ist halt darauf ausgelegt "kleine" Datenmengen schnell und ohne großen Overhead zu übertragen.

Mir war so, als wenn SPP in iOS gesperrt war, abgesehn von ein paar "zertifizierten" Apps, oder so. (MFi Programm)
Aber das war noch zu Zeiten von iOS 6, wenn ich mich Recht erinner ... k.A. was mit iOS 7+ ist.
https://support.apple.com/de-de/HT204387
https://mfi.apple.com/MFiWeb/getFAQ.action

Zitat:

Zitat von Valle (Beitrag 1339158)

Die Frage ist also eher, ob SPP denn das geeignete Profil für eure Anwendung ist.

http://www.embedded-expertise.com/bl...ssic-or-smart/

Da ihr eh selber entwickeln wollt?
Wenn ich mal dazu komm, wollte ich mir die süßen Dinger von BlueGiga ansehn.
https://www.bluegiga.com/
Dort war auch nett, dass die den integrierten Microcontroller teilweise offen haben und man da direkt ein eigenes "Programm" darin laufen lassen kann.
Also wo man sich bei Kleinstgeräten einen zusätzlichen Microcontroller sparen könnte, der dann die eigentliche Funktion übernimmt. Die meisten BT-Platinen machen ja "nur" die Kommunication und müssten dann von irgendwem gesteuert werden.
Für sowas wie Sensor/Steuerausgang->Bluetooth->Sonstwas, würde dann eine Knopfzelle, deren Platine und der Sensor ausreichen, wenn einem wenige I/O-Pins und ein "kleines" Programm ausreicht.
Deren Controller ist eh nicht voll ausgelastet und den Platz stellen sie einem zur Verfügung.

[mensch72]

Wenn es um IOS und OSX geht, was mt "allem" kommunizieren soll, sollte man nicht (mehr) auf BT Classice/Standard setzen. BLE funktioniert ab IOS7 auf allen halbwegs aktuellen Apple Geräten nun völlig lizenzfrei.

Hier mal kurz meine Erfahrung für die "Hardwareseite", also die BLE Integration in eigene Geräte für kleine bis mittlere Stückzahlen:
- wir hatten APP Ingenieure von Cypress und Nordic im Haus. Das PsoC-Konzept von Cypress müsste man mögen, wir hätten uns für den ARM basierten CombiCip von Nordic entschieden, ABER...
- alleine schon wegen der kompletten (Funk)Zulassung wurden von uns dann doch "BLE Chips", wo wir Antenne samt Anpassung selbst auf der Platine machen müssten, ausgeschlossen
- bei den Modulen, ging der Ärger dann weiter, da wir im eigenen Prozessor nix vom BLE Stack haben wollten, um BLE so auch mit existierenden kleinen 8Bit Controlern noch einsetzen zu können und auch Zulassungstechnisch in keinerlei Abhängigkeiten zwischen BLE-STACK und unseren Code zu bekommen, bzw. bei Updates beachten zu müssen
- stromsparend, voll freikonfigurierbare GATT-Services und Charateristics und optimale BLE Kompatibilität von Android4.4+, IOS7+, OSX10.10+, Win81+... das waren und sind unsere Anforderungen, weil wir im Hotelbereich Türen damit öffnen und quasi in Kontakt mit allen möglichen Gäste-Smartphones kommen können...
- wir haben uns aus wenige Auswahl dann für ein von MicroChip hergestelles und supportetes BLE-Modul entschieden, was man minimal mit 3 Leitungen (RX,TX,Wakeup) auch mit Batteriegeräten oder sogar StandAlone verwenden kann... http://www.microchip.com/wwwproducts/en/RN4020

Unsere Technik und unser Einkauf ist bei Preisen um 5Eur/USD und sofortiger Verfügbarkeit "überall" und "immer" (Microchip,Future,Mouser,Farnell,...) auch soweit zufrieden. Wir haben nun schon ein paar tausend dieser Module verbaut und ausgeliefert. Schön war das auch das BLE-Firmwareupdate "OverTheAir" was diese Module Standalone integriert haben funktioniert hat, ohne das wir selbst da ausser dem Aktivieren des OTA-Mode etwas in den Geräten programmieren mussten.

Auf APP oder PC Seite verwenden wir ein eigenes gesichertes eventbasiertes Blockprotokoll mit 17Byte PayLoad und kommen so mit den 20Bytes per BLE-Transfer gut aus. Da wir nur mit unseren eigenen Apps bzw. mit von uns vertriebenen SDK's kommunizieren, wollten wir binären Datentransfer und legten so absichtilich keinen Wert auf Kompatibilität zu bekannten BLE-StandardServices(Geschwindigkeit, Blutdruck,Puls,Batterie oder änliches)

Wir kommunizieren sowohl mit Swift(XCode),Java(AndroidStudio) als auch Delphi(XE8u1+) mit den verschiedensten BLE Geräten und konnten bis auf die leider nicht ganz 100% normgerechte Sendeleistung der RN4020 Module, welche so keine zuverlässige Entfernungsberechnung aus dem RSSI zulassen, keine Nachteile der "geschlossenen" Modulsoftware feststellen. Kompatibilität und Funktionssicherheit im realem Einsatz sind gut, und im Verhältinis zum quasi nicht vorhandenem Entwicklungsaufwand zur BLE-Hardware-Integration überragend.


Mit der Kombi aus Nordic+ARM mit separatem eigenständigem BLE-Core könnte man sicher noch ein paar Dinge optimieren, aber leider hat sich das für uns kaufmännisch nicht gerechnet, obwohl ich fachlich gerne mit dem aktuellem Wissen einiges optimieren und probieren würde... bei uns war&ist das RN4020 also "nur" eine gute Vernuftentscheidung, die zufällig sogar sehr gut funktioniert:)

[Rollo62]

@Mensch72:

Zitat:

völlig lizenzfrei

Ich glaube wenn man HomeKit nutzen will ist auch BLE nicht lizenzfrei, aber ansonsten hast du Recht.
Wenn eben geht BLE einsetzen.

Aber Classic BT selber bauen (evtl. wenn man Video/Audio braucht), da schlägt dann auch Apple noch voll zu.

Ich denke eine eigene Funklösung zu bauen macht nur Sinn wenn es um Stückzahlen >=200K geht, mal grob geschätzt.
Macht auch keinen Sinn wenn man superkleine Module an allen Ecken kaufen kann, und Cypress-Module bei 3USD losgehen.
Angeblich gibt es auch schon vorzertifizierte BLE Module in China, weit darunter.

Dafür spart man sich eine Menge Ärger, und kann einfach das nehmen was man braucht und funktioniert.
BT ist sowieso komplett durchgeregelt und überreguliert, da spielt ja eigentlich eine eigene Anpassung keine Rolle mehr.
Wenn über SPI/RS232 angebunden sehe ich das ähnlich wie bei einem ein FTDI-USB Chip.

Vielleicht gibt es hier im Forum ja noch andere Erfahrungen, aber den Fehler Funk selber zu machen hatten wir
nur einmal mit ISM vor Jahren gemacht.
Die Kosten für alle Prüfungen und Zertifizierungen in allen Ländern sind leider extrem.

Auch hat BT-SIG seit geraumen Zeit seine Praktiken verschärft, ganz so als wollten sie keine kleineren Projekte
an BLE teilhaben lassen, mit 1-2K pro Jahr, dann wird auch immer eine teure BLE Logo-Zertifizierung fällig.
Das war vor ein paar Jahren noch nicht nötig.
Für mich sind das Alles Abzockvereine, so wie das Maut-Konsortium :shock:

Rollo

[v2afrank]

Ggf. mach ich einen neuen Thread auf aber erst mal so, da es meiner Meinung nach hier hin gehört
Ich habe jetzt einen Bluetooth Stick von Hama und habe mir die Testversion von Delphi Berlin runtergeladen. Unter Windows funktioniert der Stick einwandfrei. Nehme ich allerdings das BLEScanner Demo von Delphi bekomme ich nur die Meldung Bluetooth Gerät nicht gefunden , nicht verbunden oder ausgeschaltet. Weiß jemand was ich falsch mache ?

[mensch72]

Zitat:

Zitat von v2afrank (Beitrag 1339439)

Unter Windows funktioniert der Stick einwandfrei. Nehme ich allerdings das BLEScanner Demo von Delphi bekomme ich nur die Meldung Bluetooth Gerät nicht gefunden , nicht verbunden oder ausgeschaltet. Weiß jemand was ich falsch mache ?

Du machst unter Delphi FMX nichts falsch.. die Implementation vom FMX-BLE Adapter unter Windows hat leider auch unter "DX-Berlin" immer noch den Fehler, das "DiscoverDevices" egal was man für einen TimeOut angibt stets sofort zurückkommt OHNE ZU SCANNEN!?

-> derzeit unter WindowsFMX einzige mir bekannte OutOfTheBox Möglichkeit: man "verbinde" sich im WindowsBLE Manager mit dem BLE Gerät... dann wird es auch im Delphi-BLEscanner (ohne Scan sofort)"gefunden"

[v2afrank]

Okay. Danke für die Antwort.
Wobei das natürlich etwas ist was wir genau nicht wollen. In meinem Programm soll die Auswahl erscheinen und der User das Device anzeige.
Aber wenn es nicht geht, dann eben nicht.

[mensch72]

dann schreibe "als potentieller DX Berlin Käufer" doch mal an Matthias Eißing (http://www.delphipraxis.net/members/10585-meissing.html)...

Eventuell gibt es ja bei Emba schon ein internes Update oder einen Wrapper für einen MS-API-Call, wo das Scannen per DiscoverDevices dann aus einem Delphi-FMX-Windows-Programm wir erwartet funktioniert ?

Ich habe selbst auch noch keinen QC Eintrag dazu eröffnet, weil ich das einfach unter Windows mit einem speziellen USB-BLE-Stick mit direkter serieller API ganz ohne Windows-Treiber löse. (Das funktioniert ab XP und würde auch mit Delphi7 gehen:))

[MEissing]

StatDiscovery kann unter Windows nicht funktionieren. Siehe hier:
http://docwiki.embarcadero.com/Libra...StartDiscovery

(Unter Windows *müssen* Bluetooth(LE) mit dem Gerätemanager/Systemsteuerung *vorher* gekoppelt sein..... Fragt Microsoft, warum sie den Standard so lausig (BluetoothLE!!!) implementiert haben)
(Das Pairing kann man wiederum selbst anstossen)

[mensch72]

@MEissing

Native MS UniApps sollen den BLE Scan direkt oder im Hintergrund ja nun können...

https://github.com/Microsoft/Windows...hAdvertisement

Das BLE-API mit der "Scan-Funktion" (bzw. Benachrichtigung von einem SystemService) exisitiert unter "aktuellem" Win10 definitv...
-> wäre eben nur die Frage an Emba ob und wie das per Delphi FMX auch möglich ist ???

[MEissing]

Ohne Pairing wird das nix, wenn man die Characteristics lesen/enumerieren will.

Advertisement data ist nur die halbe Miete

Siehe zB hier:
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

10.1 Berlin nutzt die WinRT Funktionalitäten:
http://docwiki.embarcadero.com/RADSt..._in_Windows_10

[Ravenpool]

Hallo Delphi Praxis Community,

Ich habe das Forum durchsucht und nur diesen passenden Thread gefunden.
Ich hoffe es ist in Ordnung, dass ich es hier reinstelle.

Ich versuche in RAD Studio 10.2 ein Pulsoximeter auszulesen.
Mit DiscoverDevices kann ich auch das Gerät finden und mir in einer Liste anzeigen lassen.


Der Befehl DiscoverServices führt immer zur Fehlermeldung: 'Device not paired'.

Unter Windows 10 kann ich das Pulsoximeter auf keinem PC pairen. Ich habe es auf vier Computern sowohl über Dongle als auch eingebautem Bluetooth getestet. Ich habe das pairen und DiscoverServices mit einem Pulsgurt getestet, das lief problemlos.

Auch Versuche mit GetServices oder GetService haben bisher keinen Erfolg gebracht, das Ergebnis ist immer nil.
Ich hatte es schon fast aufgegeben mit all den Hinweisen bezüglich Delphi kann nur bei verbundenem Gerät die Daten auslesen, als ich den Bluetooth LE Explorer von Windows gefunden hatte.

Das pairen schlägt dort zwar auch fehl, aber bei direktem Klick auf das Gerät sind alle Daten auslesbar und auch abonierbar. Generell scheint es also unter Windows 10 ohne pairen zu gehen.

Den Sourcecode zum BLE Explorer habe ich hier gefunden: https://blogs.msdn.microsoft.com/btb...en-source-now/

Leider hat mir das auch nicht viel weitergeholfen. Ich hoffe, dass jemand von euch vielleicht eine Idee hat, wie ich das Ding vielleicht doch noch zum Laufen bekomme.
Vielen Dank schon mal.

Lucas


Ich hänge hier nochmal den kompletten Code an:

Delphi-Quellcode:

unit Bluetooth_MD300CI;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants,
  System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, System.Bluetooth,
  System.Generics.Collections,
  System.Bluetooth.Components, Vcl.StdCtrls;

type
  TLucas = record
    Geraetenummer: Integer;

  end;

  Tmainfrm = class(TForm)
    Scan_Button: TButton;
    Beenden_Btn: TButton;
    BluetoothLE1: TBluetoothLE;
    ListBox1: TListBox;
    Subscribe_Btn: TButton;
    Label1: TLabel;
    procedure Scan_ButtonClick(Sender: TObject);
    procedure Beenden_BtnClick(Sender: TObject);
    procedure Subscribe_BtnClick(Sender: TObject);
    procedure BluetoothLE1EndDiscoverServices(const Sender: TObject;
      const AServiceList: TBluetoothGattServiceList);
    procedure BluetoothLE1CharacteristicRead(const Sender: TObject;
      const ACharacteristic: TBluetoothGattCharacteristic;
      AGattStatus: TBluetoothGattStatus);
    procedure BluetoothLE1DiscoverLEDevice(const Sender: TObject;
      const ADevice: TBluetoothLEDevice; Rssi: Integer;
      const ScanResponse: TScanResponse);
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
    { Private declarations }
    Device_List: TList<System.Bluetooth.TBluetoothLEDevice>;
    FBLEDevice: TBluetoothLEDevice;

    SPOService: TBluetoothGattService;
    Read_Charact: TBluetoothGattCharacteristic;
    ServiceList: TBluetoothGattServiceList;

  public

    const

    ServiceUUID = '';
    CharactUUID = '';

    CI218_SERVICE: TBluetoothUUID = '{00001822-0000-1000-8000-00805F9B34FB}';
    CI218_Characteristic
      : TBluetoothUUID = '{00002A60-0000-1000-8000-00805F9B34FB}';
  end;

var
  mainfrm: Tmainfrm;

implementation

{$R *.dfm}

procedure Tmainfrm.Beenden_BtnClick(Sender: TObject);
begin
  application.Terminate;
end;

procedure Tmainfrm.Subscribe_BtnClick(Sender: TObject);
Var
  SelectedText: String;
  Device_Identifier: String;
  Current_Device: TBluetoothLEDevice;
begin

  Scan_Button.Enabled := true;
  if (ListBox1.ItemIndex >= 0) then
  begin
    Current_Device := ListBox1.Items.Objects[ListBox1.ItemIndex]
      as TBluetoothLEDevice;

  if Current_Device.Connect then
  begin
    showMessage('connected');
  end
  else
  begin

  end;
    SPOService := nil;
    Read_Charact := nil;
    ServiceList := nil;
    BluetoothLE1.DiscoverServices(Current_Device);
      //SPOService := BluetoothLE1.GetService(Current_Device, CI218_SERVICE);
      //Read_Charact := BluetoothLE1.GetCharacteristic(SPOService,
      //  CI218_Characteristic);

      // ServiceList :=  BluetoothLE1.GetServices(Current_Device);
//      BluetoothLE1.SubscribeToCharacteristic(Current_Device, Read_Charact);

//      if SPOService <> nil then
//      begin
//        ShowMessage('Service found');
//        // FHRMeasurementGattCharact := BluetoothLE1.GetCharacteristic(FHRGattService, HRMEASUREMENT_CHARACTERISTIC);
//        // FBodySensorLocationGattCharact := BluetoothLE1.GetCharacteristic(FHRGattService, BODY_SENSOR_LOCATION_CHARACTERISTIC);
//      end
//      else
//      begin
//        ShowMessage('Service not found');
//
//      end;
    //end
    //else
      //ShowMessage('Could not connect device');
  end
  else
    ShowMessage('Please select a device from the List');
end;



procedure Tmainfrm.Scan_ButtonClick(Sender: TObject);

begin
  Scan_Button.Enabled := false;
  BluetoothLE1.DiscoverDevices(5000, [CI218_SERVICE]);

end;

procedure Tmainfrm.BluetoothLE1CharacteristicRead(const Sender: TObject;
  const ACharacteristic: TBluetoothGattCharacteristic;
  AGattStatus: TBluetoothGattStatus);
var
  LAmbient: Double;
  LTarget: Double;
  LAccel: Double;
  LHum: Integer;
  LHHum: Double;
begin
  // if ACharacteristic.UUIDName = 'UUID_IRT_DATA' then
  // begin
  // LAmbient := extractAmbientTemperature(ACharacteristic);
  // LTarget := extractTargetTemperature(ACharacteristic, LAmbient);
  // EdAmbient.Text := Format('%f °C',[LAmbient]);
  // EdTarget.Text := Format('%f °C',[LTarget]);
  // end
  // else if ACharacteristic.UUIDName = 'UUID_ACC_DATA' then
  // begin
  // LAccel := ACharacteristic.GetValueAsInt8(0) /64;
  // EdAccelX.Text := Format('%f',[LAccel]);
  // LAccel := ACharacteristic.GetValueAsInt8(1) /64;
  // end;
  //
  //
  //
end;

procedure Tmainfrm.BluetoothLE1DiscoverLEDevice(const Sender: TObject;
  const ADevice: TBluetoothLEDevice; Rssi: Integer;
  const ScanResponse: TScanResponse);
var
  Device: System.Bluetooth.TBluetoothLEDevice;
  I: Integer;
  DCount: Integer;
  NumberOfDevices: Integer;
  ListBoxText: String;
begin
  DCount := BluetoothLE1.DiscoveredDevices.Count;
  NumberOfDevices := ListBox1.Count;
  for I := 0 to DCount - 1 do
  begin
    Device := BluetoothLE1.DiscoveredDevices[I];


    // if (Device.DeviceName = 'MD300CI218') then
    begin
      if Not Device_List.Contains(Device) Then
      begin
        Device_List.Add(Device);
        //     Name := 'Unknown device';
        //        Name :=  Name + BluetoothLE1.DiscoveredDevices[I].Identifier;
        // ListBoxText := '- ' + Device.DeviceName + ' - ' + Device.Identifier;
        // ListBox1.Items.Add(ListBoxText);

        ListBox1.Items.AddObject(Device.DeviceName, Device);
      end;

      // if (List.IndexOf(Device_Count - 1) <> I) then
      // begin
      // List.Insert(Device_Count, I);
      // // device_array[NumberOfDevices] := I;
      // Name := ' - ' + Name + ' - ' + BluetoothLE1.DiscoveredDevices[I]
      // .Identifier;
      // ListBox1.Items.Add(IntToStr(NumberOfDevices + 1) + Name);
      // Device_Count := Device_Count + 1;
      // end;
      // end
      // else
      // begin
      // List.Insert(Device_Count, I);
      // Name := ' - ' + Name + ' - ' + BluetoothLE1.DiscoveredDevices[I]
      // .Identifier;
      // ListBox1.Items.Add(IntToStr(NumberOfDevices + 1) + Name);
      // Device_Count := Device_Count + 1;
      //
      // end;
    end;

  end;
end;

//
procedure Tmainfrm.BluetoothLE1EndDiscoverServices(const Sender: TObject;
  const AServiceList: TBluetoothGattServiceList);
var
  I, J: Integer;
begin
  // for I:= 0 to AServiceList.Count - 1 do
  // begin
  // if AServiceList[I].UUIDName = 'UUID_IRT_Serv' then   //Temperature service
  // begin
  // for J := 0 to AServiceList[I].Characteristics.Count - 1 do
  // begin
  // if AServiceList[I].Characteristics[J].UUIDName = 'UUID_IRT_CONF' then
  // begin
  // AServiceList[I].Characteristics[J].SetValueAsUInt8(1);
  // BluetoothLE1.WriteCharacteristic(FcurrentDevice, AServiceList[I].Characteristics[J])
  // end
  // else if AServiceList[I].Characteristics[J].UUIDName = 'UUID_IRT_DATA' then
  // BluetoothLE1.SubscribeToCharacteristic(FCurrentDevice, AServiceList[I].Characteristics[J])
  // end;
  // end
  // else if AServiceList[I].UUIDName = 'UUID_ACC_SERV' then //Accelerometer
  // begin
  // for J := 0 to AServiceList[I].Characteristics.Count - 1 do
  // begin
  // if AServiceList[I].Characteristics[J].UUIDName = 'UUID_ACC_CONF' then
  // begin
  // AServiceList[I].Characteristics[J].SetValueAsUInt8(1);
  // BluetoothLE1.WriteCharacteristic(FcurrentDevice, AServiceList[I].Characteristics[J])
  // end
  // else if AServiceList[I].Characteristics[J].UUIDName = 'UUID_ACC_DATA' then
  // BluetoothLE1.SubscribeToCharacteristic(FCurrentDevice, AServiceList[I].Characteristics[J])
  // end;
  // end
  //
  // end;
end;

procedure Tmainfrm.FormCreate(Sender: TObject);
begin
  Device_List := TList<System.Bluetooth.TBluetoothLEDevice>.Create;
end;

procedure Tmainfrm.FormDestroy(Sender: TObject);
begin
  Device_List.Free;
  BluetoothLE1.CancelDiscovery();
end;

end.

[TurboMagic]

Hallo,

achtung: es gibt für BT Low Energy (BLE) bisher kein standardisiertes serielles Profil, im Gegensatz zum SPP (Serial Port Profile) des "Classic Bluetooh".
Damit wird's mit einem COM Port eher nichts werden. Man müsste vermutlich was auf Basis von GATT entwickeln. Da habÄ ich aber keine Erfahrung (hätt' aber gerne welche).

Die erwähnte Bibliothek BTFramework habe ich in einer älteren Fassung in Delphi 2007 und 10.1 Berlin schon benutzt. Der Entwickler ist ein Russe und recht hilfsbereit. Ich bekomme auch alle paar Wochen eine E-Mail mit einer Zusammenfassung, was im neuesten Update gemacht wurde. Nur hab' ich die nur für Classic Bluetooth mit SPP und BT Gerätesuche sowie Koppelung benutzt (meine Anforderungen sind etwas spezieller, da unsere BT Hardware 2 SPP Ports bereitstellt, was auf GUI Ebene des Betriebssystems oft nicht wirklich behandelt wird (Windows ist da noch besser als Android) zund ich Zugriff auf beide Ports brauche, weil der eine ein Konfigurationsport für das gerät ist).

Ich müsste mein BTFramework mal wieder aktualisieren, alleine schon wegen der vioelen Bugfixes seit dem, allerdings hat er mal was an der Architektur umgestellt, was ich erst nachziehen müsste und dazu fehlt mir momnentan etwas die Zeit.

In wieweit die Delphi eigenen Bibliotheken bei BLE unter Windows was taugen weiß ich nicht. Für eine Test App für Android hab' ich die aber schon mal erfolgreich benutzt. Alölerdings muss ich wegen der spezifika unseres Gerätes auf eine nicht öffentliche Funktion des Android API zurückgreifen. Mir hat damals dann Allen Baur gezeigt, was ich in der RTL wo hinzufügen muss, um diese Funktionalität nutzen zu können und warum das unkritisch ist (ANdroid braucht's selber).

Zu deinem Delphi 6: versuch doch'Ä mal wirklich langsam auf eine neuere Version umzusteigen. Alleine die IDE kann einiges mehr wie Refactorings etc.
Du könntest als Zwischenschritt (man bekam bisher mit einem neueren Delphi eigentlich auch immer Lizenzen für die älteren Versionen > 7) ja auf 2007 gehen, die letzte Version vor der Unicode Umstellung. Da kann die IDE auch schon manches mehr (z.B. Rename Refactoring, Methode auslagern etc.)

Grüße

TurboMagic

[Schokohase]

@TurboMagic

Der TE benutzt Delphi 6, aber Ravenpool <> TE und Ravenpool verwendet wie angegeben Delphi 10.2