Show a list of nearby chargers with the lowest charging cost

[cremor]

It would be great if EVMap could show a list of nearby chargers that also shows the charging cost. That list should find nearby chargers and get the cheapest charging tariff for each charger.
For price calculation the already existing charging cost settings should be used. Tariffs should be limited to those configured as owned by the user ("My charging plans").

Possible settings for that list:

• Search radius
• Selection of a filter (same filters as on the map)
• Sort order (either by price or by distance)

I think that list should show 5-10 chargers. Or maybe also make that available as a setting.

This would require a new page, similar to the list of favorites, but with additional information fields for:

• Price
• Charging tariff
• Charging duration and/or average charging power

Optional enhancements to this feature:

• Maybe the already existing list of nearby chargers on the home screen of Android Auto/Automotive could be extended with the price information? At least with the charging price, if there is not enough space for everything. (But I think there should still be a seperate page on Android Auto/Automotive with the full list of informations, just like on the phone.)
• This could optionally be combined with Android Auto: Allow to search for chargers along the route, near the destination, or along the driving direction #143 to show the cheapest chargers along the route or at the destination.

[johan12345]

The Chargeprice API currently only allows us to get prices for one charger at a time. This means searching for the cheapest chargers in a given area would require a lot of parallel requests, which would make it quite slow.

Also, as our current agreement with Chargeprice on the pricing of their API has a certain limit on the number of requests per month, I would rather avoid a feature like this which has the potential to increase the request volume drastically.

So, such a feature would first need to be implemented by Chargeprice natively (e.g. an API endpoint which takes a list of charger IDs and a list of plans and returns the cheapest rate at each charger) before we can add it to EVMap. @hoenic07, have you already thought about adding something like this?

[comradekingu]

I think listing chargers in terms of size makes more sense.
A venn-diagram is the easiest, but not the best.

If the radius to the cheapest charger is always shown as a direct line to ones position, it can be selected easily and then
provide a route.
Cheaper chargers are shown within what is cost-effective distance, and those more expensive discarded.
In my head it is then easier to gauge how much more costly it is to use a charger that is closer.

The driving one does to get to where a more costly distance radius to a charging point starts is effectively distance
the user has to incur.
It could thus also be that the distance radius points in the opposite direction from the user.

Since it is easy to see what the closest points are, sorting them optically based on how effectively far away the start of their radius line is makes sense?

A list of only sensible chargers under the given conditions could be preloaded in the app maybe?
For actual distance driven it would have to take into account one-way streets, bodies of water and other barriers.

[cremor]

@comradekingu TBH I have a hard time figuring out what exactly you want added to my feature request.

• What do you mean with "listing chargers in terms of size"? What is the "size" of a charger?
• Is the distance to a charger really that important in a list of "nearby" chargers? Unless the radius setting allows very large values (which I doubt, because of the Chargeprice API limits) the distance difference will be very small.
• Ordering chargers by distance (instead of by price) might be a good option. But ordering by price should also be available. I've added this to the issue description.
• What do you mean by preloading chargers? How should they be preloaded, and how does this help?
• I don't think calculating the actual driving distance to a charger is in scope of EVMap. That whould require routing functionality.

[MPX10L]

How often do these prices change? I think for me it would be ok to use slightly older data.

Would it be viable to have the app report the price back to an EVMap-server, each time someone clicks the current price comparison button?
This would build a slightly out-of-date version of the Chargeprice-API database and calculate an average price for each charger and tarif.
The "Find cheapest nearby charger"-function could download this list (when opened the first time per day) and show the list of chargers that are typically the cheapest.
One can then decide to click on the charger and get the current price the old way.

This might even reduce API calls as someone like me would not click on the price button for all five chargers around me. (And then click them again, because I forgot how much the first one was costing .... I hope the app does some local caching.)
Actually, it might also be enough to have the best price displayed on the map, only for those chargers where the user did check the price.

Sorry if that suggestion about an EVMap-server is out of scope, I am not familiar with how the app actually works. I was simply using it and thought "Hey, wouldn't it be great to be able to list the chargers by price?"

Btw, I think it is the best app for finding a charger that I have found and tried so far. :)

[johan12345]

Would it be viable to have the app report the price back to an EVMap-server, each time someone clicks the current price comparison button?

The prices can depend on a lot of parameters, such as the selected vehicle (charging curve), connector, state of charge (e.g. 20-80%), time of day, etc., so caching the responses for a specific set of parameters (locally or on a server) wouldn't help much.

I already asked the Chargeprice folks a whether they could provide details about all price components + charging curve data in their API response - because if we would cache these, the price could be calculated locally even when the parameters change. But they didn't seem interested in that (fair enough, this data is their USP and they don't want to hand it out too easily).

[MPX10L]

What? It varies by SoC and charge curve?
Is that even legal? I mean, that makes pretty much impossible to know how much it will cost in advance (without having to use a 3rd party service). I am in the privileged position that allows me to not to care too much, so I never tried to calculate it in advance but others might need to know exactly.
Sorry, had I known this, I would not have written the previous post. (Tbh I find this slightly ridiculous.)

[johan12345]

Of course, the total price of the charging session (which is what Chargeprice calculates) varies by how much energy you want to charge, which is determined by the starting and ending SoC that you input into the app.

In case the pricing is not just per kWh but also has a time-based component or a blocking fee (= time-based component that only applies after charging for a certain duration), the cost of course also depends on the charging curve, because that determines how long charging will take.

[MPX10L]

Oh, sorry, I assumed that Chargeprice only shows the current price per kWh. I thought you were saying that this CURRENT price changes based on what kind of car charges.
I do understand that the total cost depends on the total delivered energy, which depends on the SoC, charge curve and charge duration.
Sorry ... looks like I had a very weird knot in my brain.

To maybe save it a little bit:
So, Chargeprice reports the average price per kWh for a specific amount of energy and approximate duration.
Sure, the charging curve is an unknown, but I think giving an estimate based on these averages might still be enough to help indicate which charger tends to be cheaper, no?

That would still be helpful information to have on the map, when one tries to quickly decide which charger to drive to.

But I do understand that this wouldn't be fully reliable and therefor maybe should not be implemented.
Personally, I think it would be good enough to get the correct advice more often than not.