[Q] Add car data from OBD2 to EVMap?

[PulsarFX]

With the latest upate you added a screen to show SOC, GOM and km/h. I think this must be provided by Android Auto or the car itself? For my car (Kia eNiro 2019) it only shows km/h. Is there a way to provide missing data via ... maybe by exposing a localhost web service from the app to feed this data in or via INTENTs or similar ways? Then this data could be used to calculate which chargers are in the available range of the car and then you click it and EVMap starts navigating you to this charger. Or it proposes a charger while navigating when the juice runs out ... hmm I think I am dreaming :D This would be the first non tesla app to do so. (No ABRP can't to that in AA or in an unobtrusive way while driving)

[johan12345]

Yes, it seems that most car manufacturers are very restrictive about what data their cars provide to Android Auto and thus to EVMap (see also https://issuetracker.google.com/issues/201790851). My Zoe also only reports the speed.

Adding data from other sources would definitely be possible, however I think I don't want to commit to implementing and maintaining those for all the different car models (through OBD2 or manufacturer's APIs). So it needs to be provided by other apps through some standardized interface.

The other question is: what exactly should be done with this kind of data? The current possibilities of 3rd party apps on AA are quite limited, for example we cannot access the current navigation route from another app (Google Maps) to search for chargers along that route. I think it's also not possible to show proactive notifications when the app is not currently running.

Showing all chargers within the range of the car would be possible, but that's not much different to showing all chargers sorted by distance from the current location, right? Especially as the lists in AA apps are also limited to few items right now.

[PulsarFX]

For ease of maintenance, you could provide a simple API like

{
    "soc": "12.3",
    "speed": "45.6",
    "range": "78"
}

whereas I am not sure about speed and range. That's probably useless. SOC is the one that counts.

With your information on AA restrictions, it sounds in deed rather useless. I don't understand why gmaps allows zooming, moving/swiping and other stuff and third party apps are not allowed to do so.

To be of any use in my idea, EVMap would have to do the navigation so you could easily add a charger as waypoint.

[Raudi1]

On the e-golf it's possible to get at least the soc via Android Auto and possibly more through this: https://github.com/jilleb/mqb-pm

[johan12345]

Interesting. Looks like this uses a VW-specific (probably other VW AG brands as well) extension protocol instead of the normal Android Auto protocol to send the car stats to the phone. The library https://github.com/martoreto/aauto-vex-base and the app https://github.com/martoreto/aauto-vex-vag seem to implement that protocol.

In principle that could be added to EVMap to display the data - but I have no VW AG car to test and there seems to be almost no documentation for these libraries or the protocol itself. :/ Also I don't know what would happen if multiple apps connect to this interface at the same time (e.g. EVMap and an official VW app).

[Raudi1]

I'm happy to help with testing and a bit of coding. Afaik there's no VW app which uses it. I also think the newer MEB cars don't have it anymore.

[johan12345]

Ah, hm, would be nice if it were also useful for the MEB cars... But if you can get it to work well with the e-Golf it would also be fine for me to add it to EVMap. In contrast to OBD adapters or car manufacturer's web APIs (as mentioned above) it would probably not require constant maintenance as the protocol won't change.

It's just that without the ability to test I can't do much more than copying the code from those repositories into EVMap - so you would need to do most of the coding yourself.

Also, I just noticed that the license of https://github.com/jilleb/mqb-pm is GPLv3, which isn't compatible with the more open license of EVMap - so code from that project cannot be used. The two underlying projects https://github.com/martoreto/aauto-vex-vag and https://github.com/martoreto/aauto-vex-base don't have a license file at all, so we would need to ask the author first before reusing his code.

[PulsarFX]

So what about a simpler approach for evmap: define some intents where evmap is listening for the required data values. Then, which ever App Broadcasts them is a valid data Provider. No hassle with extra Code in evmap, no compatibility issues ;-) The linked repos would Not work with my kia, but it would be easy to send the intents 😋

[johan12345]

@maulwuff Yeah, I think that's a good idea. Though maybe rather with a service that EVMap could attach to instead of Intents so that the data is only sent and updated when it's actually needed.

On the other hand, I still think that the vehicle data is not very useful right now in EVMap, as long as EVMap doesn't actually do the navigation itself (which I would hesitate to do, as I'll never be able to replicate all the sophisticated features of ABRP or Google Maps on my own) or has access to the currently running navigation route in Google Maps and can suggest chargers along the route (#143), maybe with an estimated SOC at each charger.

[fhvyhjriur]

There is AndrOBD https://f-droid.org/en/packages/com.fr3ts0n.ecu.gui.androbd/ This application have a wide compatibility with different cars and missing functionality can be implemented. It should be the most universal way to import data from OBD2 in EVMap without any OBD2 specific code. The code of both applications (EVMap and AndrOBD) can be modified by Pull requests. I also vote against implementing any OBD2 specific communication code in EVMap. Simple listening functionality instead is the best solution.

Any other OBD-applications that would like to provide the data to EVMap could then take a look at the AndrOBD code for a reference example.

[mhantsch]

As an alternative to messing with the OBD interface yourself:

For those car owners who already use EVNotify to collect their SOC data, the current SOC can be pulled via a simple REST call. The value you want to use is soc_display:

$ curl -s 'https://app.evnotify.de/soc?akey=abc123&token=abcdef1234567890' | jq
{
  "soc_display": 53,
  "soc_bms": 51.5,
  "last_soc": 1643393171
}
$ curl -s 'https://app.evnotify.de/extended?akey=abc123&token=abcdef1234567890' | jq
{
  "soh": 100,
  "charging": 0,
  "rapid_charge_port": 0,
  "normal_charge_port": 0,
  "slow_charge_port": null,
  "aux_battery_voltage": 12.7,
  "dc_battery_voltage": 350.2,
  "dc_battery_current": 0,
  "dc_battery_power": 0,
  "cumulative_energy_charged": 8713.5,
  "cumulative_energy_discharged": 8403.9,
  "battery_min_temperature": 9,
  "battery_max_temperature": 10,
  "battery_inlet_temperature": 9,
  "external_temperature": null,
  "odo": null,
  "last_extended": 1643393171
}

The user would have to configure their akey and token for the EVNotify integration on some settings page.

Just retrieving the SOC would already allow setting the "charge from" level for the chargeprice integration.

Alternatively it may be possible to pull the SOC data from ABRP, but I am not sure about their API.

[johan12345]

@mhantsch Thanks, that sounds like a simple solution, at least for SOC! I think I would accept a PR that adds this 🙂 Does EVNotify also give values like the estimated range or average consumption?

@fhvyhjriur Do you know if AndrOBD works well with EVs and provides the relevant data? In the screenshots provided I see only examples of internal combustion engine cars... I think EVNotify is more widely known in the EV community, and it's also open source.

But as stated above, I would first like us to think about and start implementing use cases where having car data in EVMap is actually useful before adding multiple additional ways to access the data from the car 😉 Setting "charge from" for Chargeprice is one possible use case, yes.