Ich versuche, BLE an meinem Linux zum Laufen zu bekommen - der Mist weigert sich hartnäckig. Welche BLE Dongles funktionieren zuverlässig mit Linux?
Ich habe mehrere billige USB Bluetooth 4-Dongles, die alle völlig problemlos unter Linux funktionieren. Eines ist konkret dieses hier: https://www.amazon.de/LogiLink-BT0015-bluetooth-Class1-Micro/dp/B0096Y2HFW/ , die anderen sehen identisch aus, es steht aber nichts von LogiLink drauf, ich bekam sie kostenlos irgendwo dazu. Kannst Du ausschliessen, dass es sich vielleicht eher um ein Software- als ein Hardwareproblem handelt (z.B. zu alte bluez-Version oder so)? Was ist das konkrete Problem?
Gast
#5227539
Bei mir läuft folgender CSL Dongle ohne Probleme: https://www.amazon.de/dp/B00C68IQ3C/ Du musst manuell eine neue Version von BlueZ installieren und den Experimental-Modus einschalten. Adafruit hat dazu eine Anleitung, die nicht nur für den RPi passt: https://learn.adafruit.com/install-bluez-on-the-raspberry-pi/overview
Ich hatte zuerst mit der Software getestet, die mit Linux Mint 17 kommt - damit funktionierte nur BT Classic. Ich habe dann nach dieser Anleitung: https://www.jaredwolff.com/blog/get-started-with-bluetooth-low-energy/ bluez-5.9 installiert - seither funktioniert auf dem Mint 17 BT überhaupt nicht mehr. Als nächstes habe ich auf eine andere Platte Mint 18.3 installiert und damit getestet, bin aber an der dortigen Bluetooth-Software mangels Beschreibung gescheitert.
Uhu U. schrieb: > Ich hatte zuerst mit der Software getestet, die mit Linux Mint 17 kommt > - damit funktionierte nur BT Classic. > > Ich habe dann nach dieser Anleitung: > https://www.jaredwolff.com/blog/get-started-with-bluetooth-low-energy/ > bluez-5.9 installiert - seither funktioniert auf dem Mint 17 BT > überhaupt nicht mehr. bluez-5.9 ist mittlerweile bereits über 4 Jahre alt, damit funktioniert einiges was BTLE betrifft noch gar nicht richtig oder war damals zumindest noch experimentell. Für BTLE macht es derzeit noch Sinn möglichst die allerneuesten bluez-Versionen zu benutzen; für "Web Bluetooth" beispielsweise (die BTLE-API für den Webbrowser) braucht man >= bluez-5.41, und unter v5.43 muss man bluez zusätzlich noch mit dem experimental-Flag starten. > Als nächstes habe ich auf eine andere Platte Mint 18.3 installiert und > damit getestet, bin aber an der dortigen Bluetooth-Software mangels > Beschreibung gescheitert. Klingt für mich jedenfalls tendenziell tatsächlich eher so, als ob da eher ein Software- als ein Hardware-Problem vorliegt.
Gast
#5227598
Ich benutze Linux Mint 18.2, BT Classic läuft weiterhin ohne Probleme. In dem Tutorial von Jared Wolff sehe ich das Einschalten des Experimental-Modus nicht, daran kann es schonmal liegen, daß es bei dir nicht läuft. Der Autor des Adafruit-Artikels geht den ganzen Prozess der Installation in einem mehrteiligen Videotutorial durch, ist auch verlinkt im Artikel. Teil 1 davon war, meine ich, nur BLE-Theorie, die anderen beiden Teile die Installation. Das Tutorial hatte ich mir vorher angesehen. Video-Tutorial: https://www.youtube.com/watch?v=5fQR2PHMDWE
Ich versuche, BLE unter Mint 17 wieder flott zu bekommen. Ich habe bluez-5.47 nach Vorschrift gebaut - das ging glatt. Dann kommt das Problem:
1 | |
2 | |
Gast
#5227895
Nach welcher Anleitung machst du das jetzt? Ist 'libdbus-1-dev' installiert?
WaddeHaddeDuDeDa schrieb: > Nach welcher Anleitung machst du das jetzt? Nach der vom Chinesen. > Ist 'libdbus-1-dev' installiert? Ja.
Ich bin jetzt auf Mint 18.3 Mit der dort standardmäßig installierten bluez 5.37 bekomme ich BLE nicht zum Laufen. BT Classic funktioniert einwandfrei - wenn man vorher den funktionsuntüchtigen blueberry deinstalliert und dafür den blueman 2.0.4 installiert. Das verwendete BT 4.0 Dongle wird von lsusb so angezeigt:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
Ich habe dann bluez mit synaptic deinstalliert und anschließend die 5.47 nach der Anleitung von https://learn.adafruit.com/install-bluez-on-the-raspberry-pi/overview gebaut. Der Status des Bluetooth-Systems ist "dead":
1 | |
2 | |
3 | |
4 | |
Das nächste Kommando scheitert kläglich:
1 | |
2 | |
Das Problem läßt sich mit sudo systemctl unmask bluetooth.service beseitigen. Ein anschließendes systemctl status bluetooth zeigt, dass da noch irgendwo ein anderes Problem ist:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
BT Classic funktioniert, aber das BTLE-Gerät läßt sich nicht connecten: "Failed to add device". Nach einem Stop/Start von Bluetooth lautet die Fehlermeldung: "Device added successfully, but failed to connect". Auf dem dbus sind folgende zwei Services disabled:
1 | |
2 | |
Hat das vielleicht was damit zu tun?
Gast
#5227956
Mein Descriptor sieht genauso aus. Schau mal welche Version von 'bluetoothd' aktiv ist. Laut deinem Status läuft '/usr/lib/bluetooth/bluetoothd'. Es sollte aber '/usr/local/libexec/bluetooth/bluetoothd' sein nach manueller BlueZ-Installation. Siehe Adafruit-Tutorial, öffne mal den Service und editiere die Zeile mit 'ExecStart' und trage dort '/usr/local/libexec/bluetooth/bluetoothd' mit der '--experimental' Flag ein.
1 | |
Bei mir sehen die Versionen so aus.
1 | |
2 | |
3 | |
4 | |
Gast
#5227957
Ach ja, und die alte BlueZ-Version darf NICHT entfernt werden, sonst funktionieren einige BT-Werkzeuge nicht richtig bzw. gar nicht, das hatte ich am Anfang auch. Am besten nochmal die 5.47 entfernen. Die aktuellste Bluez Version in den Paket-Repos mit dem Paketmanager installieren. Dann nochmal die 5.47 manuell installieren und den neuen Daemon in den Service eintragen, Flag nicht vergessen.
Ich habe jetzt nochmal die 5.37 komplett deinstalliert und dann neu installiert, ebenso bluetooth und blueman. $ bluetooth -v gibt hier nur "bluetooth = on" aus - keine Versionsnummer. Hast du vielleicht $ bluetoothd -v gemeint? Dann die ganze Chose nach https://learn.adafruit.com/install-bluez-on-the-raspberry-pi/overview wiederholt. Und dann wieder dieselbe Scheiße: "Failed to add device". BT Classic funktioniert perfekt und die Handle-Warnungen nach systemctl status bluetooth sind weg. Hast du denselben Dongle-Typ?
Gast
#5228542
Uhu U. schrieb: > Hast du vielleicht $ bluetoothd -v gemeint? Sorry, ja sollte 'bluetoothd' heissen, der BT-Daemon. In dem Fall der, der durch den Package-Manager verwaltet wird:
1 | |
Uhu U. schrieb: > Hast du denselben Dongle-Typ? Mein CSL Dongle hat den gleichen CSR-Chip drauf wie deiner, der Descriptor ist exakt gleich. Startet dein System denn den BlueZ 5.47 Daemon? Geben die Log Files noch was her zum 'Failed to add device'?
Woraus schliesst Du eigentlich, dass BTLE nicht funktioniert, womit genau hast Du es getestet? Welche Fehlermeldung kommt z.B., wenn Du "sudo hcitool lescan" ausführst?
WaddeHaddeDuDeDa schrieb: > Startet dein System denn den BlueZ 5.47 Daemon? Geben die Log Files noch > was her zum 'Failed to add device'? Ja, der 5.47 Dämon läuft. Im Anhang ein Stück Log, bei dem ich versucht hatte, das BTLE-Gerät zu connecten.
Joachim S. schrieb: > Woraus schliesst Du eigentlich, dass BTLE nicht funktioniert, womit > genau hast Du es getestet? Ich habe hier eine BT Classic GPS-Maus und ein Blutdruckmessgetät mit BTLE. Zunächst teste ich, ob BT Classic funktioniert, indem ich die GPS-Maus per blueman connecte und mich mit GtkTerm auf /dev/frcomm0 hänge - das funktioniert problemlos. Der Versuch mit BTLE geht genau so: Gerät einschalten, versuchen mit blueman zu connecten - das schlug bisher immer fehl. Im Log im vorherigen Beitrag ist ein Versuch mit BTLE geloggt. Da ist offensichtlich irgend was schwer verbogen...
Gast
#5228769
'blueman' scheint ja einiger Probleme zu haben. Bei mir läuft der Standard Mint 18.2 BT-Manager 'blueberry'. Ich habe nie einen BT-Manager benutzt, um mit LE Geräten zu kommunizieren, höchstens mal zum scannen. Am Anfang habe ich 'bluetoothctl' eingesetzt und anschliessend auf die Bluez-Dbus-API mit Python aufgesetzt. Was zeigt denn folgendes bei dir an? Und was passiert, wenn du den Dongle entfernst und das Listing machst?
1 | |
2 | |
Falls dein Dongle auftaucht.
1 | |
2 | |
3 | |
4 | |
5 | |
Gibts zu blueberry irgend was an Beschreibung? Ich bin mit dem Mistding überhaupt nicht klar gekommen. Wie ist das mit den BT-Profilen? Die GPS-Maus hat das serielle Profil. Das Blutdruckmessgerät ist ein Gesundheitsgerät und hat das entsprechende Profil - kann das eine Ursache sein?
Uhu U. schrieb: > Gibts zu blueberry irgend was an Beschreibung? Ich bin mit dem Mistding > überhaupt nicht klar gekommen. > > Wie ist das mit den BT-Profilen? Die GPS-Maus hat das serielle Profil. > Das Blutdruckmessgerät ist ein Gesundheitsgerät und hat das > entsprechende Profil - kann das eine Ursache sein? Bei BTLE gibt es die Profile, die es beim klassischen Bluetooth gibt, gar nicht. Da gibt es etwas vereinfacht gesagt eigentlich nur "Services", und diese nochmal unterteilt in "Characteristics". Die "Services" sind das, was den klassischen BT-Profilen am nächsten kommt. Für Blutdruckmessgeräte z.B. gibt es zwar einen standardisierten Service, mit der ID 0x1810: https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.blood_pressure.xml ...aber das bedeutet leider nicht, dass ein Blutdruckmessgerät mit BTLE auch tatsächlich diesen standardisierten Service benutzt. Ich z.B. habe ebenfalls ein Blutdruckmessgerät mit BTLE "Medisana BU 550 Connect", aber das benutzt (wie meiner Erfahrung nach leider die meisten BTLE-Devices, zumindest war es noch vor einiger Zeit so) leider eben keinen standardisierten Service, sondern irgendein vom Hersteller selbst definiertes Protokoll. Weshalb das Gerät im Grunde auch nur mit der herstellereigenen App funktioniert... :-( Probier doch wirklich mal ein "sudo hcitool lescan" aus, in einem Moment, in dem das BTLE Deines Blutdruckmessgerätes definitiv gerade aktiviert sein müsste.
Gast
#5228923
Was sagen denn 'hcitool' und/oder 'bluetoothctl'?
Joachim S. schrieb: > Probier doch wirklich mal ein "sudo hcitool lescan" aus, in einem > Moment, in dem das BTLE Deines Blutdruckmessgerätes definitiv gerade > aktiviert sein müsste. Ich habe auch das BU 550 Connect... sudo hcitool lescan:
1 | |
2 | |
3 | |
4 | |
5 | |
Blueman zeigt das Dingens auch an, nur das Connect geht nicht. Dass man das Gerät nur mit der herstellereigenen App funktioniert, glaube ich nicht. Letzlich ist es ja nur ein Bytestrom, der da übertragen wird und wenn man die App zu Hilfe nimmt, muss sich das entschlüsseln lassen. Diese verfluchte App ist übrigens so konstruiert, dass man an die sqlite-Datenbank, die sie schreibt nicht heran kommt. Außerdem wird die DB nicht in die Sicherung von Android einbezogen - man hat also nur eine Chance, die Daten zu sichern, indem man sie auf den Medisana-Server schickt. Aber genau das will ich nicht. Es ist schon eine ziemliche Frechheit, was die Kerle einem da zumuten...
WaddeHaddeDuDeDa schrieb: > Was sagen denn 'hcitool' hcitool scan sagt garnix. Das Gerät wird nicht erkannt - ganz im Gegensatz zur GPS-Maus. > und/oder 'bluetoothctl'? $ bluetoothctl [NEW] Controller 00:1A:7D:DA:71:0F lx18 [default] [NEW] Device 00:0D:B5:39:53:40 BT-GPS-395340 [NEW] Device F4:B8:5E:95:25:63 LS BPM ... [CHG] Device F4:B8:5E:95:25:63 RSSI: -62 [CHG] Device F4:B8:5E:95:25:63 AdvertisingFlags: 05 . [CHG] Device F4:B8:5E:95:25:63 RSSI: -51 [CHG] Device F4:B8:5E:95:25:63 RSSI: -62 [CHG] Device F4:B8:5E:95:25:63 RSSI: -51 [CHG] Device F4:B8:5E:95:25:63 RSSI: -62 [CHG] Device F4:B8:5E:95:25:63 RSSI: -51 [CHG] Device F4:B8:5E:95:25:63 RSSI: -59 [CHG] Device F4:B8:5E:95:25:63 RSSI: -67 [CHG] Device F4:B8:5E:95:25:63 RSSI: -56 [CHG] Device F4:B8:5E:95:25:63 RSSI: -67 [CHG] Device F4:B8:5E:95:25:63 RSSI: -57 [CHG] Device F4:B8:5E:95:25:63 RSSI: -67 [CHG] Device F4:B8:5E:95:25:63 RSSI: -57 [CHG] Device F4:B8:5E:95:25:63 RSSI: -66 [CHG] Device F4:B8:5E:95:25:63 RSSI: -57 [CHG] Device F4:B8:5E:95:25:63 RSSI: -65 [CHG] Device F4:B8:5E:95:25:63 RSSI: -57 [CHG] Device F4:B8:5E:95:25:63 RSSI: -66 [CHG] Device F4:B8:5E:95:25:63 RSSI: -57 [CHG] Device F4:B8:5E:95:25:63 RSSI: -66 [CHG] Device F4:B8:5E:95:25:63 RSSI: -57 [CHG] Device F4:B8:5E:95:25:63 RSSI: -66
Gast
#5228987
Moderne Smartphones haben ja auch BLE und dafür gibt es Scanner Apps, vielleicht hilft das ja erstmal zu sehen wann und wie so ein Device sich meldet. Und von Nordic gibt es eine Scanner Software die in einen nrf51822 geladen wird und der meldet dann die empfangenen Daten seriell an den PC. Über ein PlugIn landen diese dann auch im Wireshark, zumindest gibt es das unter Windows. Den ersten Schritt mit dem nrf51 hatte ich mal hinbekommen, das PlugIn wollte dann aber nicht weil mein Wireshark zu neu war.
Gast
#5228989
Uhu U. schrieb: > hcitool scan sagt garnix BLE ist ja auch nicht HCI kompatibel, mein HCI Bluetooth Adapter in Windows erkennt auch keine BLE 4.0 Geräte.
Android hat einen Trace-Mechanismus für BT auf Systemebene - muss ich mal ausprobieren. Aber das Mistding muss doch irgendwie von Linux aus ansprechbar sein...
Gast
#5228993
ok, 'hcitool' unter Linux soll auch BLE können, ziehe meinen Einwand zurück, da ist nur der Name verwirrend (wie das ganze Bluetooth mittlerweile).
Gast
#5229004
Du kannst mit 'bluetoothctl' auf Services, Characteristics, Descriptors zugreifen, read/write. BLE scheint doch zu funktionieren. Blueman, Blueberry, etc kennen halt die GATT-Profile nicht. Musst du per Hand ran.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
Das Tool 'bluetoothctl' ist zwar nicht grad anwenderfreundlich aber es reicht zum rumprobieren. Schau dir das Adafruit-Video an, dort wird das alles gezeigt, ausserdem hat Adafruit auch eine Lib für den Zugriff auf BLE mit verschiedenen Systemen, nennt sich 'Bluefruit LE'.
Uhu U. schrieb: > Ich habe auch das BU 550 Connect... Das ist schon mal gut. > sudo hcitool lescan: >
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Sehr gut, dann sollte Dein USB-Dongle sowie BTLE unter Linux schon mal funktionieren. > Blueman zeigt das Dingens auch an, nur das Connect geht nicht. Ich fürchte, das muss nix heissen. > Dass man das Gerät nur mit der herstellereigenen App funktioniert, > glaube ich nicht. Letzlich ist es ja nur ein Bytestrom, der da > übertragen wird und wenn man die App zu Hilfe nimmt, muss sich das > entschlüsseln lassen. Sorry, da habe ich mich nur missverständlich ausgedrückt: Mit "funktioniert nur mit der hersteller-App" habe ich gemeint, dass Programme/Apps, die zwar den offiziellen, standardisierten "Blood Pressure Service" 0x1810 unterstützen, mit dem Gerät trotzdem nichts anfangen können, weil das BU550 diesen Service leider nicht unterstützt, sondern der Hersteller quasi ein eigenes "Protokoll" benutzt - und daher nur solche Software genutzt werden kann, die dieses spezielle Protokoll dieses Gerätes unterstützt. Das tut natürlich die Hersteller-eigene App, ob es sonst noch Apps/Programme gibt, die das tun (weil sie das BU550-Protokoll reverse engineered haben), weiss ich nicht. Grundsätzlich kannst Du aber natürlich das BU550 auch unter Linux nutzen, da hast Du völlig recht. Ich bin mir gerade nicht sicher, aber evtl. habe ich sogar selbst das Protokoll der BU550 schon mal zumindest teilweise selbst reverse engineered. Könnte ich morgen mal nachschauen. Wenn Du das Protokoll selbst reverse engineeren willst: Ich habe neulich eine Art minimalistischen "BTLE Sniffer Proxy" geschrieben, das sehr dabei helfen kann, undokumentierte, herstellereigene BTLE-"Protokolle" zu reverse engineeren. Das Programm verbindet sich mit einem beliebigen BTLE-Device, und fungiert dann als ein Proxy zu diesem Gerät und gibt sich als selbiges aus. Dann nimmt man die Hersteller-App, und verbindet sich dann in dieser statt mit dem echten BTLE-Gerät mit dem Proxy. Der loggt dann die gesamte Kommunikation zwischen der App und dem Gerät einfach mit, und schon kann man das Protokoll analyisieren. Dafür braucht man allerdings ZWEI USB-BTLE-Adapter... :-(
Wie man auf Android den BT-Verkehr loggen kann, ist hier beschrieben: https://stackoverflow.com/questions/23877761/sniffing-logging-your-own-android-bluetooth-traffic Sniffing/logging your own Android Bluetooth traffic
Uhu U. schrieb: > Wie man auf Android den BT-Verkehr loggen kann, ist hier beschrieben: > > https://stackoverflow.com/questions/23877761/sniffing-logging-your-own-android-bluetooth-traffic > Sniffing/logging your own Android Bluetooth traffic Cooles Feature - wenn das auch für BTLE funktioniert, wäre das in der Tat perfekt.
Gast
#5229062
Was sagt denn 'bluetoothctl', wenn du dich mit deinem BPM verbindest? Sooo kompliziert wird das Profil nicht sein, dass man nicht mit probieren an die Daten kommt. Einfach mal alle Characteristics lesen oder einfach mal alle Descriptoren (0x2902) mit ner 1 füttern und schauen was kommt, da sollte sich ein Notify anstossen lassen.
WaddeHaddeDuDeDa schrieb: > Was sagt denn 'bluetoothctl', wenn du dich mit deinem BPM verbindest? Ich hab mir grade das Video reingezogen. Morgen gehts weiter...
Asche auf mein Haupt: habe eben mal in meinen Aufzeichnungen nachgeschaut, was ich zur BU550 habe - und musste feststellen, dass mich meine Erinnerung da nur getäuscht hat, bzw. ich es mit einem anderen Gerät verwechselt hatte: Das BU550 benutzt offenbar doch kein proprietäres Protokoll, sondern den standardisierten "Blood Pressure" Service 0x1810. Gute Nachrichten also, das BU550 ist doch grundsätzlich mit jeder Software kompatibel, die diesen standardisierten BTLE-Service unterstützt. Oder falls sich da partout nix finden lässt, könntest Du gemäss dem hier dokumentierten Protokoll zur Not selbst was programmieren: https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.blood_pressure.xml
So, gestern stand ich noch am Abgrund, heute bin ich schon einen Schritt weiter... BLE ist was völlig Anderes, als BT Classic. Immerhin ist es mir jetzt gelungen, mit bluetooth den Firmware Revision String auszulesen. Nur an die eigentlichen Daten im Gerät bin ich noch nicht gekommen - siehe Anhang. Die Energiesparfunktion des Teils ist bei solchen Versuchen ausgeprochen lästig.
Gast
#5229437
> BLE ist was völlig Anderes, als BT Classic.
Ich weiss. Das hab ich hier im Forum schon mindestens dreimal erzaehlt.
:-)
Nur der Frequenzbereich und damit die Antennen sind gleich und die API
ist aehnlich. Ansonsten hat das nichts miteinander zutun.
Aber natuerlich hilft ein gleicher Name beim Verkauf. :-D
Olaf
Gast
#5229515
Z.B. kannst du folgend "Battery Service"-Notifications aktivieren
1 | |
2 | |
3 | |
4 | |
5 | |
Mit 'attribute-info' schau dir mal die anderen Service-Characteristics vom BPM an. Evtl lassen sich Notifications auch für "Service Changed" (char000d), "Blood Pressure Measurement" (char0011), "Intermediate Cuff Pressure" (char000d) aktivieren. Joachim hat es ja schon erwähnt, unter https://www.bluetooth.com/specifications/gatt/generic-attributes-overview findest du alle Infos, die du brauchst.
Ich habe nochmal versucht, bluez 5.47 auf Mint 17 zu installieren, nachdem ich die ursprüngliche bluez-Version neu installiert hatte. BT Classic läuft wieder, aber BLE bekomme ich nicht zum Laufen - selbe Fehlermeldung, wie hier: Beitrag "Re: USB-Bluetooth-LE--Dongle für Linux" Man muss wohl wirklich auf Mint 18 gehen, wenn man damit rumbasteln will.
Gast
#6730998
Uhu U. schrieb: > Das verwendete BT 4.0 Dongle wird von lsusb so angezeigt:Bus 001 Device > 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI > mode) Den gibts jetzt auch als "5.0" mit der exakt identischen devive ID: 0a12:0001 und er funktioniert (immer noch?) NICHT unter Ubuntu 20.10, obwohl es auch mindestens genauso viele Berichte zu dieser ID gibt die angeblich funktionieren. Die Bluetooth Dongle Lotterie läuft also immer noch auf Hochtouren. Mein erstes Los war eine Niete, mal sehen was ich als nächstes ziehe :-/
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.