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.

[arpiecodes]

@ArendJanKramer good to hear you took the jump and simply bought one. Maybe I should do the same. I have no reaction from Werner from CODICO yet. I am unsure if they even respond to hobby users like me. :-) If I hear anything back, will let you know.

Your plan sounds nice. However, as far as I understood the beet modules only contain the components to establish the physical connection/do signal conversion. The QCA7xxx chip on-board is connected through SPI to something else. And on this something else you will have to run the full networking stack (IPv6, SLAC, UDP/TCP servers, etc.). I don't think this will be possible on a PIC as it's all pretty high level stuff. Maybe you could get it to work reliably on a dedicated ESP32 though. AFAIK it has everything on-board to do these things.

Using modbus to talk with the EVSE is a nice solution. Do have to consider the SmartEVSE will remain master in this case. So it will continually have to poll the module in such case, while also making sure your module gets the CP line state updated every now and then.

[dingo35]

Since the SmartEVSE already controls the CP line, and already has a full tcp server running (e.g. serkri distribution), IMHO it would make most sense to connect the modem through the existing SPI interface on the SmartEVSE board, and do all low-level communication on the ESP32; it might be necessary to offload the tls and complicated encryption/decryption routines that are involved with ISO15118 to a raspberry pi, but doing ipv6 is already possible since 2019 so that shouldnt be a problem... Also if the encryption/decryption logic is in the hardware of the modem (which seems to be the case for some of the beet-kits) you wouldnt need to offload at all...

[arpiecodes]

Running the serkri distribution sometimes already shows slowdowns when interacting with it through REST (at least, in my case) while not doing much with it, really. I'd not like my charge controller to end up being busy with a lot of extra stuff jammed into it to the extend of that potentially causing issues with the core functionality/compromising it. It would also raise complexity even further.

Besides, we would still need a way to react to stuff like 'identifying' the car, send through SoC and be able to control it from (for example) HA. The official repo doesn't support this as of this moment either.

I'd much rather see something like this added to Sensorbox v3 (and have that assume the master modbus device role, also run the REST API and MQTT client for example) vs. trying to cram it all into one device.

[dingo35]

Well lets agree to disagree on that.

Mind you that having Sensorbox V3 taking over the modbus master role is a really bad idea, since the Sensorbox is optionally. There are a lot of alternatives out there that can get the Mains currents into the SmartEVSE.

[arpiecodes]

Agreed with disagreeing. :-)

I was just referring to the Sensorbox as an example. I would also not mind it becoming a totally separate module.

In the near future not only your car will be talking over Homeplug GreenPHY; it will most probably become the basis for smart grid communication. So it can potentially also talk with (for example) solar inverters and other appliances like heatpumps, etc. Would be too bad if the module could not support such nice use cases. While I do agree that's out of scope (like you said with the alternatives that are there for main metering), why not consider it from the start? It would give so much more flexibility vs. making it a single-purpose solution.

I also don't see why having Sensorbox as the modbus master would be such a bad idea. It has been discussed here multiple times already. Nobody loses anything w/regards to functionality vs. current situation if you make it opt-in. If done in a correct way, would only mean the SmartEVSE can act as a Modbus slave which opens up a whole lot of extra possibilities in different set-ups as well. And would allow the SmartEVSE just to focus on that one thing it does best; be a charge controller without any added fuss.

Now, creating a whole different version of SmartEVSE as a whole sounds like complete overkill and would only make firmware management/updates more difficult, require everyone to replace their existing units, etc.

[dingo35]

You will always need the possibility to have SmartEVSE working as modbus master, so having it also making it work as a slave increases complexity (both in code and in configuration). Also it goes against the modbus architecture; all communication has to be initiated by the master by design. Almost all use cases are controllers (master) reading data from sensors (as slaves).

Id rather solve the structural problem of modbus only allowing one master by having the SmartEVSE functioning as a flexible configurable gateway from modbus to REST and/or MQTT, so it can interface to HomeAssistant or other more high-level domotica systems.

Just my 2 cents...

[arpiecodes]

Id rather solve the structural problem of modbus only allowing one master by having the SmartEVSE functioning as a flexible configurable gateway from modbus to REST and/or MQTT, so it can interface to HomeAssistant or other more high-level domotica systems.

Which is in itself definitely not a bad idea/solution. I definitely support the motion to add more connectivity (e.g. REST API/MQTT, etc) to the SmartEVSE.

I just don't agree with the part where we'd add even more responsibilities/logic to the SmartEVSE's core code; including a whole new networking stack required to make GreenPHY work.

[arpiecodes]

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

Hey @ArendJanKramer, were you able to try it out yet? I actually never heard back from CODICO and considering buying the carrier board anyways. Thought it'd be good to reach out to check how you are fairing with it first.

[ArendJanKramer]

