Can a LM Add-on be used to receive proprietary sensor data ?

[barbudor]

Hello

As I explained here : https://forum.locusmap.eu/index.php?topic=9031
I just purchased an Orbea Rise eMTB using a Shimano motor which has a BLE connection.
But this is using a proprietary protocol.

Would an add-on able to manage that proprietary connection and push sensor data to Locus Map in order to
- record those sensor in the track and get those data in the exported GPX
- make the data available to dashboard display

The type of data I'm would like to record are both standard ones like speed and cadence, but also not so standard such as the assistance mode (eco, trail, boost), the assistance level (%), the battery level, ...

I can already record those in a separated application (STride), but it would be nicer to use only 1 app and to be able to have also a single dashboard with both the map and some technical data (battery !!!)

Thanks

[Menion]

Hello barbudor,
very good question, thanks for it.

It is something we discussed in the team some time ago > to allow external devs to create and add-on that will supply data from external sensors. It make sense > we are pretty small team, so we are unable to cover all possible devices around the world.

Anyway, how to do it?

There is an option to leave the whole system in the hands of developers and only receive and handle new data from their add-ons. This is the approach we use for our Android Wear watches, where watches may record a heart rate that is sent back to the Locus Map app over undocumented API. This approach may be done for various other data, not just heart rate.

It is easy to do on my side, anyway is it correct? Because for example in your case, you will need to deal with the whole Bluetooth system in the background > it is quite a complex task to make it correctly. Also, such connections won't be aware of the app life-cycle, so for example automatic connecting and disconnecting during track recording won't work. And creating API that will somehow use apps Bluetooth system and add-ons data-reading system ... hmm

So my proposal for now

First option - if you or anyone other wants to deal with Bluetooth/ANT/etc on your own and just supply data to Locus Map, I may prepare an intent-based method for requested data fields.

The second option - I offer direct integration of any sensor into the app, anyway here is necessary to write to me all the information needed for this. UUID of services, characteristics, and specifications of what is inside ...

The third option - it is from my point of view really really complex task (but doable) and I do not have enough free time for this for now, sorry.

[barbudor]

Thanks a lot @menion for your constructive approach

As you understand, the protocol is proprietary and need to be reverse enginneered
Which also rules out option 2 as it would put Locus at risk of a cease and desist suit from Shimano. They did it with bike GPS manufacturer Hammerhead who exactly did that. As of today, only Garmin is license.

So the method must keep the Shimano related code outside of Locus.

An separate app/service could handle that and call an Locus API that would be in no way related Shimano.

So 1st part for me is to investigate the protocol.
Then I will have to learn Android programming 

Would you see that as a reason able approach ?


Still, the author from the STunlock and STride apps haven't seem to receive such C&D order but better safe than sorry.

[Menion]

Thanks for taking care of the Locus Map legality, appreciate it.

And yes, solution no 1. should of course work. It just requires quite a lot of work on your side. It still should be possible to react to for example enabled/disabled track recording in the Locus Map, so the add-on may be clever and automatic. It just needs the Bluetooth logic. I wrote all around BT on my own, but maybe there exists a library that simplifies it, do not know.

[hoschilo]

Hi

May I revive this topic: I'm also interested to display bike data (brose) in a dashboard. So far I was able to read and convert the UUID in Tasker (Tasker BLE addon) isolate the available values such as battery level, support level (velocity and power pending) and store in variables. As i understood it would be possible via intend based method as menion mentioed. Is there any chance that you could provide such?

[barbudor]

@hoshilo
Would you mind sharing what you have done ?
Thanks

On my side I was unable to find time to start learning developping on Android 

[Jan Čapek]

@hoschilo What bike do you target exactly? Because there is already integrated sensor in the Locus Map for Specialized Turbo Levo ebikes which uses Brose motors.

But it was tested and used with 1th generation Turbo Levo and I understand that newer models may not be fully compatible with the sensor due to some little changes in the communications compared to older one.

So I would recommend to first test that already implemented "Specialized" sensor to find out whether it is working for you or not. If not the easiest way for Brose motor should probably be to just do minor modifications and make it work again even with newer models.

[kulfon]

Hi,
i have SPecialized Turbo Levo gen 3 and woud like to support you with adding support for this bike.
What i can do to make it visible in Locus? I can't see bike under eBikes but i can see some bluetooth sensors but unfortunatly result after adding them is that not correct data received.
BR
adam

[hoschilo]

@hoschilo What bike do you target exactly? Because there is already integrated sensor in the Locus Map for Specialized Turbo Levo ebikes which uses Brose motors.

But it was tested and used with 1th generation Turbo Levo and I understand that newer models may not be fully compatible with the sensor due to some little changes in the communications compared to older one.

So I would recommend to first test that already implemented "Specialized" sensor to find out whether it is working for you or not. If not the easiest way for Brose motor should probably be to just do minor modifications and make it work again even with newer models.

Dear Jan

Im running a Rotwild RC750 with Brose motor. Unfortunately the available sensor for Specialized Turbo does not work.

To be more flexible also for other users I think the intend baseed method suggested by Menion above would be a good approach.

I am ready to test it immediately.

I have already:
1. Reverse-engineered the Brose BLE protocol
2. Built an Android app that reads: battery %, assist mode
  (ECO/TOUR/SPORT/BOOST), motor power (W), odometer (km)

Still to be finetuned and extended to other bike values.

Thank you!

[hoschilo]

Just an update from my side:

I was able with the strong help of Claude to fake Levo bike wiht Brose data and now I can display assist mode, power, battery on my dashboard. Next step is cadence sensor then I'm good. As I have almost no programming skills, spent many hours on trial and err and more than hundred versions.....JC

[Menion]

Hello,
amazing 

I planned to invest a little more time into the Locus API and add support for a predefined set of variables that may be passed into the app.

You are just too fast, and there is currently no useful support for what you may need.

How do you imagine continuing? Are you planning to create an add-on on the Google Play and handle the connections to bike on your own? And then just send over Locus API data into Locus Map app?

[hoschilo]

Hi Menion,

Thank you for your response! Let me explain what I've actually already built.

I own a Rotwild e-bike with a Brose motor. I reverse-engineered the proprietary BLE protocol (GIGATRONIK/TCU1) that the Qore/Brose app uses to communicate with the bike.

My Android app runs on my main/daily phone, reads the live telemetry from the Central Display (speed, cadence, battery, assist level, rider power, motor power), and then emulates a Specialized Levo GATT server toward Locus Map running on a second phone which is only used for navigation wiht locus maps.

Locus already has built-in support for "Specialized E-Bike" sensors — so my app essentially pretends to be the real bike hardware. It works surprisingly well: Locus connects, subscribes, and displays battery, assist mode, cadence and power in real time.

So I'm not looking so far to publish a Play Store add-on — I just want my own setup to work reliably. But this experience made me think about how a proper API could work for the broader community.


From my reverse-engineering I found that even a single motor brand (Brose) uses mixed data formats: simple fixed-size values (uint8 for battery %, cadence, assist level; uint16 LE for speed and power) but also Protocol Buffers (Protobuf) for more complex telemetry like estimated range, trip odometer, voltage and calculated motor power.

Other brands (Bosch, Shimano, Yamaha) will have completely different protocols and even different semantics — for example assist levels: Brose uses 0–4, Bosch uses named modes (Eco/Tour/Sport/Turbo), Shimano again differently. So a good API should treat all fields as optional/nullable and represent assist as a generic integer 0–N plus an optional label string.

A reasonable base set of fields would be: battery_percent (int), assist_level (int + optional string label), speed (float, km/h), cadence (int, RPM), rider_power (int, W), motor_power (int, W), estimated_range (float, km), trip_distance (float, km), battery_voltage (float, V).


The cleanest solution would be a plugin/adapter model: Locus provides the stable API with these fields, and the community writes small adapter apps that know the specific bike protocol and translate into the Locus format. Similar to how Garmin Connect IQ works, or OBD2 adapters. My "EBikeLocus" app could essentially be the first such community adapter and serve as a reference implementation.


One of the biggest challenges is that reverse-engineering a proprietary BLE protocol is very time-consuming. It would be extremely valuable to have a tool — perhaps even built into Locus or as a companion app — that captures raw BLE notifications and lets the user interactively assign data types to byte ranges (uint8, uint16 LE/BE, int16, float, with offset and scale factor) until the values make sense. Something like a visual BLE packet parser. This would dramatically lower the barrier for users to map their own bike's protocol without needing deep technical knowledge. The main limitation is Protobuf-based protocols, which are harder to decode without the schema — but for simpler fixed-byte protocols it would work very well.

If you're planning to extend the API in that direction, I'd be very happy to share my detailed findings about the Brose/Qore protocol and collaborate on defining the API fields.

Best regards