Support of ISO 15118 to read car SOC

[abstractionnl]

At some public chargers (particularly ones by Alfen), the car can communicate with the charging station to give details about it's SOC, this is shown on the charger display. Looking around the internet this is done with the ISO 15118 standard. Having the SOC would allow some new smart additions:

• Stop charging when battery reaches a certain % (to prevent battery degradation)
• Switch to solar mode when battery reaches a certain % (always have enough available for small rides and only trickle in more on solar when available)
• Charge just in time by setting a goal percentage to be available at a certain date/time, and wait for solar in the meantime.

[mstegen]

I just heard about this a few days ago. These chargers talk to the car behaving like a DC charger, over ISO 15118 you can indeed request the SOC and other parameters of the EV.
After receiving this information they then basically tell the EV, oh sorry i'm not capable of delivering DC, and start charging in normal AC mode.
If you stop the charge at regular intervals, and then start the sequence again, you can predict when the EV is fully charged.

The SmartEVSE v3 does not have a ISO 15118 modem. So its not possible to request this information.

[abstractionnl]

It looks like it is using powerline communication, over the CP wire. An external modem would be needed, but I see none available over the shelf.

[fluppie]

See this paper: https://ltu.diva-portal.org/smash/get/diva2:1546405/FULLTEXT01.pdf
Or with this Qualcomm chip: https://www.qualcomm.com/products/application/automotive/auto-connectivity/qca7006aq

A workaround for the current SmartEVSE is integration with https://evcc.io to get SoC via BMW Connected Drive, MyAudi, Volvo on Call etc.
https://docs.evcc.io/docs/devices/vehicles

[martijndierckx]

SmartEVSE v4? :-)

Just noticed the same at a Tesla Supercharger, charging my non-tesla. Also wondering: “If Tesla can read that data, then SmartEVSE should also be able to do it … right?”

[mstegen]

Ha!
I'll see if i can order some pre-made modules with a Qualcomm chip. I found some from 8devices and chargebyte/intech.

[Fixh1]

I added an MQTT task to the SmartEVSE (and installed Mosquitto, Node Red etc) And via Node Red I can get all information from my Zoë, including the SOC. So I can forward that information to the SmartEVSE. Not using it yet, but the option is there.
I only have a problem with the disconnecting Wifi :-(.

[fluppie]

Yeah sure, but that's not always working well. Like BMW's connected drive that from time to time doesn't work for 1-2 days. The advantage of the qualcomm chip is it can always read SoC. Ideal for cars in an underground parking lot without wifi.

[martijndierckx]

I noticed the same with Porsche's service. Not very reliable, plus on many occasions with delays.
So a direct integration would be much much better.

[dingo35]

Ha!
I'll see if i can order some pre-made modules with a Qualcomm chip. I found some from 8devices and chargebyte/intech.

@mstegen Not sure what the status is, but I would be happy to help develop the firmware adaptions for this; I am one of the developers of the serkri distribution, but it would make no sense doing that work twice....

[fluppie]

@mstegen are you (still) looking into this for v4?

[mstegen]

Thanks for the reminder, just ordered some red/yellow beet-e modules to play with.

[martijndierckx]

@mstegen any luck on testing the beet-e?

[mstegen]

I received the modules (Red beet/ Yellow beet and Red beet carrier board), but had no time yet to look into it.

[arpiecodes]

I am also actively looking for something that could 1. provide me with a SoC on the car and 2. authenticate the car without having to use a RFID card/manual action. It seems ISO15118 is the way to go forward.

I also stumbled across the web already in my quest. One thing that was very enlightening was this; https://github.com/uhi22/pyPLC#example-flow. I also came across Python libraries supporting both SLAC (link negotiation) and the actual ISO15118 communications. It all looks pretty expansive, but very cool! I mean come on, talking over IP with your car, that's awesome!

I am not sure if implementation directly inside SmartEVSE is a good idea, though. It would most likely be possible, but full integration (including the Plug&Charge stuff) would require quite a big list of 'extras', like TLS, full IPv6 stack, dynamically spawning UDP+TCP servers for communication, etc. It sounds like a lot to handle for the/a ESP32.

With that in mind, I'd like to try to add ISO15118 through a separate component (e.g. Raspberry Pi) that could act as a charge-controller-controller, handling the actual powerline communication with the car and 'work together' with the SmartEVSE to control the contactor, as the basic communication over the CP/PE lines (monitoring the EVSE 'states') is still required as part of that communication flow/charging process. I was thinking of using MQTT for this, but I guess a simple/small API or even ModBus would work as well.

I do hope the control signalling on the CP line (e.g. load balancing) and the PLC communication are not mutually exclusive, and can be combined; else above may not work out the way I am envisioning.. But we can at least try!

I have sent a mail to the people over at CODICO to find out if that carrier board they have listed on their site containing the RED BEET (https://www.codico.com/de/red-carrier-board-e-1-1-evse) would be plug&play and allow me to get a head start. If it's what I need to get going quickly, I'll order one and see what I can find out.

[ArendJanKramer]

@arpiecodes I'm pretty interested in what CODICO has to say. Thanks for the link though, I hadn't spot the carrier boards before.
I ordered one, will update you all. Like you said, pretty awesome to talk over IP with the car.
I have also seen this one: https://www.codico.com/en/powerline-gp-evse-din-rail-modul-version-1-1
But holy smokes, that's not cheap for DIY.

My first plan is to setup a Raspberry PI with the board, and see if we can get some form of communication. Things I'm interested in are:

• First of learning more about this topic, I'm a blank slate
• Read car information, perhaps useful for authorization purposes
• Read SoC and other information.

I also looked at the carrier board with a white beet instead, which has an ST32 microcontroller. However, if I understood correctly the sample code needs to be licensed, and I couldn't find sample code online.
Otherwise, I'd like to have experimented with that instead.

Once this all works, we could make a PCB with small microcontroller and a RED beet that acts as a modbus slave for SmartEVSE to supply information about car SoC. (or SmartEVSE v4)

One thing I'm interested in to learn is how we deal with CP signal, as it is currently controlled by SmartEVSE, while pyPLC mentions that the PWM needs to be set to 5% duty cycle for a while to setup digital communication. Well, we'll see once the board arrives and things need to be wired. I usually learn these things from doing it wrong initially.