@arpiecodes I received the board. Wasn't exactly easy, they asked a lot of questions before they sent one over. Quality is really good, I'm impressed. Still working on getting a Raspberry PI, so I can actually start developing with it.

[fluppie]

@ArendJanKramer Since I'm fan of having this functionality developed, could you work with a Raspberry Pi Zero 2W? Or do you need a 3B or 4? I can sell you one ( for normal MSRP prices :) ) since I migrated most of my stuff to a LENOVO ThinkCentre M73 (see eBay, you can get them at 75-125 euros) with Proxmox VE on it. I can easily run 4-5 VM's with Debian etc on these machines with an i7 and 8GB of RAM.

[ArendJanKramer]

@fluppie Thanks for the offer, I think I might be able to get one freed up in my setup. The Lenovo is actually a pretty good idea though lol.

Another question to the experts here is about zero-crossing and connecting the mains. See picture of board without the lid:

You see "YT-35636 (292877)" modules used for [AC_L and AC_N] and [CP + PE]. The CP + PE pair makes sense for me, but I'm not so familiar for AC lines, is it needed for basic communication? Because in fact, DC chargers are not using these pins am I right?

1 - https://www.codico.com/en/mpattachment/file/download/id/831/ section 5: "Zero-cross detection has to be used in all applications with communication over AC mains or when module's power supply is powers from AC mains. Two or more HomePlug AV/GreenPHY logical networks can only coexist when zero-cross detection circuit is implemented.". In other words, not needed if only one car in the network right? 2 - The dev board has the proposed schematic in place though. Do I need it? Which phase do I connect here? Does it need to be the same phase as AC_L? 3 - According to components that I see, I can just connect SmartEVSE and this board to the same CP signal. I didn't do the math, but since only high frequent components would pass the capacitor on the dev board, the smartevse would still be able to see proper line voltages to negotiate charging with car. Likewise with duty cycle signal. Anyways, the worst that can happen is not a lot so I'll just give it a try I guess.

Again, I'm completely new to this ISO, but I'll learn as we go. "what can possibly go wrong"

[fluppie]

I would also think CP + PE is the way to go. Since the AC lines are disconnected by the contactor before charging. Regarding connecting the CP in parallel, I think that's maybe a question for @mstegen ? Maybe also check this document: https://github.com/uhi22/pyPLC/blob/master/doc/EvseMode.md

The CP of the vehicle is connected to the hot side of the homeplug modem and the hot side of the arduino-charging-logic. The PP of the car is connected to PE via 1k5 (inside the plug).

I also saw the earlier posted link to https://github.com/uhi22/pyPLC#example-flow which looks like interesting information

[ArendJanKramer]

@fluppie Great resources, thanks for them. That seems hopeful.

I also read this thesis: https://ltu.diva-portal.org/smash/get/diva2:1546405/FULLTEXT01.pdf Which is great for starters, but lacks some details, specifically on the AC side.

Regarding the 5% duty cycle to initiate communication, I see this in the code: https://github.com/SmartEVSE/SmartEVSE-3/blob/main/SmartEVSE-3/src/evse.cpp#L557 When idle, there's no PWM signal. Perhaps by setting that to 5% duty cycle gets things running just as a test.

Maybe @mstegen can indeed confirm if it is safe to connect the dev board in parallel on the CP signal.

[mstegen]

