Support of ISO 15118 to read car SOC

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.

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.

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.

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

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

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

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 :-(.

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.

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.

8devices

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

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

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

@mstegen any luck on testing the beet-e?

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

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, IPv6 support, UDP, TCP servers, etc. It sounds like a lot to handle for the ESP32 currently used.
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 (figure out the EVSE 'states') is still required.
I hope the control signalling on the CP line (e.g. load balancing) and the PLC communication are not xor, and can be combined. Else above may not work out.. 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.

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

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

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.

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.

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.

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

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

 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.

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

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

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

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

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

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.

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.

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.

@ArendJanKramer Nice progress! Great to see the 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.

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

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

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

Looks like EVerest has everything figured out already. Their software stack is fully open source, and very advanced.
https://github.com/EVerest
See also https://www.youtube.com/watch?v=OJ6kjHRPkyY

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

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.

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

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

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.

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

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

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

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

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.

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

I ordered the poor man's hardware...

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

@ArendJanKramer thx for the PR, working on it, I take the liberty of taking out the 25% and 100% pwm buttons since you say they turn out to be of no use.
Also question, I want to resolve this compiler warning but don't want to guess:
src/evse.cpp:2040:70: warning: suggest parentheses around '&&' within '||' [-Wparentheses]
if ((State == STATE_B) || (State == STATE_C) && !CPDutyOverride) SetCurrent(Balanced[0]); // set PWM output for Master
What would be the correct placement of the parentheses?

Notice that when with Arend Jan's code you set the PWM to 0%, the pilot line is no longer kept at 12V and the SmartEVSE will report a vehicle is connected, even if it is not :-)

@dingo35
Normally, the PWM is updated when in State B or C; so load balancing is updated every cycle.
For override we ignore it, so this would be correct:
if ((State == STATE_B || State == STATE_C) && !CPDutyOverride) SetCurrent(Balanced[0]);

Notice that when with Arend Jan's code you set the PWM to 0%, the pilot line is no longer kept at 12V and the SmartEVSE will report a vehicle is connected, even if it is not :-)
Nice find, never tried without a car connected.

Ok if you check out the current master of serkri distribution you will find Arend Jan's code in there, with a few slight modifications:

introduced new setting (through LCD screen) Modem that defaults to Not Present but can be set to Experiment
the new stuff is hidden for Modem == Not Present users
moved /pwm endpoint to /modem/pwm so we can expand experiments;
moved pwm json element to evse subdivision
some small layout stuff

@ArendJanKramer I tested, but since you are the only one on the planet currently being able to test this fully.... please let me know if it tests ok so I can put it in the next release.

@dingo35 It seems good, but my car is 100% charged. Will tests again tomorrow with less charge, can always make a new PR with fixes if needed.

But the rest seems good, it applies the right PWM signals it seems.
Thanks for your work, feel free to put in your release.

@ArendJanKramer did you play some more with the RED beet module :-)? Or I should also buy a module ( https://www.codico.com/de/red-carrier-board-h-1-1 ) and provide remote access?
I have a 2022 BMW iX3, so I don't know if they support 15118 AC "Plug & Charge". I do have the latest 03/2023.45 iDrive software.

@ArendJanKramer Good idea's! I would definitely be in the market for an easy to use solution without spending 100+ euro's.
How about an alternative solution to the above list; a solution that would act more like a transparent 'bridge' between ethernet and the GreenPHY network? A bit like the powerline adapters that are being modded. Maybe slap on a modbus/serial connection to it as well. In such case, an ESP32 would probably do. A Raspberry Pi would also do the job, but requiring one for it to function would increase the cost dramatically and makes the solution very specific.
I don't think a full linux SOC would be required. Most people using SmartEVSE right now already use e.g. HA or some other platform with a Linux OS. ESP32 would be a cheap option, lots of I/O options for future expansion and in theory would also easily support bridging between the GreenPHY network and any other ethernet network.

@ArendJanKramer Good idea's! I would definitely be in the market for an easy to use solution without spending 100+ euro's.
How about an alternative solution to the above list; a solution that would act more like a transparent 'bridge' between ethernet and the GreenPHY network? A bit like the powerline adapters that are being modded. Maybe slap on a modbus/serial connection to it as well. In such case, an ESP32 would probably do. A Raspberry Pi would also do the job, but requiring one for it to function would increase the cost dramatically and makes the solution very specific.
I don't think a full linux SOC would be required. Most people using SmartEVSE right now already use e.g. HA or some other platform with a Linux OS. ESP32 would be a cheap option, lots of I/O options for future expansion and in theory would also easily support bridging between the GreenPHY network and any other ethernet network.
Maybe we should explore options to 'team up' with uhi22? His project CCS32 seems to be very alike in goals; https://github.com/uhi22/ccs32. It just misses a good hardware platform to bring it all together, without a hacked PLC modem.

It depends, I'd rather make something and be able to completely forget about it, so I don't have to maintain it.
On the other hand, if there's almost no demand for this feature, it makes more sense to duct-tape something together with dev-boards + Raspberry's or Powerline adapters.
Why I mentioned the Linux Soc is because Linux kernel is shipped with QCA7000 series driver and plc utils of Qualcomm/Atheros work straight out of the box,cli utility's just so. You can also run existing Python suites like Josev, EVErest and steve. If you take an ESP32 we'd need to rely heavily on @uhi22 his work and expand that (for example: AC charging).
I believe regardless of the solution, we need hardware connection between SmartEVSE and module, because SmartEVSE needs to automatically trigger 5% cycle and work with "modem module" to initiate and extract information, issue retries and then start charging. Depending on negotiated protocol SoC can be frequently updated, or it needs to be re-computed based on EVMeter. Using wifi for that feels a bit too fragile, and the last thing I want is a charger that doesn't charge.

I agree we need a hard wired connection between modem and SmartEVSE; I see the following possibilities:
-modbus
pro: no soldering, easy access
pro: software library already in use
con: a connection can only be initiated by the master device (the SmartEVSE). I doubt whether the complex communication protocol that has to be followed can be implemented without the modem being able to initiate communication
-uarts:
uart0=debug/program port
uart1= modbus port
uart2: pins seem to be in use for switch and actuator drive
-SPI:
pro: simple and efficient
pro: QCA7000 series support SPI
con: soldering required; is it possible to add another SPI device?
-I2C:
?
-wifi
pro: no soldering required
con: wireless, would only be temporary solution for experiments
-bluetooth
pro: no soldering required
con: wireless, would only be temporary solution for experiments
Perhaps @mstegen could shed some light on this?

Hi, thanks for tagging me, I was indeed not aware of this project. Glad to see, there was some success here with pyPLC, and also with Everest. This helps to get the "big picture", thanks for this.
One remark regarding "DIN does not support AC charging": Also in the DIN spec, the AC charging is basically supported, this is visible in the https://github.com/Martin-P/OpenV2G, where we find things like dinEVRequestedEnergyTransferType_AC_three_phase_core. This sounds like that a car which supports only DIN may support also AC charging via high-level-protocol. I have no information, whether there are cars in the field, which actually support this feature.
Remark regarding convincing the Ioniq to use ISO instead of DIN: This is not possible from protocol flow point of view. In the very first messages, the car announces a list of supported protocols. The Ioniq just announces a list with one element: DIN. The charger has only the possiblity to say "I want the n'th entry of the list.", this means, no matter how we patch the charger, the Ioniq will talk either DIN or nothing.
Remark regarging the options to bring ISO15118 together with SmartEVSE: The options are well described above, all have their pro and cons, I see no perfect solution. A "compact, long term solution" would be a re-design, which directly integrates the homeplug stuff into the base unit, e.g. directly driven via SPI from the existing controller. As short-term, more flexible approach, which would be also upgradable at the already installed units, I see the modbus variant. Somehow to make a box ("SECC box") which only needs the CP line, power and modbus. It can permanently listen for SLAC requests, negotiate the SLAC, establish the high-level-communication and provide the result (SOC, success or error code) via a modbus register. The main controller just needs to read it, and can decide how to go on (most likely disconnecting, and providing "normal" PWM for normal AC charging).
The content of such a small box is quite flexible, maybe a raspberry with HomePlug modem (for the self-makers), or a ESP32 with an SPI-connected QCA7xxx. This could be developed independent from the main project.
Even if it comes to real high-level-AC-charging, there is no need for fast communication between the main controller and the SECC box. The time-critical high-level-communication is handled by the SECC box, and on modbus only such things like SOC and status is polled by the main controller, and things like "continue with x amps" are flowing from the main controller to the SECC box. Should be no issue, if this is slow, e.g. once per second.

Thanks for your reply.
I noticed on the Red Beet carrier dev board, there is an option to connect the QCA7xxx to mains lines, or you can connect it to the CP line. These are selectable with dip switches. A third connection is used for zero crossing detection. They mention it's mandatory, but on my dev board there's another dipswitch which allows you to switch off zero cross detection. (enabled by default)
Looking at the pictures from @ArendJanKramer, it seems his board had this set as well.
So knowing this, i am pretty sure he can disconnect the mains connections to the dev-board, and it would have no effect on his experiments..
I'm planning in doing some tests myself today. I've got the dev board communicating with the raspberry pi, with pyPLC in EVSE mode (basically what ArendJan had working last week)
I also have a YellowBeet-E board from 8Devices, they look suitable for the next step in development, as they have the required transformer for interfacing with the CP line (and ZC circuit).

If the only requirement is SOC readout, then it might be possible to let a ESP32 handle it. But no clue yet at the moment how to read/write to the red/yellow beet module over SPI, The linux driver seems to convert the SPI connection to a ETH port.
For a future SmartEVSE hardware version, i think it's best to connect it directly to the SPI bus of an ESP32(-S3).
As a first add-on to the current version, it might be an idea to make a raspberry pi shield/hat as ArendJan suggested.
As for communication between Rpi and SmartEVSE, there are no i/o pins left on the ESP, so i suggest using the USB/program port of the SmartEVSE and connected that to the raspberry pi.
State changes, SOC etc, can then be transferred serially.

Makes sense @mstegen. The YellowBeet-E sounds like a good solution. For me the question was indeed whether the 230v lines were really needed to communicate with the car; if this is/was the case I needed something that contained that extra circuitry for AC communication. If it's not necessary, then for my purposes the Yellow Beet-E will probably do (and combining it with an ESP32). I may also explore options to add it on the Sensorbox.
I am wondering, however, if the CP line communication is available on all cars, or if this differs per brand/make. Of course you will only find out after having received the module and trying that out.

At least the Type2 / CCS Type2 cars always use the CP for communication. The use of AC line for communication I only saw in 10 years old presentations. I do not think you will find a car which uses this (at least in Europe).
Regarding "no clue yet at the moment how to read/write to the red/yellow beet module over SPI": I saw a kind of reverse-engineered paper which describes the SPI communciation parameters, but cannot find it anymore. Was from I2SE I think, and they wrote something like "all information in this document was taken from the public linux driver". I understood, that "official" information regarding the protocol will be delivered from Qualcom only if you sign a NDA. But AFAIR the protocol was not too difficult, e.g. for sending an ethernet frame, on SPI some preamble and some short command word needs to be sent, and then the data one-to-one as in a ethernet frame.

Found it: Search for "an4 Aurich Wahren" in Google.

Some extra resources I've found while googling around a bit, maybe they are of help to anyone (definitely made interesting reads);
A paper that describes the standard in reasonable depth;
https://ltu.diva-portal.org/smash/get/diva2:1546405/FULLTEXT01.pdf
An existing EVSE Raspi HAT product - seems out of stock though;
https://www.tindie.com/products/evsec/hat-raspi-evse/
https://d3s5r33r268y59.cloudfront.net/datasheets/22870/2021-03-12-15-30-54/RasPi-EVSE_User_Guide.pdf
An alternative to the YellowBEET;
https://chargebyte.com/products/powerline-communication-modules/plc-stamp-mini-2
https://chargebyte.com/assets/Downloads/datasheet_plcstampmini2_rev12.pdf

@uhi22 Thank you for your in-depth response. I learnt a few things.
@arpiecodes Very useful resources, thanks for sharing. The shield is already out of stock for 2 years, seems they are not going to make that again.
Regarding the shield, I was thinking the make a new shield that fits a Raspberry PI zero.
Fortunately, since it seems we don't need the AC lines anymore, it saves a bit in components and headers.
When I have a bit of time I can start working on this board, and compute a theoretical costs for the shield.
If someone wants to work on an alternative approach, that'd only be good I think.

You mean to design a board which contains a QCA7005 with all the needed parts around it, which exposes the SPI to be controlled from a RPi zero? Would be a great thing. But I guess the application notes / data sheet for the QCA would require an NDA signment, maybe this makes it difficult. Alternatively, reverse-engineering of an existing solution would be a possibility. Interesting project :-)

So that would be the same board as the Yellowbeet E board that Michael Stegen mentioned, €39,- ; https://www.codico.com/en/yellow-beet-e-1-1

So that would be the same board as the Yellowbeet E board that Michael Stegen mentioned, €39,- ; https://www.codico.com/en/yellow-beet-e-1-1

Yes, that seems to cover all you need to connect a Pi to the CP/PE lines and talk GreenPHY with your car. The only challenge would be soldering some jumper wires to it so you can connect it to the Pi.

@dingo35 A yellow beet with some screw connectors which can be neatly placed on a RPI Zero (or bigger).
https://www.tindie.com/products/evsec/hat-raspi-evse/
This one, but smaller and Beet based.
I could also add an RS485 to UART transceiver, so it can be directly connected to SmartEVSE without Wifi.
Components:

RED Beet / Yellow beet, depending on form factor and costs
Screw terminals for CP in, CP out, PE, Modbus A/B/GND.
Tranceiver for UART/RS485
Header for PI
Some caps / resistors

@dingo35 A yellow beet with some screw connectors which can be neatly placed on a RPI Zero (or bigger).
https://www.tindie.com/products/evsec/hat-raspi-evse/ This one, but smaller and Beet based.
I could also add an RS485 to UART transceiver, so it can be directly connected to SmartEVSE without Wifi.
Components:

RED Beet / Yellow beet, depending on form factor and costs
Screw terminals for CP in, CP out, PE, Modbus A/B/GND.
Tranceiver for UART/RS485
Header for PI
Some caps / resistors

Hmm. I know we are in the github issue of SmartEVSE and that most of us have a SmartEVSE already, but for the interest of future expandability and customisability; would it not be a good idea to also add circuitry to generate the CP signal and add a couple of I/O's that would control the relays (like on the raspi-evse hat)? I see it even can be de-coupled by removing a jumper, which would allow the use with the SmartEVSE and the use without it (as soon as someone created a nice software stack for it).
That would allow one to build a complete solution on the raspi handling all charge stuff (and also according to the ISO/DIN protocol), instead of having to rely on communication through/with an external controller such as the SmartEVSE.

Well I must be a dumb tweaker, but if I have a Yellow beet with SPI lines on neatly solderable pads, I can connect to any Raspberry Pi (zero, W) or ESP32, and even, if there is still a Slave Select available on the SmartEVSE, the ESP32 thats inside the SmartEVSE.
Or are we trying to make a consumer end product here?

The hardware is not a real issue i think, it's the software (well atleast for me ;)
Could not get pyPlc to talk to the car. After hardcoding "eth1" in the source, the only thing i'm seeing is
[addressManager] pev has MAC 98:ED:5C:B9:BE:31
[1228394ms] [EVSE] transmitting CM_SLAC_PARAM.CNF
[1228637ms] received SLAC_PARAM.REQ
[addressManager] pev has MAC 98:ED:5C:B9:BE:31
[1228638ms] [EVSE] transmitting CM_SLAC_PARAM.CNF
[1228800ms] received SLAC_PARAM.REQ
[addressManager] pev has MAC 98:ED:5C:B9:BE:31
[1228801ms] [EVSE] transmitting CM_SLAC_PARAM.CNF
[1229043ms] received SLAC_PARAM.REQ
[addressManager] pev has MAC 98:ED:5C:B9:BE:31
[1229044ms] [EVSE] transmitting CM_SLAC_PARAM.CNF
[1229206ms] received SLAC_PARAM.REQ
[addressManager] pev has MAC 98:ED:5C:B9:BE:31
[1229207ms] [EVSE] transmitting CM_SLAC_PARAM.CNF

Now trying SwitchEV's iso15118 code, unfortunately it's complaining there is no eth1 interface..
While the output of dmesg | grep qca clearly shows it's driver is used.
and ifconfig eth1, tells me it's active.
Clearly, i'm missing something here. @ArendJanKramer can you explain what you did to get pyPLC to work in EVSE mode?
did you use docker for the SwitchEV's iso15118 code?

Well I must be a dumb tweaker, but if I have a Yellow beet with SPI lines on neatly solderable pads, I can connect to any Raspberry Pi (zero, W) or ESP32, and even, if there is still a Slave Select available on the SmartEVSE, the ESP32 thats inside the SmartEVSE.
Or are we trying to make a consumer end product here?

You definitely can and there's nothing wrong with that (in fact, I will probably be doing just that e.g. buying Yellow Beet-E for the time being so I can get something 'hacked' together and start doing some more research on the software side of things).
The only real big problem I'd see with using just a Beet module and a Pi, is that you'd need to use ethernet/WiFi for communicating between the Pi and the SmartEVSE (which I'd generally not considered a very stable/good way as it introduces a lot of dependencies into the chain - call it some form of OCD but it just doesn't add up for me)..
I suppose we all have our own specialities and ways to apply this knowledge. Which in the end hopefully means we have a nice solution useable for all (or at least, solving the issue in a good way). And I can't wait to begin hacking away on this so my order will be placed today. 😄

I see the following path: first have Yellow Beat + Raspberry pi over wifi, if that works, connect the Raspberry pi with the SmartEVSE through USB, if that works, solder the Yellow Beat to an extra ESP32 that communicates with the PI that communicates with the SmartEVSE through USB, if that works move over the software to the extra ESP32 (and get rid of the PI), if that would ever work solder the Yellow Beat to the SmartEVSE directly and move over the software from the extra ESP32 to the native ESP32 .

When pyPlc says "transmitting CM_SLAC_PARAM.CNF" this means: It received the SLAC param request from the car, and tries to send a response to the car. Would propose to run wireshark or tcpdump, to understand whether the response is not sent at all or gets lost in the modem. Or maybe just use a wrong MAC address or something.

The hardware is not a real issue i think, it's the software (well atleast for me ;)
Could not get pyPlc to talk to the car. After hardcoding "eth1" in the source, the only thing i'm seeing is
[addressManager] pev has MAC 98:ED:5C:B9:BE:31
[1228394ms] [EVSE] transmitting CM_SLAC_PARAM.CNF
[1228637ms] received SLAC_PARAM.REQ
[addressManager] pev has MAC 98:ED:5C:B9:BE:31
[1228638ms] [EVSE] transmitting CM_SLAC_PARAM.CNF
[1228800ms] received SLAC_PARAM.REQ
[addressManager] pev has MAC 98:ED:5C:B9:BE:31
[1228801ms] [EVSE] transmitting CM_SLAC_PARAM.CNF
[1229043ms] received SLAC_PARAM.REQ
[addressManager] pev has MAC 98:ED:5C:B9:BE:31
[1229044ms] [EVSE] transmitting CM_SLAC_PARAM.CNF
[1229206ms] received SLAC_PARAM.REQ
[addressManager] pev has MAC 98:ED:5C:B9:BE:31
[1229207ms] [EVSE] transmitting CM_SLAC_PARAM.CNF

Now trying SwitchEV's iso15118 code, unfortunately it's complaining there is no eth1 interface.. While the output of dmesg | grep qca clearly shows it's driver is used. and ifconfig eth1, tells me it's active.
Clearly, i'm missing something here. @ArendJanKramer can you explain what you did to get pyPLC to work in EVSE mode? did you use docker for the SwitchEV's iso15118 code?

@mstegen Sorry didn't see your message until I saw Github sending me a mail about a direct mention.
pyPLC is indeed quite hard to make running.
First, you need sudo rights, otherwise the slac part won't work. Second, yes you need to modify the code here and there to get it working. For me I also needed changes for the tcp server. My code and changes are very dirty, since I just wanted to see "some" result.
I suggest to abandon pyPLC, it's much less mature than SwitchEV's code. You can follow my steps I performed here:
https://github.com/SmartEVSE/SmartEVSE-3/issues/25#issuecomment-1544277019
Docker didn't work at all for me, I just resorted to run the code bare metal. Make sure to make modifications as mentioned in my comment, as this suite also defaults to eth0. pySlac needs sudo rights, iso15118 doesn't.
For work I use Docker a lot, so I'm happy to make the build working again but since I was just playing in the sand I couldn't care yet.

pyPLC is indeed quite hard to make running. First, you need sudo rights, otherwise the slac part won't work. Second, yes you need to modify the code here and there to get it working. For me I also needed changes for the tcp server. My code and changes are very dirty, since I just wanted to see "some" result.

Any hint welcome what was the issue and how a fix (or hack) could look like.

I haven't documented, you get an error, you fix it, run into the next, until it runs. I have tried so many things in the first day I can't remember all details. At least the eth adapter, as Stegen mentioned himself, missing Python packages. Crashes after a re-connect, because the port it claimed itself was already in use (by itself), hard-coded state-machines based on time, etc.. I'm happy to paste my dirt to Github tonight if you want, so we can see what changes I made. But in my opinion pyPLC is not mature for use, although I learnt a crapload of them, so in that regard I respect the repo.

Yes, any feedback welcome, thanks.

When pyPlc says "transmitting CM_SLAC_PARAM.CNF" this means: It received the SLAC param request from the car, and tries to send a response to the car. Would propose to run wireshark or tcpdump, to understand whether the response is not sent at all or gets lost in the modem. Or maybe just use a wrong MAC address or something.

I tried to run pyPlc.py E one more time, this time logged the data with tcpdump:
Also tried sudo python pevNoGui.py E, same result.
By looking at the ISO 15118-3 standard, i see that the 'RunID' here "TESLA EV" should be replicated in the response (CM_SLAC_PARM.CNF) , but in the logged data,  there is a second copy of the mac address.. that's probably why it does not work.
22:05:01.019245 98:ed:5c:b9:be:31 (oui Unknown) > Broadcast, ethertype Unknown (0x88e1), leng                                             th 60:
        0x0000:  0164 6000 0000 0054 4553 4c41 2045 5600  .d`....TESLA.EV.
        0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
22:05:01.036394 12:16:77:61:99:db (oui Unknown) > 98:ed:5c:b9:be:31 (oui Unknown), ethertype                                              Unknown (0x88e1), length 60:
        0x0000:  0165 6000 00ff ffff ffff ff0a 0601 98ed  .e`.............
        0x0010:  5cb9 be31 0000 98ed 5cb9 be31 0000 0000  \..1....\..1....
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

Good point, thanks for the analysis. Just pushed an update. (It's getting a little bit off-topic here ;-)

There is still a bug. The last two bytes of the 8 byte RunID field are overwritten by 0x00's

Pushed a new fix. How far does the Tesla get after the SessionSetup?

Thanks.
It get's up to "ContractAuthenticationReq"

@mstegen Two things that come to my mind to double check:

I changed the pib according to these instructions: https://github.com/qca/open-plc-utils/blob/1ba7d5a042e4e8ff6858b08e113eec5dc4e89cf2/docbook/slac-config.xml#L201 - Not sure if it makes a difference
My car also does exactly this when charge is >80%, it just won't communicate anymore. SLAC? Fine, but the car leaves the network after it has been set up. Sporadically it communicates to the TCP server, but seldomly and it usually stops at the contract stage. If the SoC is low, all these problems disappear. Since my car only supports DC I suspect communication only works reliable when fast charging is possible. Perhaps there's a bug somewhere, but can't fully explain.

Also, there's a bit of confusion from my side. pyPLC says this:
Checkpoint4: The car pulls the 12V at CP line to 9V (State B).
Checkpoint5: The charger sees the level change on CP and applies 5% PWM on CP.

For me this is not true, I have to go to 0V first and then apply 5%, going from 100% to 5% does not initiate communication. Perhaps I'm not doing the correct things here, it could be that I'm acting on the wrong voltage level.
(I modified SmartEVSE code yesterday to add states to the FSM to initiate ISO communication automatically before charging starts. Work in progress)

Regarding the connection loss: In case of such "sudden" broken connections, a pcap trace would be helpful. To distinguish whether the TCP is broken (we observed such cases), or the content of the message is a problem.
Regarding the 80% limit: At my Ioniq, the DC charging can be started, as long as the SOC is below 94%. Not yet tested, how it responds if the SOC is higher.
Regarding "0V necessary between StateB and 5% PWM": This is surprising, would be interesting to see an osci plot of on an original charger. Need to search in my records, maybe I find something. At least my EVSE does not support the 0V at all, and on the Ioniq it works perfect.

@ArendJanKramer Thanks, will check later today, car is in use right now.
Ref the State changes, it should be StateA(12V) -> State B(9V) -> 5% PWM , as uhi22 mentioned.
0V is not defined in the IEC-61851 standard. (it's either 12V, -12V, 9V, 6V or 3V)
I added a analog switch to the CP line to let the EV think the charge cable is disconnected.
The reason for doing that, is because some EV's will not restart charging when the EVSE stopped the charging.
(When solar charging this could happen frequently)
Another reason for adding the analog switch is 'safely' switch between 1 and 3 phase charging.

@uhi22 @mstegen Yep, agreed. It's a weird quirk, but it does work for me.
It's a good possibility the 0% triggers a "restart" which I need, rather than the protocol itself.
I do have the materials to make measurements on the CP line, such as logic analyzer and scope.
@dingo35 I think so as well, maybe you can elaborate the switch a bit @mstegen ?

Tested the behavior of the Ioniq if it is already at 100% SOC, when plugging into DC EVSE. Result: It does not even start the SLAC. Means: No chance to read the SOC in this condition.

The MAC address, which some providers (Fastned, EnBW) are using as identification for AutoCharge.

Just read on Wikipedia that Volkswagen issues a random MAC for each session.
But i guess if they switch to ISO 15118 there are other ways of authentication, that don't rely on the MAC address.

Tested the behavior of the Ioniq if it is already at 100% SOC, when plugging into DC EVSE. Result: It does not even start the SLAC. Means: No chance to read the SOC in this condition.

Thanks for testing.

Just read on Wikipedia that Volkswagen issues a random MAC for each session. But i guess if they switch to ISO 15118 there are other ways of authentication, that don't rely on the MAC address.

It's a pity, but I think it's a good move to protect privacy. For us we could integrate the MAC address in the rfid logic.
@arpiecodes You always surprise me with stuff you're able to find, it's unbelievable.
If someone is able to sent me pdfs of the original IEC-61851 standard, I'd be interested as the resources I find are behind paywalls.
It'd be great to eventually support 'Plug & Charge' for VW users.
I did some extra development myself yesterday (well debugging my own mistakes I guess).
First, I wanted to give pyPLC another shot. @uhi22 Great work in your recent patches, it works much better. I was also able to fix a bug of re-initializing the TCP connection. I can make a PR for that. For now it works good for me.
When I now connect my car, SmartEVSE follows the right procedures to initiate communication as well. When pyPLC receives messages, it makes a REST request to SmartEVSE to switch to normal charging and submit SoC statusses. SmartEVSE waits for 60 seconds to receive this request, otherwise it will just charge normally.
In the end it turned out I saw flaky behavior because I overlooked a single line where the load balancer was setting the PWM, and only a few moments later it'd go to 5%, so this was funky.
What helped me a lot is adding log statements for the current voltage level on the CP, that opened my eyes.
Anyways, for me it's not entirely clear what the duty cycle should be during State A, B and the transitions.

If I understand this one, it's supposed to be DC for state A and charge current duty cycle for B and C.
Whereas pyPLC says:
Checkpoint4: The car pulls the 12V at CP line to 9V (State B). Checkpoint5: The charger sees the level change on CP and applies 5% PWM on CP.
I read this as State A -> 12V DC, DC 9V -> 5% -> State B
My bug turned out to be State A -> 12V DC, DC 9V -> cargecurrent (briefly, because of State B in EVSE) -> 5%
@mstegen Your switch suggestion was extremely useful. I modified my pwm override to disable CP on 0% PWM, and enable it on any other value. This works much, much better.
I will try to clean my code and make it a bit more robust, so I can share it on Github.

This is what I currently have.
Notice that when I switch betweenn "OFF" and "NORMAL" you see the state change, and at some point the SoC states populate in the web ui.
https://github.com/SmartEVSE/SmartEVSE-3/assets/1292521/68c1f06d-8bbd-48e1-96e1-6d8a502591a7
There are some minor flaws to correct. For some reason, sometimes the car responds only with "PowerDeliveryReq", which only contains current SoC. Sometimes the cycle goes on until "ChargeParameterDiscoveryReq" which contains all states. Sometimes it fails with unexpected response, for which I made another Github issue at PyPLC. And sometimes there's no SLAC initiated, but this is quite rare thankfully.

Tested another situation with the Ioniq: 93% SOC, this is below the 94% where it would stop DC charging. This works fine, log here: https://github.com/uhi22/pyPLC/blob/master/results/2023-05-24_pyPlc_with_Ioniq93prcSoc.pcapng.

Small update: my Yellow Beet-E is on its way. Hope to pitch in soon on the software side of things as well.

I pushed my code changes for pyPLC to Github, so you can re-use the callback for SoC states.
Tip: Give your python interpreter capabilities to do some things without sudo:
sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/python3.9
And used something like PyCharm with remote deployment feature, so you can actually debug without being near the PI.
Since you can't easily do that with sudo rights, you need this trick.

Thanks @ArendJanKramer, I pulled your proposals, added some improvements, and also tried the sudo-less approach. Works fine, added to the documentation.

I pushed my work to the fork, in case someone wants to have a look at it:
https://github.com/ArendJanKramer/SmartEVSE-3
I do not have a lot of time in the coming days, and it's not PR ready. Todo's are mentioned in previous comment.

Got the YellowBeet in yesterday. Looks like I will have to solder 9 wires to the pads, which (for me) is challenging enough.. Probably going to give it a stab this weekend and begin with connecting it up to a raspi zero w.

I fixed my todos of my previous post.
For me it seems I can not AC charge after a "failed DC charge" as my car only support the DIN.
Therefore, I "replug" the car by toggling the CP after I have successfully / timed out modem communication.
This works great. Not sure how this is supposed to happen, but I don't have the "IEC-61851" and pricing is ridiculous. So for now re-plugging, perhaps there's a nicer approach sometime.
Btw, on my Raspberry I run pyPLC using systemd.
Don't forget to give python3.9 the permissions:
sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/python3.9
And modify user/group accordingly.
[Unit]
Description=pyPLC
After=network.target auditd.service

[Service]
Environment="PYTHONUNBUFFERED=1"
ExecStart=/usr/bin/python3.9 /home/evse/pyPLC/evseNoGui.py
WorkingDirectory=/home/evse/pyPLC
KillMode=process
Restart=on-failure
User=evse
Group=evse

[Install]
WantedBy=multi-user.target
Alias=pyplc.service

This PR features:

The ability to setup communication with car, according to ISO15118 standard
Work together with pyPLC (https://github.com/uhi22/pyPLC) which can handle the digital communication with the car, and submit the SoC states back to SmartEVSE
Compute the current SoC, based on the EV meter
Reliably reset SoC values upon disconnect with vehicle
"Re-plug" the vehicle if the communication fails, and after communication was succesfull to resume AC charging
Display the SoC values on the web UI

Work todo:

Set the battery capacity of the car via the menu, or via API. Currently hardcoded on 28kWh for Ioniq vehicle
Feature to stop charging once a specified SoC has been reached
Authorization of car based on MAC address of car

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

Nice :-)
The battery capacity is also contained in the messages from the vehicle: In ChargeParameterDiscoveryRequest, we find "EVEnergyCapacity.Value": "28000" for the Ioniq. However, this is an optional field, so there may be cars which do not report the capacity.

Very nice work @ArendJanKramer! I fully got your code to work here with the Yellow Beet E connected to a Raspberry Pi Zero W.
[27095ms] [EVSE] {
"msgName": "ChargeParameterDiscoveryReq",
"info": "39 bytes to convert",
"error": "",
"result": "",
"schema": "DIN",
"g_errn": "0",
"header.SessionID": "0102030405060708",
"header.Notification_isUsed": "0",
"header.Signature_isUsed": "0",
"EVRequestedEnergyTransferType": "3",
"EVChargeParameter_isUsed": "0",
"DC_EVChargeParameter_isUsed": "1",
"DC_EVStatus.EVRESSSOC": "97",
"DC_EVStatus.EVReady": "0",
"EVCabinConditioning_isUsed": "0",
"EVRESSConditioning_isUsed": "0",
"EVErrorCode": "0",
"DC_EVErrorCodeText": "NO_ERROR",
"EVMaximumCurrentLimit.Value": "3750",
"EVMaximumCurrentLimit.Multiplier": "-1",
"EVMaximumCurrentLimit.Unit_isUsed": "1",
"EVMaximumCurrentLimit.Unit": "3",
"EVMaximumPowerLimit_isUsed": "0",
"EVMaximumPowerLimit.Value": "0",
"EVMaximumPowerLimit.Multiplier": "0",
"EVMaximumPowerLimit.Unit_isUsed": "0",
"EVMaximumPowerLimit.Unit": "0",
"EVMaximumVoltageLimit.Value": "470",
"EVMaximumVoltageLimit.Multiplier": "0",
"EVMaximumVoltageLimit.Unit_isUsed": "1",
"EVMaximumVoltageLimit.Unit": "5",
"EVEnergyCapacity_isUsed": "1",
"EVEnergyCapacity.Value": "6870",
"EVEnergyCapacity.Multiplier": "1",
"EVEnergyCapacity.Unit_isUsed": "1",
"EVEnergyCapacity.Unit": "9",
"EVEnergyRequest_isUsed": "1",
"EVEnergyRequest.Value": "200",
"EVEnergyRequest.Multiplier": "1",
"EVEnergyRequest.Unit_isUsed": "1",
"EVEnergyRequest.Unit": "9",
"FullSOC_isUsed": "1",
"FullSOC": "100",
"BulkSOC_isUsed": "1",
"BulkSOC": "80",
"debug": "Line9057Line9260Line400"
}
[27121ms] [EVSE] Received ChargeParameterDiscoveryReq. Extracting SoC parameters via DC
Received SoC status from ChargeParameterDiscoveryReq.
    Remaining 97%
    Full at 100%
    Bulk at 80%

Also, nice additions to the serkri firmware, the hook also works properly;

My vehicle also seems to support ISO15118-2, but I noticed this one isn't supported by pyPLC. May need to try SwitchEV out soon to figure out if it would also work with that.
[26136ms] [EVSE] {
"msgName": "supportedAppProtocolReq",
"info": "68 bytes to convert",
"error": "",
"result": "Vehicle supports 2 protocols. ProtocolEntry#1 ProtocolNamespace=urn:din:70121:2012:MsgDef Version=2.0 SchemaID=1 Priority=1 ProtocolEntry#2 ProtocolNamespace=urn:iso:15118:2:2013:MsgDef Version=2.0 SchemaID=0 Priority=2 ",
"schema": "appHandshake",
"debug": ""
}

@arpiecodes The hostname is interesting, I remember mentioning it also in a reply on the pyPLC repo:
https://github.com/uhi22/pyPLC/issues/1
So, yes I ran into the same issue.
Of course I'm happy my code worked for you as well, it was N=1 on the combinations, glad we can say it's N=2.
Also nice you're testing different hardware combination, both on PI as well on the modem board type.
In the end it's the same, but devil is in the details sometimes.
Nice that you're looking into the serial connection option. I'm also interested in a wired connection.
A Modbus to USB cable would perhaps also work, but as long we can get it reasonably robust and easily implemented I'm not having strong opinions about either options. In the end, Modbus also needs Serial on the PI side (given we want to get wired) so my intuition says it'd save a bit on the SmartEVSE code.
The PDF you linked will 100% go in the bookmarks, really good find.

I want to summarize the modem work in a small instructions document in the git repo, including some images.
It'd be great if @fluppie can get on his feet with this document once he receives his, and we can fill in the missing steps from his experience.

@arpiecodes Thank you.
It's a bit rough still, especially the pyPLC part in de docs needs a bit of rework lol, I will try to make a PR to pyPLC repo to optimize the docs there a bit if you want to run in EVSE mode. But the systemd service runs as root in the original docs, and not using PYTHONBUFFERED, those kind of things.
https://github.com/ArendJanKramer/SmartEVSE-3/blob/modem_docs/manual/Modem.md

busy trying to get it too work, cannot probe the eth1 interface.
Did enable the SPI communication (not mentioned step tin the manuals)
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on

and added the
dtoverlay -h qca7000
step
pi@rpievse:~ $ sudo dmesg | grep qca
pi@rpievse:~ $ lsmod | grep spi_
spi_bcm2835            20480  0
pi@rpievse:~ $ ifconfig eth1
eth1: error fetching interface information: Device not found
pi@rpievse:~ $ sudo dmesg | grep qca

Any ideas @ArendJanKramer or @arpiecodes ?
I'm using a clean Debian Bullseye 64-bit lite image.

Aha, got it out of the Codico manual, you need to use
dtoverlay=qca7000, speed=12000000
instead of
dtoverlay -h qca7000
pi@rpievse:~ $ sudo dmesg | grep qca
[   10.948685] qcaspi spi0.0: ver=0.2.7-i, clkspeed=12000000, burst_len=5000, pluggable=0
[   10.949078] qcaspi spi0.0: Using random MAC address: ea:40:5c:a0:c2:a8
[   12.889097] qcaspi spi0.0 eth1: SPI thread created

Now busy with pyPlc and stuck in the steps to testrun pyPlc

pi@rpievse:~/myprogs/pyPlc $ sudo python pyPlc.py E S
starting in EvseMode, simulated environment
Traceback (most recent call last):
  File "/home/pi/myprogs/pyPlc/pyPlc.py", line 96, in <module>
    root = tk.Tk()
  File "/usr/lib/python3.9/tkinter/__init__.py", line 2270, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: no display name and no $DISPLAY environment variable
pi@rpievse:~/myprogs/pyPlc $ sudo python pyPlc.py P S
starting in PevMode, simulated environment
Traceback (most recent call last):
  File "/home/pi/myprogs/pyPlc/pyPlc.py", line 96, in <module>
    root = tk.Tk()
  File "/usr/lib/python3.9/tkinter/__init__.py", line 2270, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: no display name and no $DISPLAY environment variable
pi@rpievse:~/myprogs/pyPlc $ python pyPlc.py E
starting in EvseMode
Traceback (most recent call last):
  File "/home/pi/myprogs/pyPlc/pyPlc.py", line 96, in <module>
    root = tk.Tk()
  File "/usr/lib/python3.9/tkinter/__init__.py", line 2270, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: no display name and no $DISPLAY environment variable
pi@rpievse:~/myprogs/pyPlc $

Also installed these packages to get further:
sudo apt-get install python3-tk
sudo apt-get install python3-serial
pip install pyserial

OK, had to change the hosts file and add the rpievse hostname to ::1
Now something is happening, but no SoC so far.  BMW iX3 with latest updates, was in the dealership half May.
 We are the SECC. Sending SDP response.
Jun 18 16:18:30 rpievse python3.9[491]: SDP payload (20bytes) = FE 80 00 00 00 00 00 00 5F 38 0C 6B CB 09 3A 17 3B 0E 10 00
Jun 18 16:18:30 rpievse python3.9[491]: V2Gframe (28bytes) = 01 FE 90 01 00 00 00 14 FE 80 00 00 00 00 00 00 5F 38 0C 6B CB 09 3A 17 3B 0E 10 00
Jun 18 16:18:30 rpievse python3.9[491]: [228031ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 16:18:30 rpievse python3.9[491]: [228035ms] Connection from ('fe80::ee65:ccff:feb6:85dc', 49153, 0, 4)
Jun 18 16:18:30 rpievse python3.9[491]: [SNIFFER] EXI from 49153 to 15118 (34bytes) = 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 00 00 40
Jun 18 16:18:30 rpievse python3.9[491]: [228069ms] [EVSE] In state WaitForSupportedApplicationProtocolRequest, received (42bytes) = 01 FE 80 01 00 00 00 22 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 00 00 40
Jun 18 16:18:30 rpievse python3.9[491]: [228110ms] [EVSE] {
Jun 18 16:18:30 rpievse python3.9[491]: "msgName": "supportedAppProtocolReq",
Jun 18 16:18:30 rpievse python3.9[491]: "info": "34 bytes to convert",
Jun 18 16:18:30 rpievse python3.9[491]: "error": "",
Jun 18 16:18:30 rpievse python3.9[491]: "result": "Vehicle supports 1 protocols. ProtocolEntry#1 ProtocolNamespace=urn:din:70121:2012:MsgDef Version=2.0 SchemaID=0 Priority=1 ",
Jun 18 16:18:30 rpievse python3.9[491]: "schema": "appHandshake",
Jun 18 16:18:30 rpievse python3.9[491]: "debug": ""
Jun 18 16:18:30 rpievse python3.9[491]: }
Jun 18 16:18:30 rpievse python3.9[491]: [228113ms] [EVSE] Detected DIN
Jun 18 16:18:30 rpievse python3.9[491]: [228132ms] [EVSE] responding (12bytes) = 01 FE 80 01 00 00 00 04 80 40 00 40
Jun 18 16:18:30 rpievse python3.9[491]: [228134ms] [EVSE] from 0 entering 1
Jun 18 16:18:30 rpievse python3.9[491]: [SNIFFER] EXI from 15118 to 49153 (4bytes) = 80 40 00 40
Jun 18 16:18:30 rpievse python3.9[491]: [228179ms] connection closed
Jun 18 16:18:30 rpievse python3.9[491]: [228180ms] [EVSE] re-initializing fsmEvse due to broken connection
Jun 18 16:18:30 rpievse python3.9[491]: [228181ms] [EVSE] re-initializing fsmEvse
Jun 18 16:18:30 rpievse python3.9[491]: [228181ms] Trying to reset the TCP socket
Jun 18 16:18:30 rpievse python3.9[491]: [228182ms] pyPlcTcpSocket listening on port 15118
Jun 18 16:18:30 rpievse python3.9[491]: [228185ms] The socket is linked the following IP addresses:
Jun 18 16:18:30 rpievse python3.9[491]: [228185ms] ::1
Jun 18 16:18:30 rpievse python3.9[491]: [228186ms] ::1
Jun 18 16:18:30 rpievse python3.9[491]: [228186ms] ::1
Jun 18 16:18:32 rpievse python3.9[491]: [230652ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 16:18:35 rpievse python3.9[491]: [233331ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5

Jun 18 16:21:32 rpievse python3.9[491]: [410164ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 16:21:34 rpievse python3.9[491]: [412842ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 16:21:37 rpievse python3.9[491]: [415527ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 16:21:39 rpievse python3.9[491]: [417314ms] received SLAC_PARAM.REQ
Jun 18 16:21:39 rpievse python3.9[491]: [addressManager] pev has MAC EC:65:CC:B6:85:DC
Jun 18 16:21:39 rpievse python3.9[491]: [417315ms] [EVSE] transmitting CM_SLAC_PARAM.CNF
Jun 18 16:21:39 rpievse python3.9[491]: [417560ms] received MNBC_SOUND.IND
Jun 18 16:21:39 rpievse python3.9[491]: [417562ms] received MNBC_SOUND.IND
Jun 18 16:21:39 rpievse python3.9[491]: [417644ms] received MNBC_SOUND.IND
Jun 18 16:21:39 rpievse python3.9[491]: [417645ms] received MNBC_SOUND.IND
Jun 18 16:21:39 rpievse python3.9[491]: [417647ms] received MNBC_SOUND.IND
Jun 18 16:21:39 rpievse python3.9[491]: [417729ms] received MNBC_SOUND.IND
Jun 18 16:21:39 rpievse python3.9[491]: [417730ms] received MNBC_SOUND.IND
Jun 18 16:21:39 rpievse python3.9[491]: [417731ms] received MNBC_SOUND.IND
Jun 18 16:21:39 rpievse python3.9[491]: [417814ms] received MNBC_SOUND.IND
Jun 18 16:21:39 rpievse python3.9[491]: [417815ms] received MNBC_SOUND.IND
Jun 18 16:21:39 rpievse python3.9[491]: [417816ms] [EVSE] transmitting ATTEN_CHAR.IND
Jun 18 16:21:40 rpievse python3.9[491]: [418224ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 16:21:40 rpievse python3.9[491]: [418712ms] received SLAC_MATCH.REQ
Jun 18 16:21:40 rpievse python3.9[491]: [418713ms] [EVSE] transmitting SLAC_MATCH.CNF
Jun 18 16:21:42 rpievse python3.9[491]: [420905ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 16:21:44 rpievse python3.9[491]: [addressManager] pev has IP fe80:0000:0000:0000:ee65:ccff:feb6:85dc
Jun 18 16:21:44 rpievse python3.9[491]: V2GTP (10bytes) = 01 FE 90 00 00 00 00 02 10 00
Jun 18 16:21:44 rpievse python3.9[491]: Ok, this was a valid SDP request. We are the SECC. Sending SDP response.
Jun 18 16:21:44 rpievse python3.9[491]: SDP payload (20bytes) = FE 80 00 00 00 00 00 00 5F 38 0C 6B CB 09 3A 17 3B 0E 10 00
Jun 18 16:21:44 rpievse python3.9[491]: V2Gframe (28bytes) = 01 FE 90 01 00 00 00 14 FE 80 00 00 00 00 00 00 5F 38 0C 6B CB 09 3A 17 3B 0E 10 00
Jun 18 16:21:45 rpievse python3.9[491]: [422956ms] Connection from ('fe80::ee65:ccff:feb6:85dc', 49154, 0, 4)
Jun 18 16:21:45 rpievse python3.9[491]: [SNIFFER] EXI from 49154 to 15118 (34bytes) = 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 00 00 40
Jun 18 16:21:45 rpievse python3.9[491]: [422990ms] [EVSE] In state WaitForSupportedApplicationProtocolRequest, received (42bytes) = 01 FE 80 01 00 00 00 22 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 00 00 40
Jun 18 16:21:45 rpievse python3.9[491]: [423011ms] [EVSE] {
Jun 18 16:21:45 rpievse python3.9[491]: "msgName": "supportedAppProtocolReq",
Jun 18 16:21:45 rpievse python3.9[491]: "info": "34 bytes to convert",
Jun 18 16:21:45 rpievse python3.9[491]: "error": "",
Jun 18 16:21:45 rpievse python3.9[491]: "result": "Vehicle supports 1 protocols. ProtocolEntry#1 ProtocolNamespace=urn:din:70121:2012:MsgDef Version=2.0 SchemaID=0 Priority=1 ",
Jun 18 16:21:45 rpievse python3.9[491]: "schema": "appHandshake",
Jun 18 16:21:45 rpievse python3.9[491]: "debug": ""
Jun 18 16:21:45 rpievse python3.9[491]: }
Jun 18 16:21:45 rpievse python3.9[491]: [423014ms] [EVSE] Detected DIN
Jun 18 16:21:45 rpievse python3.9[491]: [423034ms] [EVSE] responding (12bytes) = 01 FE 80 01 00 00 00 04 80 40 00 40
Jun 18 16:21:45 rpievse python3.9[491]: [423036ms] [EVSE] from 0 entering 1
Jun 18 16:21:45 rpievse python3.9[491]: [SNIFFER] EXI from 15118 to 49154 (4bytes) = 80 40 00 40
Jun 18 16:21:45 rpievse python3.9[491]: [423085ms] connection closed
Jun 18 16:21:45 rpievse python3.9[491]: [423085ms] [EVSE] re-initializing fsmEvse due to broken connection
Jun 18 16:21:45 rpievse python3.9[491]: [423086ms] [EVSE] re-initializing fsmEvse
Jun 18 16:21:45 rpievse python3.9[491]: [423087ms] Trying to reset the TCP socket
Jun 18 16:21:45 rpievse python3.9[491]: [423088ms] pyPlcTcpSocket listening on port 15118
Jun 18 16:21:45 rpievse python3.9[491]: [423090ms] The socket is linked the following IP addresses:
Jun 18 16:21:45 rpievse python3.9[491]: [423090ms] ::1
Jun 18 16:21:45 rpievse python3.9[491]: [423091ms] ::1
Jun 18 16:21:45 rpievse python3.9[491]: [423091ms] ::1
Jun 18 16:21:45 rpievse python3.9[491]: [423530ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 16:21:48 rpievse python3.9[491]: [426208ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 16:21:50 rpievse python3.9[491]: [428886ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5

Jup looks like I'm stuck. Important to know if a 64-bit Debian Bullseye lite can work. Or if I need to use the full and maybe 32-bit for some reason?

Jun 18 17:27:47 rpievse python3.9[964]: [327155ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 17:27:50 rpievse python3.9[964]: [329833ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 17:27:53 rpievse python3.9[964]: [332514ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 17:27:53 rpievse python3.9[964]: [333246ms] received SLAC_PARAM.REQ
Jun 18 17:27:53 rpievse python3.9[964]: [addressManager] pev has MAC EC:65:CC:B6:85:DC
Jun 18 17:27:53 rpievse python3.9[964]: [333248ms] [EVSE] transmitting CM_SLAC_PARAM.CNF
Jun 18 17:27:54 rpievse python3.9[964]: [333494ms] received MNBC_SOUND.IND
Jun 18 17:27:54 rpievse python3.9[964]: [333496ms] received MNBC_SOUND.IND
Jun 18 17:27:54 rpievse python3.9[964]: [333579ms] received MNBC_SOUND.IND
Jun 18 17:27:54 rpievse python3.9[964]: [333580ms] received MNBC_SOUND.IND
Jun 18 17:27:54 rpievse python3.9[964]: [333582ms] received MNBC_SOUND.IND
Jun 18 17:27:54 rpievse python3.9[964]: [333665ms] received MNBC_SOUND.IND
Jun 18 17:27:54 rpievse python3.9[964]: [333666ms] received MNBC_SOUND.IND
Jun 18 17:27:54 rpievse python3.9[964]: [333667ms] received MNBC_SOUND.IND
Jun 18 17:27:54 rpievse python3.9[964]: [333750ms] received MNBC_SOUND.IND
Jun 18 17:27:54 rpievse python3.9[964]: [333751ms] received MNBC_SOUND.IND
Jun 18 17:27:54 rpievse python3.9[964]: [333752ms] [EVSE] transmitting ATTEN_CHAR.IND
Jun 18 17:27:55 rpievse python3.9[964]: [334647ms] received SLAC_MATCH.REQ
Jun 18 17:27:55 rpievse python3.9[964]: [334649ms] [EVSE] transmitting SLAC_MATCH.CNF
Jun 18 17:27:55 rpievse python3.9[964]: [335218ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 17:27:58 rpievse python3.9[964]: [337898ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 17:27:59 rpievse python3.9[964]: [addressManager] pev has IP fe80:0000:0000:0000:ee65:ccff:feb6:85dc
Jun 18 17:27:59 rpievse python3.9[964]: V2GTP (10bytes) = 01 FE 90 00 00 00 00 02 10 00
Jun 18 17:27:59 rpievse python3.9[964]: Ok, this was a valid SDP request. We are the SECC. Sending SDP response.
Jun 18 17:27:59 rpievse python3.9[964]: SDP payload (20bytes) = FE 80 00 00 00 00 00 00 5F 38 0C 6B CB 09 3A 17 3B 0E 10 00
Jun 18 17:27:59 rpievse python3.9[964]: V2Gframe (28bytes) = 01 FE 90 01 00 00 00 14 FE 80 00 00 00 00 00 00 5F 38 0C 6B CB 09 3A 17 3B 0E 10 00
Jun 18 17:27:59 rpievse python3.9[964]: [338394ms] Connection from ('fe80::ee65:ccff:feb6:85dc', 49153, 0, 4)
Jun 18 17:27:59 rpievse python3.9[964]: [SNIFFER] EXI from 49153 to 15118 (34bytes) = 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 00 00 40
Jun 18 17:27:59 rpievse python3.9[964]: [338427ms] [EVSE] In state WaitForSupportedApplicationProtocolRequest, received (42bytes) = 01 FE 80 01 00 00 00 22 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 00 00 40
Jun 18 17:27:59 rpievse python3.9[964]: [338449ms] [EVSE] {
Jun 18 17:27:59 rpievse python3.9[964]: "msgName": "supportedAppProtocolReq",
Jun 18 17:27:59 rpievse python3.9[964]: "info": "34 bytes to convert",
Jun 18 17:27:59 rpievse python3.9[964]: "error": "",
Jun 18 17:27:59 rpievse python3.9[964]: "result": "Vehicle supports 1 protocols. ProtocolEntry#1 ProtocolNamespace=urn:din:70121:2012:MsgDef Version=2.0 SchemaID=0 Priority=1 ",
Jun 18 17:27:59 rpievse python3.9[964]: "schema": "appHandshake",
Jun 18 17:27:59 rpievse python3.9[964]: "debug": ""
Jun 18 17:27:59 rpievse python3.9[964]: }
Jun 18 17:27:59 rpievse python3.9[964]: [338452ms] [EVSE] Detected DIN
Jun 18 17:27:59 rpievse python3.9[964]: [338475ms] [EVSE] responding (12bytes) = 01 FE 80 01 00 00 00 04 80 40 00 40
Jun 18 17:27:59 rpievse python3.9[964]: [338477ms] [EVSE] from 0 entering 1
Jun 18 17:27:59 rpievse python3.9[964]: [SNIFFER] EXI from 15118 to 49153 (4bytes) = 80 40 00 40
Jun 18 17:27:59 rpievse python3.9[964]: [338530ms] connection closed
Jun 18 17:27:59 rpievse python3.9[964]: [338531ms] [EVSE] re-initializing fsmEvse due to broken connection
Jun 18 17:27:59 rpievse python3.9[964]: [338531ms] [EVSE] re-initializing fsmEvse
Jun 18 17:27:59 rpievse python3.9[964]: [338532ms] Trying to reset the TCP socket
Jun 18 17:27:59 rpievse python3.9[964]: [338533ms] pyPlcTcpSocket listening on port 15118
Jun 18 17:27:59 rpievse python3.9[964]: [338535ms] The socket is linked the following IP addresses:
Jun 18 17:27:59 rpievse python3.9[964]: [338536ms] ::1
Jun 18 17:27:59 rpievse python3.9[964]: [338536ms] ::1
Jun 18 17:27:59 rpievse python3.9[964]: [338537ms] ::1
Jun 18 17:28:01 rpievse python3.9[964]: [340514ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 17:28:03 rpievse python3.9[964]: [343194ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 18 17:28:06 rpievse python3.9[964]: [345871ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5

@fluppie Few things I see in your posts:

Apparently there are some minor differences between your os and the default raspbian, because the overlay for me works just fine. I can adjust the docs here
The tk error you see in python is from tkinter. Without a window server (headless) you will never be able to run tkinter, even if you install the python packages (well, unless apt installs the desktop environment as dependency). Therefore I have added the evseNoGUI.py, the counterpart of pevNoGUI.py which already existed.
I will add the no hostname thing to the docs

It seems there is some form of communication, but it's failing. I do not know the answer.
One of the things I've done in my journey when things didn't work is adjusting the PIB. You can try that, and revert if things don't change:
plctool -ieth1 -p original.pib  <Your mac addr of red beet>
cp original.pib evse.pib
setpib evse.pib 74 hfid "EVSE"
setpib evse.pib F4 byte 2
setpib evse.pib 1653 byte 2
setpib evse.pib 1C98 long 10240 long 102400
cat evse.pib
plctool -ieth1 -P evse.pib <Your mac of red beet interface>

If it doesn't work you can perhaps ask in the pyPLC repo in an issue why communication is failing, @uhi22 knows obviously much more about this than I do. Perhaps you can also try another car, if you know someone with another EV.

I used the Raspberry Pi Imager v1.7.5 with the 2023-05-03 release. Also tried the 32-bit full instead of 64-bit Lite. Same behaviour.
I don't have a monitor connected to my RPi Model 3B+, only SSH / Putty. I use a wired LAN connection for the RPi.
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        inet6 fe80::daf2:ae7a:db60:d6a9  prefixlen 64  scopeid 0x20<link>
        ether 46:68:09:2f:b0:b1  txqueuelen 100  (Ethernet)
        RX packets 287  bytes 21676 (21.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 24711  bytes 2450507 (2.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Is 46:68:09:2f:b0:b1 my Red Beet's MAC address?

It seems to be the car is connecting to the socket server and is exchanging EXI format payloads with PyPLC. I don't think the communication layer is the issue here. The car is probably getting something back it's not expecting and closes (resets) the connection. To be that appears as a compatibility issue somewhere..

Thanks for the pointers, I'll see if I'm able to run josev
I have a pcap file for those interested
BMWiX3.zip

@ArendJanKramer & @arpiecodes did you disable/modify stuff regarding the network manager?
https://github.com/uhi22/pyPLC/blob/master/doc/installation_on_raspberry.md#disable-network-manager-for-the-ethernet-port
my ifconfig looks like this:
pi@rpievse:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        inet6 fe80::986e:fb1:8764:ffee  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:33:26:6a  txqueuelen 1000  (Ethernet)
        RX packets 1636072  bytes 215414482 (205.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 96111  bytes 21909178 (20.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        inet6 fe80::daf2:ae7a:db60:d6a9  prefixlen 64  scopeid 0x20<link>
        ether 46:68:09:2f:b0:b1  txqueuelen 100  (Ethernet)
        RX packets 741  bytes 56149 (54.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 69203  bytes 6908698 (6.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 109  bytes 10949 (10.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 109  bytes 10949 (10.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        inet6 fe80::19af:99c3:b2f5:a6b1  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:66:73:3f  txqueuelen 1000  (Ethernet)
        RX packets 554973  bytes 121131013 (115.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1709  bytes 123668 (120.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

For the moment no other EV's around to test with :(. So don't know if it's the car or something else.

@fluppie I did not disable the network manager, and got it to work with on a RaspberryPi zero W together with the RedBeet dev board.
What modem board are you using?

@fluppie I also didn’t disable network manager.  I see it has a self-assigned ip. Perhaps uhi22 knows a bit more, but maybe its best to try with another ev, as the communication seems to be initialized.

OK thanks, I also use the Red Beet dev kit. identical setup as ArendJan.
Will have a Tesla M3 over on Sunday, so will test with this car.

So Today the Tesla over, I had 2 succesful tries (out of 9). I think, can't tell for sure, that when switching to normal mode it worked, and not in smart and solar. But don't take me up on this.
	Regel 5035: Jun 25 18:11:04 rpievse python3.9[23722]: "DC_EVStatus.EVRESSSOC": "36",
	Regel 5624: Jun 25 18:24:01 rpievse python3.9[23722]: "DC_EVStatus.EVRESSSOC": "36",

I think I might be right (HACS integration only fetches every minute). I'll have to test with the BMW.

Nope, still nothing with the iX3 :-(. Even tried the plctool commands from AJ
Jun 25 23:40:27 rpievse python3.9[1337]: [82013ms] received SLAC_PARAM.REQ
Jun 25 23:40:27 rpievse python3.9[1337]: [addressManager] pev has MAC EC:65:CC:B6:85:DC
Jun 25 23:40:27 rpievse python3.9[1337]: [82014ms] [EVSE] transmitting CM_SLAC_PARAM.CNF
Jun 25 23:40:28 rpievse python3.9[1337]: [82259ms] received MNBC_SOUND.IND
Jun 25 23:40:28 rpievse python3.9[1337]: [82261ms] received MNBC_SOUND.IND
Jun 25 23:40:28 rpievse python3.9[1337]: [82343ms] received MNBC_SOUND.IND
Jun 25 23:40:28 rpievse python3.9[1337]: [82344ms] received MNBC_SOUND.IND
Jun 25 23:40:28 rpievse python3.9[1337]: [82427ms] received MNBC_SOUND.IND
Jun 25 23:40:28 rpievse python3.9[1337]: [82428ms] received MNBC_SOUND.IND
Jun 25 23:40:28 rpievse python3.9[1337]: [82429ms] received MNBC_SOUND.IND
Jun 25 23:40:28 rpievse python3.9[1337]: [82511ms] received MNBC_SOUND.IND
Jun 25 23:40:28 rpievse python3.9[1337]: [82512ms] received MNBC_SOUND.IND
Jun 25 23:40:28 rpievse python3.9[1337]: [82513ms] [EVSE] transmitting ATTEN_CHAR.IND
Jun 25 23:40:28 rpievse python3.9[1337]: [83162ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 25 23:40:29 rpievse python3.9[1337]: [83407ms] received SLAC_MATCH.REQ
Jun 25 23:40:29 rpievse python3.9[1337]: [83408ms] [EVSE] transmitting SLAC_MATCH.CNF
Jun 25 23:40:31 rpievse python3.9[1337]: [85841ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 25 23:40:32 rpievse python3.9[1337]: [addressManager] pev has IP fe80:0000:0000:0000:ee65:ccff:feb6:85dc
Jun 25 23:40:32 rpievse python3.9[1337]: V2GTP (10bytes) = 01 FE 90 00 00 00 00 02 10 00
Jun 25 23:40:32 rpievse python3.9[1337]: Ok, this was a valid SDP request. We are the SECC. Sending SDP response.
Jun 25 23:40:32 rpievse python3.9[1337]: SDP payload (20bytes) = FE 80 00 00 00 00 00 00 95 6E 4E E7 AE EE 9B 73 3B 0E 10 00
Jun 25 23:40:32 rpievse python3.9[1337]: V2Gframe (28bytes) = 01 FE 90 01 00 00 00 14 FE 80 00 00 00 00 00 00 95 6E 4E E7 AE EE 9B 73 3B 0E 10 00
Jun 25 23:40:33 rpievse python3.9[1337]: [SNIFFER] EXI from 49156 to 15118 (34bytes) = 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 00 00 40
Jun 25 23:40:33 rpievse python3.9[1337]: [87229ms] Connection from ('fe80::ee65:ccff:feb6:85dc', 49156, 0, 4)
Jun 25 23:40:33 rpievse python3.9[1337]: [87262ms] [EVSE] In state WaitForSupportedApplicationProtocolRequest, received (42bytes) = 01 FE 80 01 00 00 00 22 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 00 00 40
Jun 25 23:40:33 rpievse python3.9[1337]: [87293ms] [EVSE] {
Jun 25 23:40:33 rpievse python3.9[1337]: "msgName": "supportedAppProtocolReq",
Jun 25 23:40:33 rpievse python3.9[1337]: "info": "34 bytes to convert",
Jun 25 23:40:33 rpievse python3.9[1337]: "error": "",
Jun 25 23:40:33 rpievse python3.9[1337]: "result": "Vehicle supports 1 protocols. ProtocolEntry#1 ProtocolNamespace=urn:din:70121:2012:MsgDef Version=2.0 SchemaID=0 Priority=1 ",
Jun 25 23:40:33 rpievse python3.9[1337]: "schema": "appHandshake",
Jun 25 23:40:33 rpievse python3.9[1337]: "debug": ""
Jun 25 23:40:33 rpievse python3.9[1337]: }
Jun 25 23:40:33 rpievse python3.9[1337]: [87295ms] [EVSE] Detected DIN
Jun 25 23:40:33 rpievse python3.9[1337]: [87310ms] [EVSE] responding (12bytes) = 01 FE 80 01 00 00 00 04 80 40 00 40
Jun 25 23:40:33 rpievse python3.9[1337]: [87312ms] [EVSE] from 0 entering 1
Jun 25 23:40:33 rpievse python3.9[1337]: [SNIFFER] EXI from 15118 to 49156 (4bytes) = 80 40 00 40
Jun 25 23:40:33 rpievse python3.9[1337]: [87365ms] connection closed
Jun 25 23:40:33 rpievse python3.9[1337]: [87366ms] [EVSE] re-initializing fsmEvse due to broken connection
Jun 25 23:40:33 rpievse python3.9[1337]: [87366ms] [EVSE] re-initializing fsmEvse
Jun 25 23:40:33 rpievse python3.9[1337]: [87367ms] Trying to reset the TCP socket
Jun 25 23:40:33 rpievse python3.9[1337]: [87368ms] pyPlcTcpSocket listening on port 15118
Jun 25 23:40:33 rpievse python3.9[1337]: [87370ms] The socket is linked the following IP addresses:
Jun 25 23:40:33 rpievse python3.9[1337]: [87370ms] ::1
Jun 25 23:40:33 rpievse python3.9[1337]: [87371ms] ::1
Jun 25 23:40:33 rpievse python3.9[1337]: [87371ms] ::1
Jun 25 23:40:34 rpievse python3.9[1337]: [88455ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 25 23:40:36 rpievse python3.9[1337]: [91129ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 25 23:40:39 rpievse python3.9[1337]: [93803ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5

@ArendJanKramer I've been busy over the weekend and hacked in some extra goodness in both the serkri SmartEVSE code and the PyPLC code. I will try to ready my changes for a pull request on both repo's.
In light of my latest hackings, there's something I'd like to request/would like your input on. For the 'access by modem' feature to work, we need the SmartEVSE to initiate modem communication with the vehicle regardless of the Access_bit, as currently nothing will happen after plugging in the vehicle if access is denied. As we do not know whether the vehicle is actually on the 'white list' we need to obviously ask it first, then decide whether we want to allow it to continue the charging process.
I suppose having EV state/data regardless of access state would be a nice thing to have anyways..
My question is; could you look at your added logic and maybe find a place where we could do these access checks? Maybe make a small example for me where to insert the code? If you prefer I could also simply push my changes/hacks so you know where I'm at now and maybe explains a bit more what I'd like to do.

I've opened two pull requests (three if you also count the MQTT support one) containing my latest hackings;
https://github.com/serkri/SmartEVSE-3/pull/160
https://github.com/uhi22/pyPLC/pull/8
Seems to work quite well. I even was able to include a basic AutoCharge feature. This does not use the whitelist method mentioned yet, but enforces a single EVCCID.
Let me know what you think!

Wow nice work @arpiecodes i'll test your changes tomorrow.
I have been trying to get basic SPI communication between a YellowBeet and a ESP32-S3 to work.
The datasheet for the QCA7000 (https://www.findic.us/part-doc-transfer/30159072) contained valuable information about the registers, and how to read/write to the internal registers or to the data buffer.
Took some time before i figured out how to setup the ESP32-S3 correctly, so it uses USB-CDC mode (and does not require a manual reset after programming the chip).
Reading the QCA700X's signature register works now. So i can identify the chip on the SPI bus.
Baby steps...

@arpiecodes Thanks for your work, I'll try to look into them tomorrow!

@arpiecodes nice work. At first sight josev/switchev looks a bit to complicated for me.
@uhi22 saw in the logs that my car request SchemaID=0 while the other tested cars request SchemaID=1. Apparently SchemaID=1 is hardcoded in pyPlc.
Cross referencing https://github.com/uhi22/pyPLC/issues/6

@fluppie For Josev, see the steps I did:
https://github.com/SmartEVSE/SmartEVSE-3/issues/25#issuecomment-1544277019
It's not as difficult as it seems. It might seem a bit confusing at first to run two separate processes, but the setup makes sense at some point.

@arpiecodes looked at your code, looks great, thanks for all the work!
I want to make a remark on the API though; you are trying to change /modem to /ev_state , and add /settings/evccid .
I think forward compatibility is important, so changing API's back and forth between PR's is not the way to go.
Although I can see the logic in splitting stuff in /settings and /ev_state from a conceptual point of view, I would like to isolate all this ISO15118 stuff into the /modem endpoint and the [car_modem] json category, so that all other users are not getting confused ("why is this ev_state empty?" "well its because you don't have a modem installed").
If the modem gets mainstream (e.g. when Michael introduces a commercial add-on or a SmartEVSEv4 that has it) we might have to reconsider this, but for now lets keep this stuff together.
Also as to EVCCID, IMHO this has to be a repeatable field since you can have multiple EV's connecting/allowing. I will look into a solution like the RFID reader, where you can store 8 cards; perhaps I can reuse some code....
At all involved, please your thoughts on all of the above.

I agree with @arpiecodes, the feature is not really used by anyone. I have no bad feeling towards renaming / changing the API. I see both of you have some points though. I think we need to ask the following question:

Are authorization/authentication methods related to modem or rfid or can we generalize?
- If we'd ever introduce vehicle OR user profiles or something, how does it work then?

I think the API changes are an improvement. The only compatibility things he broke are my home assistant automations, but I do not care changing them honestly.
I feel there is some technical debt, but we need to be careful to not spend too much time "fixing" debt, while introducing potential bugs and getting distracted from the main development.
Personally my wish list has also these:

We lack a bit of structure in the decision tree, every feature requires changes in quite a few functions.
Style / coding rules. Start extremely simple, e.g. trailing spaces, whitespace rules and perhaps some indentation rules.
Unit tests: Bring style and unit tests to Github actions, every PR can be tested.

Are authorization/authentication methods related to modem or rfid or can we generalize?

If we'd ever introduce vehicle OR user profiles or something, how does it work then?

Good point actually. I suppose introducing a feature that would allow managing device/user profiles including easy management through the web interface would already cover most of the real-world use-cases. We can probably store the RFID tag id's in the same format and store as the EVCCID's. Added bonus; RFID tags would become editable through the API if we do this right.

I feel there is some technical debt, but we need to be careful to not spend too much time "fixing" debt, while introducing potential bugs and getting distracted from the main development.

Agreed!

Personally my wish list has also these:

We lack a bit of structure in the decision tree, every feature requires changes in quite a few functions.
Style / coding rules. Start extremely simple, e.g. trailing spaces, whitespace rules and perhaps some indentation rules.
Unit tests: Bring style and unit tests to Github actions, every PR can be tested.

I think these would be the logical next step for the project to reach the next level in maturity. Starting out with some lint/IDE configs that can be shared would already go a long way. Especially since most of us are using VSCode? (just guessing here tho). Unit tests would be nice and Github Actions are great!

I have been trying to get basic SPI communication between a YellowBeet and a ESP32-S3 to work.
I recorded some spi traces of the QCA7005, maybe they help to develop the software for the ESP: https://github.com/uhi22/Ioniq28Investigations/blob/main/CCM_ChargeControlModule_PLC_CCS/CCM_SPI_powerOn_and_SLAC_until_contractAuth.txt Following with big interest.

Regarding the iX3 SchemaID topic, pushed some fixes. Ready for testing. https://github.com/uhi22/pyPLC/issues/9#issuecomment-1610098576

2 of out 3 succesful tries, but the SoC (75% is correct) doesn't get transferred to the SmartEVSE?

 We are the SECC. Sending SDP response.
Jun 28 08:41:09 rpievse python3.9[2137]: SDP payload (20bytes) = FE 80 00 00 00 00 00 00 DB 7C 36 04 B2 2B C7 CF 3B 0E 10 00
Jun 28 08:41:09 rpievse python3.9[2137]: V2Gframe (28bytes) = 01 FE 90 01 00 00 00 14 FE 80 00 00 00 00 00 00 DB 7C 36 04 B2 2B C7 CF 3B 0E 10 00
Jun 28 08:41:09 rpievse python3.9[2137]: [1004027ms] Connection from ('fe80::ee65:ccff:feb6:85dc', 49155, 0, 4)
Jun 28 08:41:09 rpievse python3.9[2137]: [SNIFFER] EXI from 49155 to 15118 (34bytes) = 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 00 00 40
Jun 28 08:41:09 rpievse python3.9[2137]: [1004061ms] [EVSE] In state WaitForSupportedApplicationProtocolRequest, received (42bytes) = 01 FE 80 01 00 00 00 22 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 00 00 40
Jun 28 08:41:09 rpievse python3.9[2137]: [1004076ms] [EVSE] {
Jun 28 08:41:09 rpievse python3.9[2137]: "msgName": "supportedAppProtocolReq",
Jun 28 08:41:09 rpievse python3.9[2137]: "info": "34 bytes to convert",
Jun 28 08:41:09 rpievse python3.9[2137]: "error": "",
Jun 28 08:41:09 rpievse python3.9[2137]: "result": "Vehicle supports 1 protocols.
 Extracting SoC parameters via DC
Jun 28 08:41:10 rpievse python3.9[2137]: Received SoC status from ChargeParameterDiscoveryReq.
Jun 28 08:41:10 rpievse python3.9[2137]:     Current SoC 75%
Jun 28 08:41:10 rpievse python3.9[2137]:     Full SoC 100%
Jun 28 08:41:10 rpievse python3.9[2137]:     Energy capacity 27000 Wh
Jun 28 08:41:10 rpievse python3.9[2137]:     Energy request -1 Wh
Jun 28 08:41:10 rpievse python3.9[2137]:     EVCCID ec65ccb685dc
Jun 28 08:41:10 rpievse python3.9[2137]: [1004634ms] [EVSE] responding (49bytes) = 01 FE 80 01 00 00 00 29 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 48 20 40 00 00 C9 90 02 06 20 50 19 30 80 C0 C8 02 06 4C 80 10 19 01 40 C8 0A 20
Jun 28 08:41:10 rpievse python3.9[2137]: [1004636ms] [EVSE] from 4 entering 4
Jun 28 08:41:10 rpievse python3.9[2137]: [SNIFFER] EXI from 15118 to 49155 (41bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 48 20 40 00 00 C9 90 02 06 20 50 19 30 80 C0 C8 02 06 4C 80 10 19 01 40 C8 0A 20
Jun 28 08:41:10 rpievse python3.9[2137]: [1004675ms] connection closed
Jun 28 08:41:10 rpievse python3.9[2137]: [1004676ms] [EVSE] re-initializing fsmEvse due to broken connection
Jun 28 08:41:10 rpievse python3.9[2137]: [1004676ms] [EVSE] re-initializing fsmEvse
Jun 28 08:41:10 rpievse python3.9[2137]: [1004677ms] Trying to reset the TCP socket
Jun 28 08:41:10 rpievse python3.9[2137]: [1004677ms] pyPlcTcpSocket listening on port 15118
Jun 28 08:41:10 rpievse python3.9[2137]: [1004679ms] The socket is linked the following IP addresses:
Jun 28 08:41:10 rpievse python3.9[2137]: [1004680ms] ::1
Jun 28 08:41:10 rpievse python3.9[2137]: [1004680ms] ::1
Jun 28 08:41:10 rpievse python3.9[2137]: [1004680ms] ::1
Jun 28 08:41:10 rpievse python3.9[2137]: [1004792ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 28 08:41:12 rpievse python3.9[2137]: [1007471ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jun 28 08:41:15 rpievse python3.9[2137]: [1010154ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5

@fluppie makes sense, as pyPLC repo already includes changes of @arpiecodes. Whereas the serkri repo doesn’t yet. You need to conpile the fork of @arpiecodes and put that on your smartevse to make things work.

Compiled the test branch of his fork but the result doesn't get transferred to the SmartEVSE.
@arpiecodes is something different in your pyPlc.ini? This is mine: pyPlc.ini.txt

Compiled the test branch of his fork but the result doesn't get transferred to the SmartEVSE. @arpiecodes is something different in your pyPlc.ini? This is mine: pyPlc.ini.txt

@fluppie I think I see the issue. You need to provide the full callback URL inside the soc_callback_endpoint config var. For example; soc_callback_endpoint = http://<IP_ADDRESS>/ev_state.

@arpiecodes If you doubt the version of the firmware you could also apply https://github.com/serkri/SmartEVSE-3/pull/160 to the serkri master, and flash that.
It is still a draft so I'm waiting for Jorit to finalize it.

@arpiecodes If you doubt the version of the firmware you could also apply serkri#160 to the serkri master, and flash that. It is still a draft so I'm waiting for Jorit to finalize it.

Got it. Bit busy with work right now, but I will push the requested changes in the evening.

@arpiecodes No hurry; to be clear, since all current users (being Arend Jan and you 😁) agree on the API you propose, you can leave that as it is. No use in disturbing all your experiments with bureaucracy. So its only Arend Jan's remarks on your do-list.

soc_callback_endpoint = http://<IP_ADDRESS>/ev_state did the trick @arpiecodes :-)
I also had to disable chademo and changed the ev capacity to match more with my car.
Over OBD the car reports it's real capacity, but looks like it's not in the ChargeParameterDiscoveryReq

Note to self:
When setting up two RedBeet-E modules, one as EVSE (connected to ESP32) and the other as PEV (raspberry pi running PevNoGui.py)
It helps a -lot- if you reprogram the PEV module, so it acts as a RedBeet-P, instead of a RedBeet-E.
Without doing that, there is no communication possible between the modules. Makes sense, if you think about it ;-)
Forgot to do that...argh.
Here is how to reprogram the RedBeet-E to PEV mode:
plctool -i<eth port> -p original.pib  <Your mac addr of red beet>
cp original.pib pev.pib
setpib pev.pib 74 hfid "PEV"
setpib pev.pib F4 byte 1
setpib pev.pib 1653 byte 1
setpib pev.pib 1C98 long 10240 long 102400
plctool -i<eth port> -P pev.pib <Your mac addr of red beet>

used ArendJanKramer's code as a template.

Yes, definitely, lesson learnt :-)

Since people expressed the desire to redesign the API, but OT here, please enter your thoughts here:
https://github.com/serkri/SmartEVSE-3/discussions/163
(especially contributors @arpiecodes and @ArendJanKramer )

Reading the QCA700X's signature register works now. So i can identify the chip on the SPI bus. Baby steps...

Walking in the same direction, also with small steps. Reading the QCAs software version with the ESP32 works: https://github.com/uhi22/ccs32berta

Nice. I have uploaded my project (WIP) here https://github.com/SmartEVSE/ESP32-PLC

To all users of the serkri distri: if you want to use the experimental code, please compile with build flag MODEM=1 (or #define MODEM 1 in include/evse.h); the code from Arend Jan and Jorrit caused problems, not only the EVconnected flag working improperly but also incompatibilities with specific EV's (e.g. Renault).
Also the old setting "Modem = Experimental" needs to remain in place; its not an ideal combination but I had to fix this to bring out a new release....

Just upgraded to 1.7.1 and can report it keeps on working :)
Jul 20 23:42:54 rpievse python3.9[3115]: [1934011640ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jul 20 23:42:56 rpievse python3.9[3115]: [1934014318ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jul 20 23:42:59 rpievse python3.9[3115]: [1934016996ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jul 20 23:43:02 rpievse python3.9[3115]: [1934019681ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jul 20 23:43:05 rpievse python3.9[3115]: [1934022361ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jul 20 23:43:07 rpievse python3.9[3115]: [1934024792ms] received SLAC_PARAM.REQ
Jul 20 23:43:07 rpievse python3.9[3115]: [addressManager] pev has MAC EC:65:CC:B6:85:DC
Jul 20 23:43:07 rpievse python3.9[3115]: [1934024793ms] [EVSE] transmitting CM_SLAC_PARAM.CNF
Jul 20 23:43:07 rpievse python3.9[3115]: [1934025038ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jul 20 23:43:07 rpievse python3.9[3115]: [1934025039ms] received MNBC_SOUND.IND
Jul 20 23:43:07 rpievse python3.9[3115]: [1934025040ms] received MNBC_SOUND.IND
Jul 20 23:43:07 rpievse python3.9[3115]: [1934025123ms] received MNBC_SOUND.IND
Jul 20 23:43:07 rpievse python3.9[3115]: [1934025125ms] received MNBC_SOUND.IND
Jul 20 23:43:07 rpievse python3.9[3115]: [1934025126ms] received MNBC_SOUND.IND
Jul 20 23:43:07 rpievse python3.9[3115]: [1934025208ms] received MNBC_SOUND.IND
Jul 20 23:43:07 rpievse python3.9[3115]: [1934025209ms] received MNBC_SOUND.IND
Jul 20 23:43:07 rpievse python3.9[3115]: [1934025210ms] received MNBC_SOUND.IND
Jul 20 23:43:07 rpievse python3.9[3115]: [1934025293ms] received MNBC_SOUND.IND
Jul 20 23:43:07 rpievse python3.9[3115]: [1934025293ms] received MNBC_SOUND.IND
Jul 20 23:43:07 rpievse python3.9[3115]: [1934025294ms] [EVSE] transmitting ATTEN_CHAR.IND
Jul 20 23:43:08 rpievse python3.9[3115]: [1934026188ms] received SLAC_MATCH.REQ
Jul 20 23:43:08 rpievse python3.9[3115]: [1934026189ms] [EVSE] transmitting SLAC_MATCH.CNF
Jul 20 23:43:10 rpievse python3.9[3115]: [1934027730ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jul 20 23:43:12 rpievse python3.9[3115]: [addressManager] pev has IP fe80:0000:0000:0000:ee65:ccff:feb6:85dc
Jul 20 23:43:12 rpievse python3.9[3115]: V2GTP (10bytes) = 01 FE 90 00 00 00 00 02 10 00
Jul 20 23:43:12 rpievse python3.9[3115]: Ok, this was a valid SDP request. We are the SECC. Sending SDP response.
Jul 20 23:43:12 rpievse python3.9[3115]: SDP payload (20bytes) = FE 80 00 00 00 00 00 00 DB 7C 36 04 B2 2B C7 CF 3B 0E 10 00
Jul 20 23:43:12 rpievse python3.9[3115]: V2Gframe (28bytes) = 01 FE 90 01 00 00 00 14 FE 80 00 00 00 00 00 00 DB 7C 36 04 B2 2B C7 CF 3B 0E 10 00
Jul 20 23:43:12 rpievse python3.9[3115]: [1934030332ms] Connection from ('fe80::ee65:ccff:feb6:85dc', 49154, 0, 4)
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030363ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jul 20 23:43:13 rpievse python3.9[3115]: [SNIFFER] EXI from 49154 to 15118 (34bytes) = 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 00 00 40
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030366ms] [EVSE] In state WaitForSupportedApplicationProtocolRequest, received (42bytes) = 01 FE 80 01 00 00 00 22 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 00 00 40
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030381ms] [EVSE] {
Jul 20 23:43:13 rpievse python3.9[3115]: "msgName": "supportedAppProtocolReq",
Jul 20 23:43:13 rpievse python3.9[3115]: "info": "34 bytes to convert",
Jul 20 23:43:13 rpievse python3.9[3115]: "error": "",
Jul 20 23:43:13 rpievse python3.9[3115]: "result": "Vehicle supports 1 protocols. ProtocolEntry#1 ProtocolNamespace=urn:din:70121:2012:MsgDef Version=2.0 SchemaID=0 Priority=1 ",
Jul 20 23:43:13 rpievse python3.9[3115]: "schema": "appHandshake",
Jul 20 23:43:13 rpievse python3.9[3115]: "AppProtocol_arrayLen": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "NameSpace_0": "urn:din:70121:2012:MsgDef",
Jul 20 23:43:13 rpievse python3.9[3115]: "Version_0": "2.0",
Jul 20 23:43:13 rpievse python3.9[3115]: "SchemaID_0": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "Priority_0": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "debug": ""
Jul 20 23:43:13 rpievse python3.9[3115]: }
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030384ms] [EVSE] The car supports 1 schemas.
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030385ms] [EVSE] The NameSpace urn:din:70121:2012:MsgDef has SchemaID 0
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030386ms] [EVSE] Detected DIN
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030400ms] [EVSE] responding (12bytes) = 01 FE 80 01 00 00 00 04 80 40 00 00
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030401ms] [EVSE] from 0 entering 1
Jul 20 23:43:13 rpievse python3.9[3115]: [SNIFFER] EXI from 15118 to 49154 (4bytes) = 80 40 00 00
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030463ms] [EVSE] In state WaitForSessionSetupRequest, received (22bytes) = 01 FE 80 01 00 00 00 0E 80 9A 00 40 11 D0 1B B1 97 32 DA 17 70 00
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030475ms] [EVSE] {
Jul 20 23:43:13 rpievse python3.9[3115]: "msgName": "SessionSetupReq",
Jul 20 23:43:13 rpievse python3.9[3115]: "info": "14 bytes to convert",
Jul 20 23:43:13 rpievse python3.9[3115]: "error": "",
Jul 20 23:43:13 rpievse python3.9[3115]: "result": "",
Jul 20 23:43:13 rpievse python3.9[3115]: "schema": "DIN",
Jul 20 23:43:13 rpievse python3.9[3115]: "g_errn": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.SessionID": "00",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.Notification_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.Signature_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVCCID.bytesLen": "6",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVCCID": "ec65ccb685dc",
Jul 20 23:43:13 rpievse python3.9[3115]: "debug": "Line532"
Jul 20 23:43:13 rpievse python3.9[3115]: }
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030488ms] [EVSE] responding (31bytes) = 01 FE 80 01 00 00 00 17 80 9A 02 00 40 80 C1 01 41 81 C2 11 E0 20 1D 69 68 C0 C0 C0 C0 C0 80
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030490ms] [EVSE] responding (31bytes) = 01 FE 80 01 00 00 00 17 80 9A 02 00 40 80 C1 01 41 81 C2 11 E0 20 1D 69 68 C0 C0 C0 C0 C0 80
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030491ms] [EVSE] from 1 entering 2
Jul 20 23:43:13 rpievse python3.9[3115]: [SNIFFER] EXI from 49154 to 15118 (14bytes) = 80 9A 00 40 11 D0 1B B1 97 32 DA 17 70 00
Jul 20 23:43:13 rpievse python3.9[3115]: [SNIFFER] EXI from 15118 to 49154 (23bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 11 E0 20 1D 69 68 C0 C0 C0 C0 C0 80
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030551ms] [EVSE] In state WaitForServiceDiscoveryRequest, received (22bytes) = 01 FE 80 01 00 00 00 0E 80 9A 02 00 40 80 C1 01 41 81 C2 11 94 00
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030563ms] [EVSE] {
Jul 20 23:43:13 rpievse python3.9[3115]: "msgName": "ServiceDiscoveryReq",
Jul 20 23:43:13 rpievse python3.9[3115]: "info": "14 bytes to convert",
Jul 20 23:43:13 rpievse python3.9[3115]: "error": "",
Jul 20 23:43:13 rpievse python3.9[3115]: "result": "",
Jul 20 23:43:13 rpievse python3.9[3115]: "schema": "DIN",
Jul 20 23:43:13 rpievse python3.9[3115]: "g_errn": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.SessionID": "0102030405060708",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.Notification_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.Signature_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "ServiceCategory_isUsed": "True",
Jul 20 23:43:13 rpievse python3.9[3115]: "debug": "Line508"
Jul 20 23:43:13 rpievse python3.9[3115]: }
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030576ms] [EVSE] responding (27bytes) = 01 FE 80 01 00 00 00 13 80 9A 02 00 40 80 C1 01 41 81 C2 11 A0 01 20 02 41 00 C4
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030578ms] [EVSE] from 2 entering 3
Jul 20 23:43:13 rpievse python3.9[3115]: [SNIFFER] EXI from 49154 to 15118 (14bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 11 94 00
Jul 20 23:43:13 rpievse python3.9[3115]: [SNIFFER] EXI from 15118 to 49154 (19bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 11 A0 01 20 02 41 00 C4
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030791ms] [EVSE] In state WaitForServicePaymentSelectionRequest, received (24bytes) = 01 FE 80 01 00 00 00 10 80 9A 02 00 40 80 C1 01 41 81 C2 11 B2 00 12 80
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030808ms] [EVSE] {
Jul 20 23:43:13 rpievse python3.9[3115]: "msgName": "ServicePaymentSelectionReq",
Jul 20 23:43:13 rpievse python3.9[3115]: "info": "16 bytes to convert",
Jul 20 23:43:13 rpievse python3.9[3115]: "error": "",
Jul 20 23:43:13 rpievse python3.9[3115]: "result": "",
Jul 20 23:43:13 rpievse python3.9[3115]: "schema": "DIN",
Jul 20 23:43:13 rpievse python3.9[3115]: "g_errn": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.SessionID": "0102030405060708",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.Notification_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.Signature_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "SelectedPaymentOption": "ExternalPayment",
Jul 20 23:43:13 rpievse python3.9[3115]: "SelectedService.arrayLen": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "SelectedService.array": "0:1",
Jul 20 23:43:13 rpievse python3.9[3115]: "debug": "Line520"
Jul 20 23:43:13 rpievse python3.9[3115]: }
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030823ms] [EVSE] responding (22bytes) = 01 FE 80 01 00 00 00 0E 80 9A 02 00 40 80 C1 01 41 81 C2 11 C0 00
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030824ms] [EVSE] from 3 entering 4
Jul 20 23:43:13 rpievse python3.9[3115]: [SNIFFER] EXI from 49154 to 15118 (16bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 11 B2 00 12 80
Jul 20 23:43:13 rpievse python3.9[3115]: [SNIFFER] EXI from 15118 to 49154 (14bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 11 C0 00
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030880ms] [EVSE] In state WaitForFlexibleRequest, received (21bytes) = 01 FE 80 01 00 00 00 0D 80 9A 02 00 40 80 C1 01 41 81 C2 10 B8
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030894ms] [EVSE] {
Jul 20 23:43:13 rpievse python3.9[3115]: "msgName": "ContractAuthenticationReq",
Jul 20 23:43:13 rpievse python3.9[3115]: "info": "13 bytes to convert",
Jul 20 23:43:13 rpievse python3.9[3115]: "error": "",
Jul 20 23:43:13 rpievse python3.9[3115]: "result": "",
Jul 20 23:43:13 rpievse python3.9[3115]: "schema": "DIN",
Jul 20 23:43:13 rpievse python3.9[3115]: "g_errn": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.SessionID": "0102030405060708",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.Notification_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.Signature_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "debug": "Line424"
Jul 20 23:43:13 rpievse python3.9[3115]: }
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030908ms] [EVSE] responding (23bytes) = 01 FE 80 01 00 00 00 0F 80 9A 02 00 40 80 C1 01 41 81 C2 10 C0 00 00
Jul 20 23:43:13 rpievse python3.9[3115]: [1934030909ms] [EVSE] from 4 entering 4
Jul 20 23:43:13 rpievse python3.9[3115]: [SNIFFER] EXI from 49154 to 15118 (13bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 B8
Jul 20 23:43:13 rpievse python3.9[3115]: [SNIFFER] EXI from 15118 to 49154 (15bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 C0 00 00
Jul 20 23:43:13 rpievse python3.9[3115]: [SNIFFER] EXI from 49154 to 15118 (36bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 71 90 00 00 0B 20 40 61 10 4E 04 07 0A 8C 30 10 20 50 CA 20 13 20 50 00
Jul 20 23:43:13 rpievse python3.9[3115]: [1934031024ms] [EVSE] In state WaitForFlexibleRequest, received (44bytes) = 01 FE 80 01 00 00 00 24 80 9A 02 00 40 80 C1 01 41 81 C2 10 71 90 00 00 0B 20 40 61 10 4E 04 07 0A 8C 30 10 20 50 CA 20 13 20 50 00
Jul 20 23:43:13 rpievse python3.9[3115]: [1934031040ms] [EVSE] {
Jul 20 23:43:13 rpievse python3.9[3115]: "msgName": "ChargeParameterDiscoveryReq",
Jul 20 23:43:13 rpievse python3.9[3115]: "info": "36 bytes to convert",
Jul 20 23:43:13 rpievse python3.9[3115]: "error": "",
Jul 20 23:43:13 rpievse python3.9[3115]: "result": "",
Jul 20 23:43:13 rpievse python3.9[3115]: "schema": "DIN",
Jul 20 23:43:13 rpievse python3.9[3115]: "g_errn": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.SessionID": "0102030405060708",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.Notification_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "header.Signature_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVRequestedEnergyTransferType": "3",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVChargeParameter_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "DC_EVChargeParameter_isUsed": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "DC_EVStatus.EVRESSSOC": "89",
Jul 20 23:43:13 rpievse python3.9[3115]: "DC_EVStatus.EVReady": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVCabinConditioning_isUsed": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVRESSConditioning_isUsed": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVErrorCode": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "DC_EVErrorCodeText": "NO_ERROR",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumCurrentLimit.Value": "5000",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumCurrentLimit.Multiplier": "-1",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumCurrentLimit.Unit_isUsed": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumCurrentLimit.Unit": "3",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumPowerLimit_isUsed": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumPowerLimit.Value": "25000",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumPowerLimit.Multiplier": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumPowerLimit.Unit_isUsed": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumPowerLimit.Unit": "7",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumVoltageLimit.Value": "4170",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumVoltageLimit.Multiplier": "-1",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumVoltageLimit.Unit_isUsed": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVMaximumVoltageLimit.Unit": "5",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVEnergyCapacity_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVEnergyCapacity.Value": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVEnergyCapacity.Multiplier": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVEnergyCapacity.Unit_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVEnergyCapacity.Unit": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVEnergyRequest_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVEnergyRequest.Value": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVEnergyRequest.Multiplier": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVEnergyRequest.Unit_isUsed": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "EVEnergyRequest.Unit": "0",
Jul 20 23:43:13 rpievse python3.9[3115]: "FullSOC_isUsed": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "FullSOC": "100",
Jul 20 23:43:13 rpievse python3.9[3115]: "BulkSOC_isUsed": "1",
Jul 20 23:43:13 rpievse python3.9[3115]: "BulkSOC": "80",
Jul 20 23:43:13 rpievse python3.9[3115]: "debug": "Line9057Line9090Line9169Line9226Line9260Line400"
Jul 20 23:43:13 rpievse python3.9[3115]: }
Jul 20 23:43:13 rpievse python3.9[3115]: [1934031044ms] [EVSE] Received ChargeParameterDiscoveryReq. Extracting SoC parameters via DC
Jul 20 23:43:13 rpievse python3.9[3115]: Received SoC status from ChargeParameterDiscoveryReq.
Jul 20 23:43:13 rpievse python3.9[3115]:     Current SoC 89%
Jul 20 23:43:13 rpievse python3.9[3115]:     Full SoC 100%
Jul 20 23:43:13 rpievse python3.9[3115]:     Energy capacity 74000 Wh
Jul 20 23:43:13 rpievse python3.9[3115]:     Energy request -1 Wh
Jul 20 23:43:13 rpievse python3.9[3115]:     EVCCID xxxxxxxxxxxx
Jul 20 23:43:13 rpievse python3.9[3115]: [1934031168ms] [EVSE] responding (49bytes) = 01 FE 80 01 00 00 00 29 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 48 20 40 00 00 C9 90 02 06 20 50 19 30 80 C0 C8 02 06 4C 80 10 19 01 40 C8 0A 20
Jul 20 23:43:13 rpievse python3.9[3115]: [1934031169ms] [EVSE] from 4 entering 4
Jul 20 23:43:13 rpievse python3.9[3115]: [SNIFFER] EXI from 15118 to 49154 (41bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 48 20 40 00 00 C9 90 02 06 20 50 19 30 80 C0 C8 02 06 4C 80 10 19 01 40 C8 0A 20
Jul 20 23:43:14 rpievse python3.9[3115]: [1934031391ms] connection closed
Jul 20 23:43:14 rpievse python3.9[3115]: [1934031392ms] [EVSE] re-initializing fsmEvse due to broken connection
Jul 20 23:43:14 rpievse python3.9[3115]: [1934031393ms] [EVSE] re-initializing fsmEvse
Jul 20 23:43:14 rpievse python3.9[3115]: [1934031394ms] Trying to reset the TCP socket
Jul 20 23:43:14 rpievse python3.9[3115]: [1934031395ms] pyPlcTcpSocket listening on port 15118
Jul 20 23:43:14 rpievse python3.9[3115]: [1934031397ms] The socket is linked the following IP addresses:
Jul 20 23:43:14 rpievse python3.9[3115]: [1934031397ms] ::1
Jul 20 23:43:14 rpievse python3.9[3115]: [1934031398ms] ::1
Jul 20 23:43:14 rpievse python3.9[3115]: [1934031398ms] ::1
Jul 20 23:43:15 rpievse python3.9[3115]: [1934033131ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jul 20 23:43:18 rpievse python3.9[3115]: [1934035809ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jul 20 23:43:21 rpievse python3.9[3115]: [1934038484ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jul 20 23:43:23 rpievse python3.9[3115]: [1934041163ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
Jul 20 23:43:26 rpievse python3.9[3115]: [1934043839ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5

@fluppie or @Uhi22
This is the first time i have written on a GitHub repository, so for a bit of context i will add my setup.
I am using this QCA7000 board with RaspberryPi
https://www.aliexpress.com/item/1005003956180603.html?gatewayAdapt=Msite2Pc
I have a separate AC Charger which i can program to 5% duty cycle PWM and i put the QCA7000 coms in parallel with that.
I have a BMW IX3 which i hooked it up to and made a connection using uhi22/pyPLC running with EVSE mode.
Details of the installation on Raspberry pi were followed from uhi22/pyPLC/installation_on_raspberry.md
The key has to be near the car.
I made a connection of 120 Ohms PP to earth, and the car responds.
I make the CP connection to the car, when then charger sees the 12V to 9V drop and starts the PWM at 5% duty cycle.
It runs +9V, -12V 5% duty cycle and the raspberry go into SLAC and makes the connection and runs through the script.
It gets to ChargeParameterDiscoveryReq as per yours, but then it cuts out with Broken Connection.
I believe you had this problem too, and you resolved it.
Can you help me understand how you resolved it.?
Below is the extract of the trace output before it closed.
The prior details, are similar as you gave above.
The car alarms with problem in DC Charging station when the "broken connection" occurs.
...
"FullSOC": "100",
"BulkSOC_isUsed": "1",
"BulkSOC": "80",
"debug": "Line9057Line9090Line9169Line9226Line9260Line400"
}
[55163ms] [EVSE] Received ChargeParameterDiscoveryReq. Extracting SoC parameters via DC
[55173ms] [EVSE] responding (49bytes) = 01 FE 80 01 00 00 00 29 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 48 20 40 00 00 C9 90 02 06 20 50 19 30 80 C0 C8 02 06 4C 80 10 19 01 40 C8 0A 20
[55225ms] [EVSE] from 4 entering 4
[SNIFFER] EXI from 49154 to 15118 (36bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 71 90 00 00 05 A0 40 61 10 4E 04 07 0A 8C 30 10 20 50 C0 20 13 20 50 00
[SNIFFER] EXI from 15118 to 49154 (41bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 48 20 40 00 00 C9 90 02 06 20 50 19 30 80 C0 C8 02 06 4C 80 10 19 01 40 C8 0A 20
[55286ms] connection closed
[55310ms] [EVSE] re-initializing fsmEvse due to broken connection
[55311ms] [EVSE] re-initializing fsmEvse
[55311ms] Trying to reset the TCP socket
[55332ms] pyPlcTcpSocket listening on port 15118
[55333ms] The socket is linked the following IP addresses:
[55333ms] ::1
[55333ms] ::1
[55334ms] ::1
[55671ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
[58500ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5

I think the best way to further investigate this topic IS to make an ethernet log, using wireshark or tcpdump on the raspberry.

@uhi22 thank you for your early response.
Here i have attached the ethernet log from wireshark on the raspberry.
(i labelled it as .txt for support in Github file transfer. I could load it directly in wireshark, or it could be relabelled .pcapng as the original file type)
Thank you for any support.
ix3_run.txt

I stored the ix3_run.txt as pcap file, and used two methods to evaluate the content:

use https://github.com/uhi22/pyPLC/blob/master/pcapConverter.py to extract the content of the EXI messages. Here we see, that the vehicle reports a full battery in the ChargeParameterDiscoveryReq: "DC_EVStatus.EVRESSSOC": "100". This could lead to the situation, that the car does not proceed in the charging process, because it sees no need to be charged.
use wireshark to inspect the TCP traffic. Here we see, that at 18.273s the car sends a TCP frame which has the RESET flag set. This means, the car actively closes the connection. I guess this is because it is fully charged.

Summarized: This could be a "normal" behavior depending on the implementation on car side. Some cars do not even start a communication if the battery is full. Your seems to report the full battery and then close the connection.
It would be interesting whether the behavior changes if the SOC is lower.

Maybe the car does not like the ChargeParameterDiscoveryRes, because it does not contain valid units. Instead, the decoder sees "hours", e.g. here: EVSEMaximumPowerLimit.Unit": "h"
To resolve this, need to update the OpenV2Gx (https://github.com/uhi22/OpenV2Gx/blob/68850c94ecc95b0f67099463ade9176efcecf035/src/test/main_commandlineinterface.c#L1304C52-L1304C52) to write the Unit_isUsed=1 for all signals.

An other potential root cause could be, that we report "DC_EVSEStatus.EVSEIsolationStatus": "1", which means "valid". On real charger, we see that they report 0, which means dinisolationLevelType_Invalid. Maybe the car expects the "Invalid" at this step.

As a beginner, I want to ask basic question - do you read these values directly from CP pin via TCP? You capture them, scrape and project as information? The car sends information not as coded data, but for example "The SOC is xx %"?

As a beginner, I want to ask basic question - do you read these values directly from CP pin via TCP? You capture them, scrape and project as information? The car sends information not as coded data, but for example "The SOC is xx %"?

The car and the charging controller use PLC communication over the CP and PE pins. It's like having those AV HomePlugs that allow you to communicate over power lines; same basic concept.
The established PLC communication channel allows for your car and charge controller to talk to each other on IP level (so, indeed talk over TCP). The messages exchanged over TCP are standardised.
You can read more about it here; https://ltu.diva-portal.org/smash/get/diva2:1546405/FULLTEXT01.pdf

@uhi22 wrote
“[Edit] Pushed an update: https://github.com/uhi22/OpenV2Gx/commit/d0e22816ace99ff77b72bcb45273580ea65211a9. Please pull and compile the OpenV2G
”
I will test it in approx 2 weeks following vacation.
At same time I am testing switch iso15118 and I can compare differences in the car communications.