Looking for Bosch Smart System developers and BLE experts (Open Source BikeBridge project)

[stereodreieck86]

Hi everyone,


I'm one of the contributors to the open-source Android project BikeBridge, which aims to provide a privacy-friendly, vendor-independent companion app for modern e-bikes.


During the last months we've been working extensively on Bosch Smart System support.

Current status​

We've already implemented a large part of the BLE infrastructure, including:

• robust GATT queue
• extensive BLE logging and replay framework
• MCSP frame reassembly
• reverse engineering of Bosch telemetry
• comparison against Bosch Flow HCI captures
• support for replaying captured traffic for offline analysis

Our current research repository documents all of this work in detail.

The remaining problem​

The remaining challenge is enabling Bosch's Live Data Interface (LDI).


Interestingly, LDI is officially documented by Bosch through the Live Data Interface (LDI) Specification, including the published protobuf definitions describing the telemetry messages.


So the message format itself is no longer the main obstacle.


The problem is that there still seems to be an unknown activation or negotiation step before the Bosch drive actually starts transmitting LDI telemetry.

What we've already tried​

• Reverse engineering Bosch Flow
• BLE HCI captures
• MCSP analysis
• Comparing multiple firmware versions
• Studying Bosch's official LDI documentation
• Comparing with the Home Assistant implementation
• Contact with the Home Assistant developer (Xunil99)
• Contact with Bosch B2B

At this point we believe we're missing one small piece of the puzzle.

We're looking for​

Maybe someone here

• has worked with Bosch Smart System,
• has reverse engineered BLE communication,
• knows how LDI is activated,
• develops diagnostic tools,
• or simply has ideas that could help.

Even small hints such as

• "Firmware X behaves differently."
• "This characteristic has to be read first."
• "Another write command is required."
• "SX and CX behave differently."

could save us weeks of work.


We're also looking for people who would like to contribute to the project. This is an entirely volunteer-driven open-source effort.


Any ideas are greatly appreciated!


Thanks!

 

[stereodreieck86]

Update (Research Status – June 2026)​

Over the last few weeks we've made much more progress than when I originally opened this thread, so I wanted to post a complete status update.

Project Goal​

BikeBridge is an independent, open-source research project whose goal is to build a privacy-friendly, vendor-independent, read-only client for the Bosch Smart System Live Data Interface (LDI).


The goal is not to bypass Bosch security, tune the bike or modify firmware.


The focus is interoperability, research and local ownership of live telemetry.

---

Current Research Status​

Our work is now based on three independent sources that have been cross-checked against each other:

• Bluetooth HCI captures recorded from a real Bosch Smart System bike
• Bosch's official Live Data Interface (LDI) documentation and published protobuf definitions
• Open-source implementations (especially Home Assistant / ESPHome)

Whenever possible we only accept conclusions that are supported by more than one of these sources.

---

What we now understand with high confidence​

We now have high confidence in the following parts of the protocol:

BLE Architecture​

• BLE connection
• Service discovery
• MTU negotiation
• CCCD activation
• Notifications vs Writes

Protocol Stack​

BLE


↓


GATT


↓


Bosch LDI Service


↓


MCSP Transport


↓


Protobuf


↓


LiveData messages

LiveData​

We understand the structure and decoding of the documented telemetry including:

• Speed
• Cadence
• Rider Power
• Battery State of Charge
• Odometer
• Bike status flags

The decoder is already capable of parsing these values.

MCSP​

The transport framing is largely understood:



<span>0x30<br>Length<br>Payload</span>


Multiple frames may be packed into one BLE notification.

---

What is no longer a blocker​

Originally we believed the protobuf format itself was the main problem.


It isn't.


The protobuf format is now well understood.


Likewise, the BLE infrastructure is no longer the main obstacle.

---

What is still unknown​

The remaining questions are now much smaller, but also much harder.

1. Session activation​

We believe there is a subscription or initialization sequence that starts LiveData streaming.


The overall flow appears to be:


Connect


↓


Service Discovery


↓


CCCD Enable


↓


Subscription / Initialization


↓


Periodic LiveData Notifications


The remaining question is:


What exactly is required to start the stream?

---

2. Replay validation​

Our current hypothesis is that replaying the subscription write observed in Bluetooth captures may be sufficient to start the LiveData stream.


This has not yet been experimentally confirmed with an independent client.


This is currently our highest-priority experiment.

---

3. MCSP details​

The overall framing is understood.


However we still don't fully understand:

• header bits
• possible fragmentation flags
• protocol versioning
• optional routing information

These are interesting for documentation but are probably not blockers for a read-only client.

---

4. Unknown telemetry​

Some protobuf fields remain unidentified.


These appear mainly in newer firmware versions.


We suspect they may correspond to newer Smart System features, but we currently don't have enough evidence to identify them with confidence.

---

What we've already tried​

Over the last months we've already explored many different approaches.


Including:

• Bluetooth HCI analysis
• Wireshark analysis
• Reverse engineering MCSP
• Comparison of multiple firmware traces
• Bosch official LDI documentation
• Home Assistant implementation
• ESPHome decoder
• Contact with the Home Assistant developer
• Contact with Bosch B2B
• Posts on Reddit
• Facebook groups
• Multiple forums

Unfortunately most communities either had very little information about the protocol itself or no developers working on this topic.

---

What we are looking for now​

At this point we are not primarily looking for more reverse engineering ideas.


Instead, we're looking for people who can help validate the remaining hypotheses.


Especially:

• Bosch Smart System developers
• BLE specialists
• Embedded developers
• ESP32 developers
• Android BLE developers
• People with multiple Smart System bikes
• Different firmware versions
• Different displays (Purion 200, Kiox 300, Kiox 500, SmartphoneGrip)

---

We'd also really appreciate help with​

Bosch contacts​

If anyone has contacts inside Bosch working on the Smart System or Live Data Interface, we'd be very interested in talking to them.

---

Additional HCI captures​

Especially from:

• different firmware versions
• different displays
• different drive units

---

Developers​

We'd love to collaborate with experienced developers interested in open interoperability.

---

Media​

If anyone knows journalists, YouTubers, bloggers or publications interested in open ecosystems, interoperability, cycling technology or privacy, we'd be grateful for introductions.

---

Current Assessment​

For a read-only LiveData client, we believe we're approximately 90–95% of the way there.


The remaining work is primarily experimental validation, not protocol discovery.


The single most important next step is demonstrating that an independent client can establish a BLE connection, perform the required initialization sequence and receive the periodic LiveData stream.

---

Final Note​

If anyone has experience with Bosch Smart System internals, firmware differences, BLE behaviour, or simply wants to contribute to an open research effort, we'd be delighted to hear from you.


Even small observations could help verify the remaining pieces of the puzzle.


Thank you for reading!