Great that you received your dev board. I think you can connect the AC_L and AC_N to L and N of the SmartEVSE. As the homeplug data is injected on the CP signal, you can connect the CP directly to the CP of the controller. Ideally the EVSE should have a filter to suppress the homeplug HF signal. (it's described in the ISO-15118_3 standard)

If you kill it somehow, let me know, and i'll replace it.

Ref the 5% PWM, this is required to start digital communication with the EV. There is no harm in setting PWM to 5%, If the EV does not support it, it will reject it. It has been part of the old J1772 standard, so even cars from 15+ years old should be able to handle it.

[ArendJanKramer]

@mstegen Thank you for your suggestions and kind offer. Let's hope nothing breaks.

Good news so far, the PI and the Red Beet are talking:

I'll see if I can mount the components to some sort of board, so it's a bit less fragile.

Next is modifying the firmware of SmartEVSE and then wiring. Fingers crossed

[ArendJanKramer]

Ok, here's what I got so far.

Modified firmware. Apparently, there's a few seconds delay before state B is switched in SmartEVSE. I abused this by setting the duty cycle to 5% over there, so the car has 5 seconds to enable communications.

I also did some janky wiring, it's "temporary" as we engineers tend to call bad work.

The funny thing is, it seems to kinda work. When I run "evse" command, part of open-plc-utils I see slac messages. Not exactly the right thing perhaps, but some things are going on:

These messages definitely stop when I stop the charging.

But next, HOW THE HELL DOES THIS WORK? I can't find a list of commands or parameters to send / receive so we can find SoC and other stuff. I'm a bit clueless, did some googling but I'm missing the right words apparently.

[arpiecodes]

@ArendJanKramer Nice progress! Great to see the absolute 'basic' communication is established.

For me, the following really helped with getting a general understanding on what happens in the digital communication; https://github.com/uhi22/pyPLC#example-flow. If I interpret your results so far, I'd say the evse (charger) has to send SLAC_PARAM.CNF. It is actually a VERY expansive process it has to go through.

It seems someone has managed to (sort of) start a session with that pyPLC stuff here; https://openinverter.org/forum/viewtopic.php?p=56188&sid=9579fd29268d0e332c81ed528f59f09b#p56188. Maybe it helps. Some interesting stuff in that topic.

One such things is a project that aims to get everything running on a ESP32; https://github.com/uhi22/ccs32. But they seem to be working on the PEV side of things, not the EVSE side (aka; car side, not charge controller side). But requirements are sort of the same, just inverted logic.

[fluppie]

I've came across these two repo's who contain a lot of info, especially the one from EDF seems to have a GUI. https://github.com/EDF-Lab/eVDriveFlow

and also this one: https://github.com/SwitchEV/josev

[dingo35]

Are you sure your ipv6 stack is in order on your Pi? In that openinverter topic https://openinverter.org/forum/viewtopic.php?t=2262&start=100 they have the same problem, and they attribute it to the software using old-school ifconfig instead of ip route. So it might be that your pi does not have a link-local ipv6 address which prevents the communication going forward...

[ArendJanKramer]

@dingo35 I guess it does? Not the expert, but good suggestion. I got iso15118 python running (from SwitchEV), here's what we see:

And this multicast ip you see at the bottom does ping:

Which is in fact my eth1 (SPI Red Beet) ipv6 address.

Next to try is pyPLC from fluppie, but since I installed minimal Raspbian without X, there's no window server to run tkinter (which it the code uses all over the place). Will install window server / strip out tkinter out of the source to get things rolling. And if not, I'll try to understand the flow more to see if we can get at least 1 step further than I have now, which enables the path for the subsequent steps I guess.

[mstegen]

Looks like EVerest has everything figured out already. Their software stack is fully open source, and very advanced. https://github.com/EVerest https://everest.github.io/nightly/

See also https://www.youtube.com/watch?v=OJ6kjHRPkyY

[ArendJanKramer]

@mstegen I've seen that one, but unfortunately it's quite hard to build. It's basically a mix of all libraries mentioned out here, it pulls in Steve, iso5118 lib, etc. Will definitely give it another try, but for now I got stuck at the lack of Rust compiler and clang12 installation. Went all the way through the workspace process, but it went in too many errors for now. Once I have some of the individual components working, I'll might give it a bit more time.

However, I got 1 step further with pyPLC.

Modified code quite a bit to sniff on eth1, and run without GUI. In the end it seems to take steps until Checkpoint102.

Now, the car is 100% charged and car doesn't seem to execute charging procedures anymore.

Not exactly sure what ConnectionLevel means in this context, need to read more in the code to learn I guess.

Anyways, enough for today. Tomorrow I'll play again and see if we can get at least one step further. Perhaps I might also connect a scope to verify there's actually the signals on the CP that I expect.

[arpiecodes]

I think you are running in PEV mode, which is actually the vehicle side. You should run in EVSE mode for it to act like a charge controller.

[ArendJanKramer]

@arpiecodes I think there are some things mixed up here, in the debugger I clearly see the evse sim started. Both ini file an py file are changed to start evse, but you are right in that the events are reversed. I’ll dig deeper tomorrow. It might have been a bit too long day for me to notice it’s still wrong around. Filename and print at top are static btw, I will update them as well.

[dingo35]

@ArendJanKramer , on a raspberrypi 4, they forgot the dependency on the rust compiler; you need to do a apt install rustc . I did not notice missing dependencies with clang12...

[ArendJanKramer]

First things first, check if what I thought I made actually was that I made. So I hooked up my scope to the CP pin. Guess what, not 5% duty cycle but 100%; whoops. As a quick check commented out all calls in EVSE code and hard-coded 5% in.

Immediately pyPLC saw traffic coming in on server at port 15118:

On the scope, the duty cycle is near 5% (ignore probe settings and voltages, lazy is my second name):

Seems pretty nice to me, very cool to see these messages.

Turns out my modified code was actually doing what I thought it did. Thanks for letting me doubt myself @arpiecodes, actually learned some new things while stepping through the code again. You made me find a hidden test in pyPlcTcpSocket.py, which is actually pretty nice to know about.

Sorry for my spam again, but I'm glad to be 1 step closer. Next is to making sure I can still charge, while also having 5% when I need to set up communication. Will need to familiarize myself with the SmartEVSE code before I can add some REST calls to post the SoC and request 5% PWM.

[fluppie]

Cool! I see 3 SoC's, FullSOC, BulkSOC,EVRESSSOC 94, 84 and 56 is by accident any of those 3 numbers the right SoC? :).

[arpiecodes]

@ArendJanKramer That is some amazing progress!

I am curious whether the car would still allow digital communication/give updates on SOC while charging through the 'old' method (e.g. SmartEVSE controlling the charge session instead of through PLC). That would be ideal.

Else, it'd mean we'd have to completely implement charge control through EXI/PLC. Which would most probably almost completely mean rewriting something akin to the core logic in SmartEVSE (and also making the logic kind of redundant there).

[ArendJanKramer]

@fluppie Those seem to be the right numbers, which make me quite happy. @arpiecodes This is what I'm working on. Made some buttons in the SmartEVSE page to overrule PWM so I can set up communication and then resume normal charging. The code is new to me, and I have never used the debugger functions before, so need to learn a bit. I will update you once I know a bit more.

[ArendJanKramer]

@arpiecodes I'm afraid the answer is no, at least for my car. I just played for a short bit with SiwtchEV's josev, and got it working.

The steps I took:

• Edit .env in iso15118 to match setup.
• Run iso15118/secc/main.py. You'll see the tcp server waiting for communication from car
• Now, you need slac to initiate communication.
• Edit pyslac/examples/cs_configuration.json, to only have 1 evse
• Set PWM to 0% in EVSE, I made some buttons to help me with that
• Run pyslac/examples/single_slac_session.py
• Set PWM to 5%, immediately you should see pyslac negotiating with car
• Few seconds later, you'll see iso15118 talking with the car Much more mature than pyPLC. Perhaps I didn't take the best route in hind sight, but I learnt a lot which is something I don't regret.

SmartEVSE side PWM control

I abstracted the CP signal calls into a function (SetPWM) and I have a global variable with OverridePWM and its value. Does the job for me. If I want to set up a new connection, click zero and then few seconds later at 5. 25% and 100% are unnecessary in hindsight. Reset removes override so I can charge normally.

Limitation of car I found a few things. First, my car only supports DIN_SPEC_70121. Unfortunately, this only supports the transfer mode of DC:

Attempt 1: Disable DIN_SPEC_70121 from SECC side. Just remove this option from the list of protocols communicated with car, so an alternative is hopefully chosen. Nope, car responds it can't do that, 100% expected of course, but can't say I haven't tried.

Attempt 2: Ignore spec, hard code AC response in DIN_SPEC_70121 Basically commenting out the check in fist image.

Car rejects this, and says it's not compatible with my charger.

Conclusion My car is not suitable for communication + charging via AC simultaneously, since it only supports the DIN spec, which only support transfer mode of DC. Other cars do support newer protocols. Is it a failure for me? Absolutely not, because I can extract SoC before charging, and I know the battery capacity. By using the EV meter, I know exactly how much energy has been gone into the car, so I can compute the new SoC quite reliable I think.

Next steps: Add some endpoint and rest callbacks to SmartEVSE, so when the cable gets plugged in, the digital communication is initialized by the PI + Modem. Then, I can just post the SoC values to SmartEVSE and we can do the energy counting from there, if EV meter is connected. A more mature approach would be to solve this over Modbus and make the iso15118 more self contained. It depends a bit on where we want to take this feature.

[arpiecodes]

@ArendJanKramer sad to read about those limitations. But as you already found; there is a workaround that could definitely work for your use-case.

I suppose I also should order a board soon. I am eager to try it out on my Polestar 2, which IIRC does not really have support for Charge 'n Go (which is actually build upon the PLC stuff) so my mileage will probably also vary. But if I can get a SOC and have the car make itself known, then yes, it would also be a full win for me.

What car did you test it with?

[ArendJanKramer]

@arpiecodes My car is an Ioniq electric 28kWh, built in late 2018. I'm eager to see what your results will be. It's a pity I don't have a lot of family / friends with that own an electric car, because I'd like to test with a more modern car.

Btw, please reach out to me via tweakers @topaj via PB if you need a board.

[dingo35]

@ArendJanKramer If you have a diff for me, I can integrate it in the github repo so it will save others the work of fiddling out the 5% pwm stuff...

[dingo35]

I ordered the poor man's hardware... (Picture of TP LINK homeplug deleted because it had some pw info on it)

....but now awaiting firmware update of my car, in week 20.

[ArendJanKramer]

@ArendJanKramer If you have a diff for me, I can integrate it in the github repo so it will save others the work of fiddling out the 5% pwm stuff...

https://github.com/serkri/SmartEVSE-3/pull/143