Open giguerator opened 9 months ago
Hi @giguerator,
Thanks for submitting your issue. This is very likely a bug in the old firmware. Please update your board to the newest firmware (V01_00_07). If your issue still persists, feel free to reach out to us again. In that case we will need further logs from both UART and Port Mirror.
Best regards, Niklas Stoffers
Hi Niklas,
Thanks for the response. Where do I download the V01_00_07 FW version? My colleague tried to download it from your PLC website but could not find it.
Hi @giguerator,
Do you have access to the CODICO download area? You should be able to find the mentioned firmware there. If you are missing this access please contact CODICO so that they can give you access to it.
Best regards, Niklas Stoffers
Hi Niklas,
I got the FW version you suggested. I am trying it out today. Keep you posted.
@nststx , one question though, which version of FreeV2G should we use with FW V01_00_07?
Please use the EV_v1.0.7_0
tag together with the V01_00_07 firmware.
Best regards, Niklas Stoffers
Hi @nststx,
We do not have the time to setup our white beet for capturing UART and port mirror at the moment.
What I can tell you is that setting the energy transfer mode works with V01_00_07. However, I am not able to set the priority on DIN vs ISO protocol or set the whitbeet to support only DIN. The FW does not accept a protocol_count =1 in the SetConfiguration method (we get and a "Module did not accept command" error with a blank return code). Also, inverting the order in the protocols list does not change the priority sent to the EVSE on PLC.
Hey @giguerator,
I tested your use case. I used the latest master branch of FreeV2G and a Whitebeet Evse on FW v2.0.1 and a Whitebeet Ev on FW v1.0.7, both connected via ethernet. I created a virtual environment, installed the dependencies, modifed ev.json
for configuration and started the application:
python3 -m venv .venv
source .venv/bin/activate
pip install --pre scapy[basic]
pip install Cython
pip install python-libpcap
sudo -E .venv/bin/python3 Application.py -r EV -m c4:93:00:34:d5:45 -i eth-wb1-ev -c ev.json eth -p
I also started the EVSE at the same time:
sudo -E .venv/bin/python3 Application.py -r EVSE -m c4:93:00:34:a5:1f -i eth-wb1-evse eth
I got a successful charging session using DIN.
I attached the patch file with the modifications to ev.json
for your reference:
I also needed to modify Ev.py
, we are investigating this issue right now.
Please place it into your copy of FreeV2G and run:
git apply din_charging.txt
Then restart your charging session, but this time tell the application to use the modified ev.json
file with -c ev.json
. Please let me know if this is resolving your issues.
If not please create uart and wireshark log files. Setting up port mirror is just a matter of starting the application with the -p
parameter and starting a wireshark/tcpdump log on your ethernet interface used to connect to your Whitebeet.
Best regards, lho
@lho-stx thanks!
The modification in ev.py was what we were missing. This solves our problem.
Hey @giguerator,
I am happy that your issue was resolved. There is a bug in the Whitebeet firmware when using DIN and setting a charging profile. This will be fixed in the new PEV firmware. In the meantime you (and everyone else who has this problem) can use the patch file as a workaround.
Best regards, lho
Your Setup Platform: PEV Firmware Version: i.e. V01_00_04 Host Controller Interface: Ethernet Host: FreeV2G (EV_v1.0.4_0)
Describe the bug If ISO15118 is selected by the EVSE and the energy transfer mode is set to DC extended, the whitebeet still sends out DC core.
To Reproduce That a charging session with energy transfer mode set to dc extended (dc core not supported, dc extended supported). Ensure the EVSE selects ISO15118.
Expected behavior Whitebeet should advertise supporting dc extended.
Logs evse.txt ev.txt Man in the middle captures from Keysight CDS
Additional context Add any other context about the problem here.