Unterstützung bei der Open-Source-Integration des Bosch Smart Systems (LDI & BLE) gesucht

[hesinde2006]

Hallo zusammen,

ich möchte diesen Thread einmal aktualisieren, weil sich bei BikeBridge seit meinem ursprünglichen Beitrag im Juli einiges getan hat. Damals lag unser Schwerpunkt noch sehr stark auf der Frage, wie wir die Bosch-Smart-System-Kommunikation vollständig zum Laufen bekommen. Inzwischen ist das Projekt deutlich weiter und wir beschäftigen uns mit weiteren Themen und Herstellern.

Was ist BikeBridge?​

BikeBridge ist ein nichtkommerzielles Open-Source-Projekt für Android. Unser Ziel ist es, Telemetriedaten verschiedener E-Bike-Systeme in einer gemeinsamen, konfigurierbaren App auszulesen und darzustellen.

Projektseite: https://bridge.bike
Quellcode: https://codeberg.org/bg443/BikeBridge

Mich persönlich hat ursprünglich vor allem eine einfache Frage angetrieben: Warum kann ich nicht mehr über mein eigenes Fahrrad erfahren?

Mich interessieren beispielsweise das Verhältnis zwischen Fahrerleistung und Motorleistung, aussagekräftigere Reichweitenschätzungen und generell mehr Einblick in die Daten, die mein Bike ohnehin erzeugt. Außerdem wäre es mir wichtig, dafür möglichst unabhängig von einer Hersteller-App und einer Cloud zu sein.

Datenschutz spielt dabei eine große Rolle. Ich möchte nachvollziehen können, welche Daten lokal verfügbar sind und wie ich sie selbst nutzen kann, ohne unnötig von proprietären Diensten abhängig zu sein.

Wo stehen wir inzwischen?​

