Bluetooth Low Energy eignet sich ideal für das Vernetzen batteriegestützter Sensoren. Wir zeigen, wie Sie es auf dem Raspberry Pi nutzen.
Bluetooth LE oder kurz BLE bringt neben neuer Technologie eine ganz eigene Begriffswelt mit. Bevor es also um praktische Beispiele geht, fällt etwas Theorie an. Ohne Kenntnis der allgegenwärtigen Begriffe können Sie die vielen Anwendungsbeispiele aus dem Internet nicht einordnen und für die eigenen Bedürfnisse anpassen.
Bei Bluetooth handelt es sich um eine Nahfunktechnik für den Einsatz zwischen zwei Geräten [1]. Bevor eine Verbindung steht, kann ein System entweder ein Peripheriegerät (Peripheral Device) oder ein Zentralgerät (Central Device) sein. Leistungsfähige Devices wie PCs, Tablets und Laptops können beide Rollen einnehmen, schwächere Geräte beschränken sich auf die Rolle als Peripherie.
Jedes Peripheriegerät sendet in regelmäßigen Abständen Werbebotschaften (“Advertisements”) aus, etwa “ich bin der Sensor ABC und biete Herzfrequenzdaten an”. Alternativ kann die Botschaft aber auch lauten: “Ich bin der Sensor XYZ und möchte die aktuelle Zeit wissen”. Herzfrequenzdaten (Heart Rate) und aktuelle Zeit (Current Time) sind sogenannte Services. Bei den beiden handelt es sich um standardisierte Services, aber Hersteller sind frei darin, eigene, proprietäre Dienste zu verwenden. Dazu später mehr.
Abbildung 1: Ein Beispiel für Advertisements aus dem Bluetooth Low Energy Primer der Bluetooth SIG.
Die Abbildung 1 aus dem BLE-Primer der Bluetooth SIG [2] zeigt, dass Geräte für Advertisements mehrere vordefinierte Kanäle des Spektrums nutzen. Wenn Sie sich für technische Details rund um BLE interessieren, sollten Sie dieses Dokument auf alle Fälle lesen.
Verbindungsaufbau
Zentralgeräte scannen ihre Umgebung auf solche Advertisements. Findet sie etwas Interessantes, baut die Zentrale eine Verbindung zum entsprechenden Gerät auf. Sobald die Verbindung steht, stellt das Peripheriegerät den Versand der Werbebotschaften ein. Das ganze Verfahren läuft unter dem Begriff GAP (Generic Access Profile) und ist hier etwas verkürzt dargestellt.
Einmal verbunden, geht es um den Datenaustausch zwischen beiden Geräten. Der zugehörige Standard heißt GATT (Generic Attribute Profile) und regelt, welche Bytes das eine Gerät über Funk zum anderen Gerät sendet. Auch wenn die Verbindung immer von der Zentrale zur Peripherie aufgebaut wird, bedeutet das nicht, dass die Daten nur in eine Richtung fließen. Auch ein bidirektionaler Datenfluss ist möglich, etwa beim UART-Service. BLE definiert dazu die Begriffe Server und Client. Der Client greift lesend respektive schreibend auf den Server zu, der wiederum Daten (mit oder ohne Antwort) an den Client senden kann. Dabei hält der Server die Definition der Ressourcen bereit.
Der Herzfrequenzsensor aus dem vorigen Beispiel wäre der Server. Das Peripheriegerät, das nach der aktuellen Zeit fragt, hätte nach dem Verbindungsaufbau dagegen die Client-Rolle inne. Es kann seinerseits nur hoffen, dass eine Zentrale in die Server-Rolle schlüpft.
Profile und mehr
Ein zentraler Begriff in der BLE-Welt ist der sogenannte Service, der Daten und Verhalten festlegt. Jeder Service trägt eine eindeutige Nummer, die UUID (Universal Unique ID). Die von der Bluetooth SIG standardisierten Services haben 16-Bit-UUIDs, private Services nutzen 128-Bit-UUIDs. Ein offizielles Dokument [3] legt alle standardisierten UUIDs fest. Der Heart Rate Service trägt zum Beispiel die UUID 0x180D.
Mithilfe dieser UUIDs kann eine Zentrale beim Scannen nach Advertisements nur die für sie interessanten Sensoren ausfiltern. Eine App, die den Herzschlag visualisieren will, kann sich somit gezielt mit den geeigneten Sensoren verbinden. Wenn sich jeder an den Standard hält, klappt das sogar herstellerübergreifend.
Eine logische Klammer um mehrere Services stellt das sogenannte Profile dar. Das Heart Rate Profile enthält zum Beispiel zusätzlich noch den Device Information Service (Abbildung 2). Der entsprechende Standard definiert auch die beiden Rollen Collector (Client) und Sensor (Server). Darüber hinaus legt er diverse mehr oder minder wichtige Details fest, etwa dass der Device-Name des Sensors optional überschreibbar sein darf.
Abbildung 2: Ein Beispiel für das Heart Rate Profile aus dem Bluetooth Low Energy Primer der Bluetooth SIG.
Innerhalb eines Services gibt es mehrere logische Attribute beziehungsweise Funktionen, die in der BLE-Terminologie Characteristic heißen. Der Heart Rate Service enthält als Pflicht die Heart Rate Measurement Characteristic und optional unter anderem die Body Sensor Location Characteristic. Jede Characteristic umfasst wiederum benannte Felder mit den eigentlichen Daten.
Scan mich!
Nach so viel Theorie wird es Zeit für ein paar einfache Beispiele. Auf dem Raspberry Pi benötigen Sie dafür nur Python. Die Bibliothek Bleak stellt eine Abstraktionsschicht bereit, die die Anwendung stark vereinfacht. Das Akronym steht etwas gestelzt für BLE Platform Agnostic Klient und weist darauf hin, dass das Paket auf Linux, MacOS und Windows läuft. Für die Programmentwicklung benötigen Sie also nicht unbedingt einen RasPi, auf jeden Fall aber Python ab Version 3.7.
