Changelog
Documentation [beta]

Have something to say?

Tell us how we can make ABRP even better for you! ⚡️

Suggestion: Support for WiFi OBD Devices in Live Data

Hello, I would like to suggest adding support for WiFi OBD devices in the Live Data connection options. Currently, many users rely on Bluetooth OBD adapters, but some vehicles and setups work better with WiFi-based OBD devices. Allowing users to connect Live Data via WiFi OBD adapters would provide more flexibility and compatibility with a wider range of hardware. It would also be helpful for users who already own WiFi OBD scanners. Thank you for considering this feature. I believe it would improve the usability of the app for many EV drivers. Best regards.

Vedat METİN 1 day ago

Reintroduce manual Charge overhead time.

When planning longer trips during the summer I often added 10 or 15 minutes to the Charing overhead time to allow for: *Waiting for an available charger *Finding the charger (sometimes the route displayed is not available) *Ramp up time for the charger *Technical issues to start the charging (network coverage etc) When planning a full day of driving that includes multiple Charing stops each delay adds up and might lead to a missed deadline. Now I count the stops and calculate the extra time manually outside ABRP. It would not be a big thing if I was not used to be able tu use ABRP for this function in the past.

Erik S 8 days ago

1

Plan with alternate charger

Here's an idea: Instead of minimum SoC at a charging stop, what about having the option to “arrive with enough SoC to get to a second charger if this one is broken”. I've seen this a lot: “I arrived to a charger and it didn't work, I barely had enough battery to get to a second one, or not at all “. You probably have seen it too. That's why I think this would be a cool option to plan charging stops. The idea would be for the minimum SoC to be determined by being able to reach a backup charger. I would consider a backup charger anything more than, say, 250-500m away from the first one, since it's somewhat common for hubs to show as multiple spots and the idea is to get to a different stop.

Rui Oliveira 9 days ago

1

Android auto showing price like Android app

It would bé great when selecting a charger point to have the price with the cards we own on Android auto. Just like we have it on the native app. Would be great directly when arriving at a station yo see directly from the car which card to choose to have the best price This is available in the app but not from Android auto. Thanks

Ludovic Sarakha 10 days ago

Open Location Code (aka "Plus Codes") as destination input

Open Location Codes (OLC, also branded as "Plus Codes") are an open method for compressing latitude/longitude coordinates into either 6 unambiguous alphanumeric characters + a nearby populated place, or 10 alphanumeric characters alone. (Technically, there are other character lengths that could be used, but those are the only ones seeing practical usage.) It's an open, royalty-free specification at https://github.com/google/open-location-code, with free reference implementations in many different languages. The main problem this would solve for me is copying specific locations from Google Maps into ABRP. Some of that difficulty is on Google, since they appear to have intentionally made it more difficult than necessary to copy lat/long coordinates in the decimal format ABRP will understand, while they've made it very easy to copy their Plus Codes. Nonetheless, while implementing OLC support would improve interoperability with Google, it wouldn't actually depend on Google—Google could totally drop all support for them and OL codes would continue to work. They don't depend on any Google servers, subscriptions, or other resources. They just need a generic geocoder to geocode the populated place part of the short codes, which ABRP already has. Another benefit is that OLC is a relatively easy and error-resistant way of passing specific locations (down to 3 meter precision) verbally, in handwriting, or through any random system for storing or sending text. You could use it to write down the location of a secret campsite in a national forest on a post-it and give it to your friend, for example, and be confident that they can easily type it into ABRP and find the right spot. The system avoids ambiguous characters like 1, I, and l to make these use cases work better. At this point, the skeptical will sometimes bring up a competing system and ask why implement OLC instead of that system. There's good answers to those questions on the specification’s Github. The short summary is: no other system is already built into the world's most popular navigation app, and some of those systems (e.g. what3words) are not open, imposing both licensing costs and restrictions on anyone who wants to implement them. Implementing OLC requires only ABRP's internal development costs, but no ongoing license costs, restrictions, or external dependencies.

Evan Derickson 13 days ago

Select specific charger providers only

I have a few accounts with charger providers, and ABRP returns me a route with providers I don’t know and I want to exclude. However, the exclude feature doesn’t have the “select all” and selecting one provider at a time is so tedious. I would like to simply “white list” the few providers I know and I have accounts. This is just impossible to have one account with every provider. Thanks

Francis Giraldeau 16 days ago

Option to avoid roads restricted for vehicles >3.5 tonnes (trailer / caravan users)

I’d like to suggest a small but very useful addition for EV drivers who regularly tow a trailer or caravan: In many European countries, certain roads, bridges, mountain passes, or city access roads are legally forbidden for vehicles with a total permitted gross weight over 3.5 tonnes. This restriction often applies when towing even a light-to-medium trailer, because the combination (towing vehicle + trailer) exceeds 3.5 t, even if the tow vehicle itself is registered <3.5 t. Suggested feature: Add a simple routing preference : "Avoid roads restricted for vehicles >3.5 t" When enabled, ABRP would use map data tags for weight-restricted ways (OpenStreetMap already contains quite good coverage with tags like maxweight, maxgvweight, hgv=no, motorcar=designated with weight conditions, etc.) and reroute accordingly — just like existing avoid options. This would make ABRP even more valuable for the people towing with EVs (ABRP is already a must-have for proper trip planning, especially with the customization of consumption). Many thanks for considering this !

Benjamin 16 days ago