Die Unterstützung des Bosch Smart Systems (BES ist inzwischen deutlich weiter fortgeschritten. Der Verbindungsaufbau und der notwendige Handshake sind integriert. Wir können Bosch-Telemetrie empfangen und dekodieren bereits verschiedene Messwerte.

Außerdem haben wir die Forschung zu Protokollen, Datenfeldern und unterschiedlichen Transportwegen systematisiert und eine umfangreiche Sammlung von BES3-Adressinformationen integriert. Die technische Validierung einzelner Datenfelder und deren zuverlässige Anzeige bleiben wichtige Aufgaben.

Parallel beschäftigen wir uns mit Shimano EP8/STEPS und SRAM Eagle Powertrain. Die Unterstützung und der jeweilige Entwicklungsstand unterscheiden sich je nach System.

Auch die Benutzeroberfläche möchten wir weiter verbessern. Dazu gehören ein übersichtliches Live-Dashboard, sinnvoll dargestellte Messwerte, Diagramme und eine gute Anpassbarkeit.

Warum nicht einfach für jeden Hersteller eine eigene App?​

Genau das ist einer der Gründe, warum wir BikeBridge entwickeln. Es gibt inzwischen viele einzelne Projekte, die sich mit bestimmten Motoren, Komponenten oder Kommunikationsprotokollen beschäftigen. In diesen Projekten steckt oft wertvolle Arbeit.

Wir würden gern mehr davon zusammenbringen, voneinander lernen und, wo es technisch und lizenzrechtlich sinnvoll ist, auf vorhandenen Erkenntnissen aufbauen. Unser Ziel ist eine gemeinsame App, in der Daten verschiedener Hersteller möglichst einheitlich dargestellt werden.

Es geht dabei nicht darum, andere Projekte zu verdrängen oder deren Arbeit ungefragt zu übernehmen. Erfahrungsaustausch, nachvollziehbare Quellen und Zusammenarbeit sind uns wichtig.

Was wir ausdrücklich nicht vorhaben​

BikeBridge soll eine Telemetrie-App bleiben. Wir wollen Daten auslesen, dekodieren und anzeigen, nicht das Verhalten des Antriebs verändern.

Tuning, das Umgehen von Geschwindigkeitsbegrenzungen, Veränderungen der Motorsteuerung und Firmware-Manipulationen gehören nicht zu unserem Projektumfang.

Bei der Entwicklung achten wir außerdem auf die Herkunft technischer Informationen, die Lizenzen verwendeter Projekte und die jeweils relevanten Nutzungsbedingungen. Die eigenständige Implementierung und eine nachvollziehbare Dokumentation sind uns wichtig.

Wer könnte mithelfen?​

Unser Kernteam ist weiterhin ziemlich klein – ungefähr vier Leute beschäftigen sich intensiver mit dem Projekt. Deshalb freuen wir uns über weitere Menschen mit Interesse an einem der folgenden Bereiche:

• Android/Kotlin und Jetpack Compose: Dashboard, UI/UX, Architektur und Tests.
• Bluetooth LE und USB: praktische Erfahrung mit Verbindungen, GATT, Datenübertragung und Protokollanalyse.
• E-Bike-Systeme: Erfahrungen mit Bosch, Shimano, SRAM oder anderen Herstellern, unterschiedlichen Modellen und Firmwareständen.
• Hardwaretests: Telemetrie auf realen Fahrrädern überprüfen und Ergebnisse nachvollziehbar dokumentieren.
• Dokumentation und Open Source: vorhandene Projekte vergleichen, Erkenntnisse zusammentragen und die Zusammenarbeit verbessern.

Man muss nicht alles können und auch kein ausgewiesener E-Bike-Experte sein. Manchmal hilft schon ein konkreter Hinweis, ein zusätzlicher Hardwaretest oder Erfahrung aus einem verwandten Projekt.

Wie geht es weiter?​

Ich würde mich freuen, wenn sich hier weitere Leute finden, die Lust haben, an BikeBridge mitzuarbeiten oder ihre Erfahrungen mit uns zu teilen. Vielleicht habt ihr selbst an einem ähnlichen Projekt gearbeitet, kennt eine interessante Implementierung oder habt Ideen, wie wir unsere begrenzten Ressourcen besser einsetzen können.

BikeBridge ist ein freiwilliges Open-Source-Projekt ohne kommerzielles Geschäftsmodell. Wir möchten vorhandene Daten sinnvoll nutzbar machen und unsere Erkenntnisse – soweit zulässig – nachvollziehbar dokumentieren, damit nicht jeder wieder bei null anfangen muss.

Vielen Dank fürs Lesen und für alle Hinweise, Erfahrungen und Beiträge!

Viele Grüße
Nik

 

[punkhead]

wünsche euch viel spaß und erfolg beim "hacken"
Bosch hat seine Hausaufgaben gemacht und gibt die selbst gesammelten Daten nicht so leicht her.

 

[hesinde2006]

Vielen Dank!


Genau zu diesem Eindruck sind wir im Laufe der letzten Wochen ebenfalls gekommen.


Inzwischen konnten wir die Bluetooth-Kommunikation zwischen BikeBridge und dem Bosch Smart System bereits sehr weit analysieren und instrumentieren. Dazu gehören unter anderem detailliertes BLE-Logging, GATT-Operationen, MCSP-Frame-Reassembly sowie umfangreiche Vergleichstests mit HCI-Mitschnitten der Bosch Flow App.


Interessant ist, dass die Bosch Live Data Interface (LDI) sogar offiziell von Bosch dokumentiert ist. Bosch stellt dazu eine öffentliche Spezifikation inklusive der Live Data Interface Protocol Buffer (.proto)-Definition bereit. Auf Grundlage dieser Dokumentation konnten wir die LDI-Kommunikation bereits implementieren und mit der Spezifikation abgleichen.


Unser aktueller Stand deutet deshalb darauf hin, dass das eigentliche Problem nicht mehr das Protokoll selbst, sondern die Aktivierung des Datenstroms ist. Es scheint noch einen Initialisierungs- bzw. Trigger-Schritt zu geben, der bislang fehlt.


Genau dieses letzte Puzzleteil versuchen wir momentan zu finden. Dafür vergleichen wir verschiedene Smart-System-Bikes (u. a. SX und CX), HCI-Mitschnitte der Bosch Flow App sowie andere Open-Source-Projekte wie Home Assistant und OpenTracks.


Falls jemand praktische Erfahrungen mit dem Bosch Smart System, der LDI-Initialisierung, zusätzlichen GATT-Operationen, Firmware-Unterschieden oder ähnlichen Themen hat, würden wir uns über jeden Hinweis freuen. Inzwischen suchen wir vermutlich eher nach einem kleinen, aber entscheidenden Detail als nach einer grundsätzlichen Lösung.


Unser Ziel ist weiterhin eine offene, datenschutzfreundliche und herstellerunabhängige Unterstützung des Bosch Smart Systems in BikeBridge sowie eine saubere Dokumentation der gewonnenen Erkenntnisse, damit auch andere Entwickler davon profitieren können.

 

[hesinde2006]

Forschungs-Update (Juni 2026)​

Hallo zusammen,


zunächst einmal vielen Dank für die bisherigen Rückmeldungen und die vielen privaten Nachrichten.


Seit Eröffnung dieses Threads haben wir in den letzten Wochen erhebliche Fortschritte erzielt, sodass ich den aktuellen Stand einmal vollständig zusammenfassen möchte.

Aktueller Forschungsstand​

Unsere Untersuchungen basieren inzwischen auf drei unabhängigen Quellen, die wir konsequent miteinander vergleichen:

• Bluetooth-HCI-Mitschnitte eines Bosch Smart Systems
• die offizielle Bosch Live Data Interface (LDI)-Dokumentation inklusive der veröffentlichten Protobuf-Definitionen
• verschiedene Open-Source-Projekte, insbesondere Home Assistant / ESPHome

Wir versuchen grundsätzlich, Erkenntnisse nur dann als gesichert anzusehen, wenn sie durch mehrere unabhängige Quellen bestätigt werden.

---

Was wir inzwischen mit hoher Sicherheit verstanden haben​

Nach unserem aktuellen Stand verstehen wir die grundlegende Architektur des Bosch Smart Systems inzwischen sehr gut.


Der Kommunikationsweg lässt sich heute wie folgt beschreiben:


Bluetooth LE


↓


GATT


↓


Bosch LDI Service


↓


MCSP Transport


↓


Protobuf


↓


LiveData


Darüber hinaus konnten wir unter anderem folgende Punkte nachvollziehen:

• BLE-Verbindungsaufbau
• Service Discovery
• Characteristic Discovery
• Descriptor Discovery
• CCCD-Aktivierung
• MTU-Verhandlung
• Notification-Verarbeitung
• MCSP-Framing
• Protobuf-Struktur
• Dekodierung der dokumentierten LiveData-Felder (Geschwindigkeit, Trittfrequenz, Fahrerleistung, Akkustand, Odometer usw.)

BikeBridge besitzt inzwischen außerdem:

• dynamische GATT-Auflösung
• vollständige Session-State-Machine
• Replay-Infrastruktur
• forensisches Session-Logging
• MCSP-Decoder
• LiveData-Decoder
• strukturierte Forschungs- und Exportformate

Die reine BLE-Infrastruktur betrachten wir daher inzwischen als weitgehend abgeschlossen.

---

Was sich gegenüber dem ursprünglichen Beitrag geändert hat​

Als ich diesen Thread eröffnet habe, gingen wir noch davon aus, dass das eigentliche Problem die Dekodierung der Bosch-Telemetrie sei.


Heute sehen wir das anders.


Die eigentliche Datenstruktur ist inzwischen weitgehend verstanden.


Auch die offizielle LDI-Spezifikation passt erstaunlich gut zu unseren eigenen Beobachtungen.


Die verbleibenden Fragen liegen inzwischen hauptsächlich im Bereich der Initialisierung und experimentellen Verifikation.

---

Wo wir noch nicht ganz sicher sind​

Einige Punkte sind noch nicht vollständig geklärt.


Insbesondere:

• der exakte Ablauf der Session-Initialisierung
• der vollständige Replay des Subscription-Handshake
• Details des MCSP-Headers
• Unterschiede zwischen verschiedenen Firmware-Versionen
• Unterschiede zwischen SX-, CX- und weiteren Smart-System-Antrieben
• Unterschiede zwischen Purion 200, Kiox 300, Kiox 500 und SmartphoneGrip
• einzelne bislang unbekannte Protobuf-Felder neuerer Firmware-Versionen

Wir vermuten inzwischen, dass genau hier die letzten offenen Fragen liegen.

---

Was wir bereits ausprobiert haben​

In den vergangenen Monaten haben wir unter anderem untersucht:

• Bluetooth-HCI-Mitschnitte
• Wireshark-Analysen
• MCSP-Reverse-Engineering
• Vergleich mehrerer Firmware-Versionen
• Bosch-LDI-Dokumentation
• Home Assistant
• ESPHome
• verschiedene Android-Projekte
• Replay-Analysen
• zahlreiche Vergleichstests

Darüber hinaus haben wir bereits versucht, Unterstützung über

• Reddit,
• Facebook-Gruppen,
• verschiedene Entwickler-Communities,
• Open-Source-Projekte
• sowie Bosch selbst

zu erhalten.


Leider gibt es bislang nur sehr wenige öffentlich verfügbare technische Informationen zum Bosch Smart System.

---

Wobei uns inzwischen am meisten geholfen wäre​

Inzwischen suchen wir deutlich gezielter Unterstützung.


Besonders hilfreich wären:

• Entwickler mit Erfahrung in Bluetooth Low Energy
• Android-Entwickler
• Embedded-Entwickler (ESP32 o. Ä.)
• Personen mit Erfahrungen im Bosch Smart System
• Besitzer unterschiedlicher Smart-System-Bikes und Firmware-Versionen
• zusätzliche Bluetooth-HCI-Mitschnitte
• Kontakte zu Bosch oder Entwicklern des Smart Systems

Ebenso interessant wären Erfahrungen zu Fragen wie:

• Gibt es Unterschiede zwischen verschiedenen Firmware-Versionen?
• Verhält sich LDI auf SX und CX identisch?
• Gibt es Unterschiede zwischen Purion 200, Kiox 300, Kiox 500 oder SmartphoneGrip?
• Sind weitere Telemetriedaten bekannt?
• Hat bereits jemand erfolgreich einen eigenen Read-Only-Client aufgebaut?

---

Unsere aktuelle Einschätzung​

Nach heutigem Stand glauben wir, dass wir für einen Read-Only-LiveData-Client bereits sehr weit gekommen sind.


Die grundlegende Architektur verstehen wir inzwischen mit hoher Sicherheit.


Der Schwerpunkt liegt heute nicht mehr auf klassischem Reverse Engineering, sondern auf der experimentellen Verifikation der letzten offenen Hypothesen.


Unser Ziel bleibt unverändert:


Eine offene, datenschutzfreundliche und herstellerunabhängige Möglichkeit, die offiziell verfügbaren LiveData-Daten des Bosch Smart Systems lokal zu nutzen – ohne Cloud-Zwang und ohne Eingriffe in das Fahrrad.


Nach unserem aktuellen Kenntnisstand scheint sich die verbleibende Unsicherheit auf wenige, klar abgrenzbare Punkte zu konzentrieren – insbesondere die Initialisierung des LiveData-Streams und deren experimentelle Verifikation.

Falls jemand eigene Erfahrungen, zusätzliche Informationen oder Interesse an einer Mitarbeit hat, würden wir uns sehr über einen Austausch freuen.


Vielen Dank!

 

[petermuss]

Bike Bridge

Moin aus Hagen/Westf.

Das ist ein sehr spannendes Projekt und ich habe sofort ein paar Fragen, die Du hoffentlich beantworten kannst:

1) gibt es ein solches Projekt auch für die Bosch BES2 Motoren?
2) ist ein modularer Aufbau der Hard- und Software geplant?
- mein Ansatz war: ein Hardware-Dock incl. einem Snap-On/In Anschluss zur Aufnahme eines Smartphones
- proprietär zur Motor-Seite, einheitlich zur Smartphone App
- sollte ähnlich dem COBI fior Bosch SmartPhoneHub gestaltet sein
alle Infos zum Cobi hier: Youtube Video
mein Augenmerk ist:
- offener Software Standard zur App
- KEIN Tuning oder ähnliche Eingriffe in die Motorsysteme
- sichere Befestigung des Docks am Lenker, Vorbau incl. Diagnose-Anschluss für die Vertragswerkstätten
- Stromversorgung des Smartphones vom E-Bike Akku
- nur ein zentrales Gerät für die Motor-Daten, Navi, Licht-Steuerung und ext. Sensoren wie Herzfrequenz, (...)

Gerne arbeite ich an dem Projekt mit, kann aber eher Ideen und ein wenig Programmier-Erfahrung sowie 3D-Drucker einbringen

Bei Interesse freue ich mich über eine Rückmeldung!

Peter

 

[hesinde2006]

Hallo Peter,

vielen Dank für deine Nachricht und dein Interesse am Projekt! Das freut uns wirklich sehr.

Zu deinen Fragen:

1) Unterstützung für Bosch BES2​

Der aktuelle Schwerpunkt liegt vollständig auf dem Bosch Smart System (BES, weil es dort bisher kaum offene Lösungen gibt und wir in den letzten Monaten bereits sehr weit gekommen sind.
Grundsätzlich möchten wir die Architektur aber so modular halten, dass später auch andere Systeme (z. B. BES2) integriert werden können.

2) Modularer Aufbau​

Genau das ist eines unserer wichtigsten Ziele.

BikeBridge selbst ist bereits herstellerübergreifend aufgebaut. Die Bosch-Unterstützung soll möglichst als eigenständiges Modul integriert werden, sodass die eigentliche App weitgehend unabhängig vom jeweiligen Hersteller bleibt.

Auch Hardware möchten wir – soweit sinnvoll – von der Software trennen.

Ein offener Aufbau mit klaren Schnittstellen erscheint uns langfristig als der beste Weg.

Dock / Smartphone-Lösung​

Die Idee gefällt uns sehr gut.

Im Moment konzentrieren wir uns allerdings vollständig auf die Software:

• stabile Bluetooth-Kommunikation
• Read-Only-Telemetrie
• keine Cloud-Abhängigkeit
• keine Veränderungen am Motor
• keine Tuning-Funktionen

Wenn diese Basis zuverlässig funktioniert, wären Themen wie Dock, Smartphone-Halterung, Spannungsversorgung oder zusätzliche Sensorik sehr interessante nächste Schritte.

Unser aktueller Entwicklungsstand​

Seit der Eröffnung dieses Threads hat sich das Projekt deutlich weiterentwickelt.

Inzwischen verfügen wir unter anderem über:

• vollständige GATT-Queue
• serielle BLE-Kommunikation
• Replay-System
• Session-Logging
• MCSP-Decoder
• LDI-Decoder
• Research Mode
• umfangreiche HCI-Analysen
• strukturierte Exportformate

Die grundlegende BLE-Infrastruktur betrachten wir inzwischen als weitgehend abgeschlossen. Unser aktueller Schwerpunkt liegt auf der experimentellen Verifikation der letzten Initialisierungsschritte und der sauberen Integration in BikeBridge.

Falls doch das Thema interessiert​

Vielleicht hast du ja Lust, dich einmal selbst durch die Quellen zu klicken. Wir haben viele Erkenntnisse genau durch den Vergleich verschiedener Projekte gewonnen.

Ein guter Einstieg ist beispielsweise:

• Offizielle Bosch Live Data Interface (LDI) Spezifikation
• Bosch LDI Protocol Buffers (.proto)
• Home Assistant Bosch Smart System
• ESPHome Bosch Smart System
• OpenTracks
• BikeBridge
• RobbyPees Bosch Smart System Android Projekt

Diese Projekte betrachten das Bosch Smart System aus unterschiedlichen Blickwinkeln und ergänzen sich erstaunlich gut. Genau dieser Vergleich hat uns in den letzten Monaten mehrfach weitergebracht.

Unser Ziel​

Uns geht es ausdrücklich nicht um Tuning oder Eingriffe in das Fahrverhalten.

Unser Ziel ist eine offene, datenschutzfreundliche und herstellerunabhängige Möglichkeit, die offiziell verfügbaren Live-Daten des Bosch Smart Systems lokal zu nutzen – ohne Cloud-Zwang und mit einer sauberen Dokumentation, damit andere Entwickler nicht dieselbe Arbeit noch einmal machen müssen.

Vielen Dank auch für dein Angebot zur Mitarbeit!

Gerade Ideen aus den Bereichen Hardware, Mechanik, 3D-Druck oder ein modulares Dock könnten später sehr spannend werden. Wenn wir an diesem Punkt angekommen sind, kommen wir gerne darauf zurück.

Viele Grüße

Nik

 

[punkhead]

schon mal im Umfeld des CCC "gewildert"?

