Closed kramzarales closed 1 year ago
Hi @kramzarales ,
can we first verify that you are using the correct version of FreeV2G for your WHITE-beet firmware?
What confuses me is the following line:
Host: FreeV2G (EVSE_v1.1.7_1) Plug_and_charge branch
I think you want to use SPI with version 1.1.7. SPI wasn't available in this version. You can use the tag https://github.com/Sevenstax/FreeV2G/tree/EVSE_v1.1.7_1 and merge the SPI interface commit https://github.com/Sevenstax/FreeV2G/commit/331add2a4abf6a31998fb7152d10c075a7cf3f6e, but I don't know if you run into conflicts.
My recommondation would be to use the latest version of the master branch (the plug and charge branch was merged today) and update your WHITE-beet to 2.0.1. The plug and charge branch is indended to be used with the version 2.0.1.
Hi,
Thank you for the hint. The issue seemed to be in that Whitebeet was running 1.1.7. After i updated it this error is resolved and the vehicle connects correctly. Unfortunatly after another error appears, where after i type "yes" to autherize the vehicle, i do not recieve a response back from the vehicle and the program times out. I attached a picture of the log. Do i have to type a command or is this a bug?
This was tested directly on Renault Zoe 53kw (2020)
Can you add the line
evse.whitebeet.networkConfigSetPortMirrorState(1)
before evse.loop()
in Application.py, connect an ethernet cable dirctly from your PC to the WHITE-beet and start a wireshark capture? This should mirror the PLC data to the ethernet port.
You can also see what happens when you comment out the line:
https://github.com/Sevenstax/FreeV2G/blob/623e5288bd80a809cec2d27f7869cd6e711dd6a7/Evse.py#L235
and set auth_str = "yes"
Thank you for the sugestion.
I set auth_str = "yes"
, but while it skipped the input prompt, it still hangs on the same error.
I have tried setting evse.whitebeet.networkConfigSetPortMirrorState(1) , but python just returns AttributeError: Evse object has no attribute "whitebeet"
Is there something i have missed?
Hi @kramzarales
I have a setup here with a Raspberry Pi connected via SPI to the Whitebeet and the latest version from the master branch. With the changes from https://github.com/Sevenstax/FreeV2G/issues/99#issuecomment-1302200348 everything works as expected. Can you double check if your setup is clean without any other changes except the ones I proposed.
Hi,
OK, i manage to solve the issue and did a packet capture. I am sending the wireshark capture from the time of starting the script with sudo python3 Application.py spi -i spidev0.0 -m ----MAC--- -r EVSE untill it times out from not recieveing a response and exits
Is it working now? In the log I see that the EV isn't responding after the whitebeet sent the authorization response.
If you still have a problem please change the energy transfer mode for DIN to DC_extended.
No, we are still trying to get it to work. How exactly can we change the energy transfer mode correctly? Do we do it like this:
self.evse_config = {
"evse_id_DIN": '+49*123*456*789',
"evse_id_ISO": 'DE*A23*E45B*78C',
"protocol": [0, 1],
"payment_method": [0],
"energy_transfer_mode": 3,
"certificate_installation_support": False,
"certificate_update_support": False,
}
Also is it possible to set it to 4 and it will work? Since that is the transfer mode for AC single phase, which is what we are aiming for.
I hava managed to resolve the issue and FreeV2G is now working correctly. The solution was to set "energy_transfer_mode": [1],
Your Setup Platform: EVSE Firmware Version: i.e. V01_01_07 Host Controller Interface: SPI Host: FreeV2G (EVSE_v1.1.7_1) Plug_and_charge branch
Describe the bug When connecting the whitebeet module to a Renault ZOE (52kw 2020 model), the SLAC process starts correctly, but eventualy the softwere errors out at the starting V2G part, with the error: "Module did not accept command 27:60, return code: 4".
To Reproduce Connect whitebeet E module with relevant firmwere to type 2 charging cable and run softwere on host controler (raspbarry pi 3B) with command: sudo python3 Application.py spi -i spidev0.0 -m ----MAC--- -r EVSE
Expected behavior charging process begins like it does correctly when using Ethernet version of the softwere.
Additional context softwere traceback: