Messages

Hi,

the function to wake up the screen by waving does not work on my Samsung S24 Fe. It also did not work on my previous S21 FE. I already activated the premission that was explained here: https://help.locusmap.eu/topic/36979-das-aufwecken-des-bildschirms-offnet-die-eingabehilfe-samsung-s23

Any idea how to solve?
 

Regards,

David

Hi Davidos

I belive that this phone does not have a proximity sensor but uses instead virtual proximity sensing (some clever guy found out how to remove one sensor). I'm having the same issue with my Xiaomi, while on my old Samsung S9 (I can spot the sensor at the upper left) waving worked well on Xiaomi there is no such sensor and it is confirmed that it uses proximity sensing (uses a combination of light and gyro) which as a result does not recoginze waving (missing movement).

As a workaround, I keep screen constantly on 

Adapter API Beta feedback:                                                                                                                                 
When the bike is stationary, the sensor adapter keeps sending valid data (battery %, assist mode, range) every 1.5s via the SEC batch. Locus clears the sensor display anyway after a short time. In the previous direct-BLE approach, values persisted. Could there be a persistLastValue option per <refId> in the manifest, or a minimum hold-time before Locus clears adapter values?

Quick update: the issue with power fluctuating between -1 W and real values is now fixed.                                                                     
                                                                                                                                                               
Root cause: The Brose motor returns -1 as a sentinel value for power when the bike is stationary (no pedalling). The adapter was passing this raw value directly to Locus Maps, which displayed it as -1 W.                                                                                                         
                                                                                                                                                               
Fix: Clamp the value to a minimum of 0 before sending — so Locus always receives either 0 W (idle) or the real wattage while riding.     

https://github.com/hoschilo/locus-brose-adapter

Adapter API Beta feedback:                                                                                                                                   
When the bike is stationary, the sensor adapter keeps sending valid data (battery %, assist mode, range) every 1.5s via the SEC batch. Locus clears the sensor display anyway after a short time. In the previous direct-BLE approach, values persisted. Could there be a persistLastValue option per <refId> in the manifest, or a minimum hold-time before Locus clears adapter values?

@Menion:

I wanted to reach out and say thank you for your hard work — genuinely. Your quick response today and the announcement of the Sensor Adapter API 0.10.0 completely changed the trajectory of what I'm building, and in the best possible way.                                                                                                                                                                                     
                                                                                                                                                                                                         
                                                                                                                                                                                                         
With Locus now owning the BLE connection, the "middleman-phone" disappears entirely. Locus on a single device connects directly to the universal display, and our adapter just parses the raw frames. We already have the Brose protocol partially reverse-engineered:                                                                                                                                               
                                                                                                                                                                                                         
  - TEL frame (7×/sec): speed, cadence, battery, assist mode, odometer                                                                                                                                   
  - SEC frame (protobuf, triggered every 2s): motor power, rider power, estimated range                                                                                                                   
                                                                                                                                                                                                         
We've already prepared the adapter — BroseAdapterService, locus_adapter.xml, BroseProtocol.kt — and it's waiting for your Beta to go live tomorrow.                                                     
                                                                                                                                                                                                         
The plan / outlook                                                                                                                                                                                               
                                                                                                                                                                                                         
We intend (after testing) to publish this as an open-source Locus addon on GitHub (locus-brose-adapter) and on Google Play, so the broader Brose motor community can benefit. Is there anything I must consider by publishing an addon from your viewepoint. Brose powers bikes from Scott, Raleigh, Pinarello, Moustache, and others. If you'd like to feature it in the Locus Store or link to it from documentation, we'd be honoured.                                             
                                                                                                                                                                                                         
One open question                                                                                                                                                                                       
                                                                                                                                                                                                         
The HRM sample works without a scanFilter because Locus recognises the standard BT SIG Heart Rate Service UUID. Our Brose motor uses a custom service UUID (31be2300-d927-11e9-8a34-2a2ae2dbcce4). Is there an attribute in <deviceType> or <characteristic> to declare the service UUID for scanning — so Locus can find Brose motors by service UUID rather than by device name prefix?                     
                                                                                                                                                                                                         
Thank you again for this API — it's exactly the right architecture.

thanks and sorry - now public

For those who are interested

https://github.com/hoschilo/EBikeLocus

Hi Menion,

Everything works well so far – battery, assist level, rider power, cadence and speed via CSC Wheel Revolutions are all displayed correctly in the Specialized E-Bike sensor.

However, there is one field in the Specialized E-Bike sensor display that always shows -256 and I cannot figure out what it represents. It is displayed as "Tachometer". There is also no such field in the dashboard which could be selected.....

My question: What is this field and which GATT channel/format does Locus expect for it? Is it the total odometer (km), trip distance, or something else?
For context: I am sending data via the proprietary Levo TCU1 protocol channels (sender/channel format) and also CSC standard service (0x1816) with both Wheel and Crank Revolutions.

Thank you for your great work on Locus Map!

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

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

@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!

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?