Habt ihr schon mal untersucht, ob der Initialisierungstrigger im Zusammenhang mit der Datenübertragung der App zusammenhängt.
Also die Daten werden erst über BLE übertragen, sobald die App Verbindung zum Backend hat?

 

[Alles "Trek"]

Ich habe keine Ahnung was da technisch beschrieben wird. Will ich auch nicht.

Aber wer ist "wir" die dahinter stehen.
Und warum opfert man da jede Menge Ressourcen? Will will man damit Geld verdienen, was ist das Geschäftsmodell dahinter?
Nur "Forschung"? Also Beschäftigungstherapie (Praxisarbeit) für angehende ITler?

 

[hesinde2006]

Hallo zusammen,

ich möchte meine damalige Antwort noch etwas aktualisieren, weil sich das Projekt seitdem weiterentwickelt hat.

Hinter BikeBridge steckt weiterhin kein Unternehmen. Wir sind eine kleine Gruppe von Leuten, die sich aus unterschiedlichen Gründen mit der Technik beschäftigen. Ungefähr vier Personen arbeiten derzeit intensiver am Projekt; darüber hinaus stehen wir mit weiteren Entwicklern und Projekten im Austausch.

Warum der Aufwand?

Mich persönlich interessiert vor allem, wie ich die lokal verfügbaren Daten meines eigenen Fahrrads sinnvoll nutzen kann. Ich möchte beispielsweise Fahrerleistung und Motorleistung besser miteinander vergleichen, die Reichweite fundierter einschätzen und mehr über das Verhalten meines Bikes erfahren.

Dazu kommt der Datenschutzgedanke: Ich würde gern möglichst viele Daten lokal verwenden können, ohne dafür zwingend auf eine Hersteller-App oder Cloud angewiesen zu sein. Welche Daten bei einer konkreten Hersteller-App tatsächlich wohin übertragen werden, möchte ich nicht spekulieren, sondern anhand belastbarer Informationen beurteilen.

Ein zweiter Grund ist die Open-Source-Idee. Es gibt bereits viele einzelne Projekte, die unterschiedliche E-Bike-Systeme untersuchen. Wenn wir Erkenntnisse austauschen und geeignete Lösungen zusammenbringen, muss nicht jeder dieselben Grundlagen erneut erforschen.

Seit meinem ursprünglichen Beitrag haben wir auch beim Bosch Smart System weitere Fortschritte gemacht. Der Verbindungsaufbau beziehungsweise Handshake ist inzwischen integriert. Die damalige Suche nach einem einzelnen fehlenden Initialisierungsschritt beschreibt daher nicht mehr unseren aktuellen Arbeitsstand.

BikeBridge entwickelt sich außerdem über Bosch hinaus weiter. Wir arbeiten auch an Shimano- und SRAM-Unterstützung und möchten insbesondere die Telemetrieanzeige und die Benutzeroberfläche verbessern.

Dass es andere Projekte wie BES3 Analyzer oder spezialisierte Hersteller-Tools gibt, finde ich deshalb nicht grundsätzlich problematisch. Solche Projekte können sich ergänzen. BikeBridge verfolgt das Ziel, Daten verschiedener E-Bike-Systeme in einer gemeinsamen Android-App bereitzustellen. Wo andere Projekte bereits gute Lösungen oder wertvolle Erkenntnisse haben, möchten wir lieber zusammenarbeiten, als unnötig alles doppelt zu entwickeln.

Es gibt derzeit kein kommerzielles Geschäftsmodell. Unser Schwerpunkt liegt auf einer nachvollziehbaren, möglichst datenschutzfreundlichen Telemetrie-App. Wir wollen weder Firmware verändern noch in die Motorsteuerung eingreifen oder Tuningfunktionen bereitstellen.

Was uns momentan tatsächlich helfen würde, wären zusätzliche Mitstreiter mit Erfahrungen in Android/Kotlin, Bluetooth, Protokollanalyse, anderen E-Bike-Systemen oder praktischen Hardwaretests. Wir sind nur eine kleine Gruppe und freuen uns über jeden, der sich einbringen möchte – auch mit einem begrenzten Beitrag.

Projekt und Quellcode:
https://bridge.bike
https://codeberg.org/bg443/BikeBridge

Viele Grüße
Nik