search

Sevenstax / FreeV2G

Python based Host MPU Application for the use with 8DEVICES WHITE-BEET Embedded ISO15118 Module modules to realize IEC/ISO15118 and DIN70121 conform charging communication between electric vehicles (PEV) and elevtric vehicle supply equipment (EVSE). FreeV2G can e.g. been used with a Raspberry Pi.
Other
51 stars 25 forks source link

Why does the White Beet board communicate with controller in EVSE mode but not in EV mode using FreeV2G?? #297

Closed Hipowerguy closed 3 months ago

Hipowerguy commented 4 months ago

Why does the WB board communicate with controller in EVSE mode but not in EV mode using FreeV2G?

I use a recent WB carrier board EI 1.1 and the current FreeV2G to implement a EVSE to EV test setup. The problem is that in the EV mode, the WB doesn't respond. I get the following:

(.venv) marco@Debian:~/FreeV2G$ sudo .venv/bin/python3 Application.py eth -i enp0s8 -m C4:93:00:48:B1:D3 -r EV Welcome to Codico Whitebeet EV reference implementation Initiating framing interface iface: ETH, name: enp0s8, mac: C4:93:00:48:B1:D3 WHITE-beet-PI firmware version: V02_01_00 Set the CP mode to EV Traceback (most recent call last): File "/home/marco/FreeV2G/Application.py", line 48, in ev.loop() File "/home/marco/FreeV2G/Ev.py", line 684, in loop self._initialize() File "/home/marco/FreeV2G/Ev.py", line 101, in _initialize self.whitebeet.controlPilotSetMode(0) File "/home/marco/FreeV2G/Whitebeet.py", line 322, in controlPilotSetMode self._sendReceiveAck(self.cp_mod_id, self.cp_sub_set_mode, mode.to_bytes(1, "big")) File "/home/marco/FreeV2G/Whitebeet.py", line 194, in _sendReceiveAck raise Warning("Module did not accept command {:x}:{:x}, return code: {}".format(mod_id, sub_id, response.payload[0])) Warning: Module did not accept command 29:40, return code: 5

But asking for the EVSE version I get something better which seems to eliminate basic communication issues. It seems to be strictly related to the EV configuration. I use what came with FreeV2G.

(.venv) marco@Debian:~/FreeV2G$ sudo .venv/bin/python3 Application.py eth -i enp0s8 -m C4:93:00:48:B1:D3 -r EVSE Welcome to Codico Whitebeet EVSE reference implementation Initiating framing interface iface: ETH, name: enp0s8, mac: C4:93:00:48:B1:D3 WHITE-beet-EI firmware version: V02_01_00 Set the CP mode to EVSE Set the CP duty cycle to 100% Start the CP service Start SLAC in EVSE mode Wait until an EV connects

I swapped the two WB boards (updating the MAC address in the call) and even tried using a PC and a Raspberry pi as the controller with exactly the same result.

Is there an issue with the EV version WHITE-beet-EI firmware version: V02_01_00?

I read that the EV had an issue with FreeV2G V1.06 so I tried V1.04 with the same result.

Here is the terminal recording: [ 27.473] [NOTICE] APL-ETH: Got link: [ 27.473] [NOTICE] APL-ETH: Interface: eth1 [ 27.474] [NOTICE] APL-ETH: MAC: C4:93:00:48:B1:D3 [ 29.314] [NOTICE] APL-MAIN: [ 29.314] [NOTICE] APL-MAIN: ============================= [ 29.315] [NOTICE] APL-MAIN: NEW LAN CONFIGURATION (IPv6): [ 29.315] [NOTICE] APL-MAIN: for IP Config handle [fe01] [ 29.316] [NOTICE] APL-MAIN: IPv6 Addresses: [ 29.317] [NOTICE] APL-MAIN: Link-Local: fe........ [ 29.318] [NOTICE] APL-MAIN: Local: 0:0:0:0 : 0:0:0:0 [ 29.318] [NOTICE] APL-MAIN: DNS1: ....... [ 29.319] [NOTICE] APL-MAIN: DNS2: .......... [ 29.320] [NOTICE] APL-MAIN: ============================= [ 29.321] [NOTICE] APL-MAIN: [ 141.718] [NOTICE] SLAC: stxSLAC_Stop() [ 141.719] [WARN ] V2GCPS: stxV2GCPS_Stop() - Failed

lho-stx commented 4 months ago

Hey @Hipowerguy,

firmware version 2.1.0 is an EVSE based firmware and does not work with the EV demo code. The latest EV firmware version is v1.0.6. The issue related to this version are resolved, so please flash this version to your board and try again!

Thank you, lho

Hipowerguy commented 4 months ago

Thanks for the reply.

I am not an expert with this kind of product. Do you mean load v1.0.6. in the WB board or for the FreeV2G?

Marco

From: lho-stx @.> Sent: Tuesday, April 2, 2024 2:45 AM To: Sevenstax/FreeV2G @.> Cc: Hipowerguy @.>; Mention @.> Subject: Re: [Sevenstax/FreeV2G] Why does the White Beet board communicate with controller in EVSE mode but not in EV mode using FreeV2G?? (Issue #297)

Hey @Hipowerguy https://github.com/Hipowerguy ,

firmware version 2.1.0 is an EVSE based firmware and does not work with the EV demo code. The latest EV firmware version is v1.0.6. The issue related to this version are resolved, so please flash this version to your board and try again!

Thank you, lho

- Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/297#issuecomment-2031196573 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AVZ63FEBGZVZCXFMOXVOGNDY3 JHWNAVCNFSM6AAAAABFQLEEOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZRGE4TM NJXGM . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AVZ63FHBDG5D5ENYDJUJQT3Y3JHWNA5CNFS M6AAAAABFQLEEOWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT ZCGMZ2.gif Message ID: @. @.> >

Hipowerguy commented 4 months ago

Ok, If I underestand well, while FreeV2G has the code for the two modes, you have different versions for EVSE and EV.

Why is that? May I suggest that you make this clearer in the instructions?

Thanks!

lho-stx commented 4 months ago

Hey @Hipowerguy,

Yes you need to use the latest firmware for your product with the latest master branch of this repository. If you have a PEV based board you need to flash v1.0.6 to your board, if you have an EVSE based board you need to flash the v2.1.0 firmware. Please get the latest version from CODICO website. This is especially important vor the PEV firmware, as there was a problem with an older version of it. When you download it now from CODICO website it is the correct one.

Yes, there are indeed two hardware boards and you need to start FreeV2G with a different set of parameters. In the introduction section in the repository ReadeMe there is an overview over the different firmware versions mapped to the tags of this repo, it also links to the CODICO product pages.

I will discuss if we create a more differentiated documentation internally.

You can also have a look into the quick start guide in the wiki. It is for EVSE, but most of the things also apply to PEV, you just need to start the application with -r EV instead of -r EVSE.

Best regards, lho

Hipowerguy commented 4 months ago

OK, I have ordered a PEV version of the board.
Should get it in a week or so.

Thanks,

lho-stx commented 4 months ago

The please flash the v1.0.6 and try to run FreeV2G with the -r EV parameter.

Please let me know if this is wokring for you!

Best regards, lho

Hipowerguy commented 4 months ago

I received the PEV board with firmware V1.0.7, I assume that this one doesn't have any of the issues discussed above. Is this correct?

Also, where do I see the FreeV2G revision number once downloaded into the Raspberry Pi? I looked into the Application and teh README files without seing it.

Hipowerguy commented 4 months ago

Hello Iho,

I am having a similar issue as Kristanpivk123 with my two White Beet (WB) boards, one EVSE V2.1.0 and the other one EV V1.0.7. See: https://github.com/Sevenstax/FreeV2G/issues/263

Both WB are running from one Raspberry Pi 4 board running Debina (Linux). I open a different instance of FreeV2G for each WB and it seems to work until connection on V2G mode. The EVSE board times out after 30 seconds just like Kristanpivk123's case at time index 107.

I read with interest your suggestions and the work that Kristanpivk123 did but I am puzzled as to why the Ethernet connection would have an effect on the EVSE timing out when waiting for the EV. Did you figure out why?

Thanks,

Marco

P.S. The attached picture gives both monitors. 20240414_150440 2

This is the log for the EV board:

[ 58.108] [NOTICE] SLAC: stxSLAC_Stop() [ 58.111] [WARN ] V2GCPS: stxV2GCPS_Stop() - Failed [ 58.130] [NOTICE] SLAC: stxSLAC_Start() [ 58.158] [NOTICE] V2GCPS: Changed Max Current EV State (7) [ 58.158] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler() [ 58.159] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler() [ 58.160] [NOTICE] V2GCPS: # V2GCPS_INFOTYPE_CP_DUTY_CYCLE [ 58.160] [NOTICE] V2GCPS: Duty cycle is 1000 permill [ 75.702] [NOTICE] V2GCPS: Changed Max Current EV State (1) [ 75.702] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler() [ 75.703] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler() [ 75.704] [NOTICE] V2GCPS: # V2GCPS_INFOTYPE_CP_DUTY_CYCLE [ 75.704] [NOTICE] V2GCPS: Duty cycle is 57 permill [ 80.747] [NOTICE] SLAC: stxSLAC_StartSlacMatchingProcess() [ 80.855] [WARN ] SLAC: # SLAC_STATE_RECV_SLAC_PARAM_CNF - TIMEOUT [ 84.062] [NOTICE] PLCV-HL: PIB File was updated => Download PIB without reset [ 84.187] [NOTICE] PLCV-HL: PIB File was updated => Download PIB without reset [ 84.291] [NOTICE] APL-ETH: Got link: [ 84.291] [NOTICE] APL-ETH: Interface: plc0 [ 84.292] [NOTICE] APL-ETH: MAC: C4:93:00:34:CD:00 [ 84.293] [NOTICE] SLAC: SLAC matching was successful! [ 84.294] [NOTICE] SLACSERV: # NC_SLAC_SUCCESS [ 84.310] [NOTICE] V2GSVC: Starting in EV mode. [ 107.867] [NOTICE] APL-MAIN: [ 107.867] [NOTICE] APL-MAIN: ============================= [ 107.868] [NOTICE] APL-MAIN: NEW LAN CONFIGURATION (IPv6): [ 107.868] [NOTICE] APL-MAIN: for IP Config handle [fe00] [ 107.869] [NOTICE] APL-MAIN: IPv6 Addresses: [ 107.870] [NOTICE] APL-MAIN: Link-Local: fe80:0:0:0 : c693:ff:fe34:cd00 [ 107.871] [NOTICE] APL-MAIN: Local: 0:0:0:0 : 0:0:0:0 [ 107.871] [NOTICE] APL-MAIN: DNS1: 2001:4860:4860:0 : 0:0:0:8888 [ 107.872] [NOTICE] APL-MAIN: DNS2: fd00:0:0:0 : be05:43ff:fe44:5280 [ 107.873] [NOTICE] APL-MAIN: ============================= [ 107.874] [NOTICE] APL-MAIN: [ 115.875] [WARN ] APL-ETH: # Unhandled Ethernet notifycode 365

lho-stx commented 4 months ago

Hey @Hipowerguy,

good to see that you made some progress!

Regarding the FreeV2G version:

It is tied to the git tag. You can always use the latest FreeV2G version with the latest firmware. If you want to use an older firmware version (which I do not recommend) you can checkout the corresponding FreeV2G tag.

Regarding the timeout issue:

I see that you are running both FreeV2G instances from a single Raspberry Pi 4, but you are using a single ethernet interface. I assume you are using some network gear (router / switch) with it, to connect to multiple Whitebeets. This setup may work in theory when setup correctly (with additional efforts on creating VLANs), but it is not officially supported. It is known to cause issues.

Please try connecting to each board via a separated ethernet interface and without any router / switch in between. Let me know if this fixes your issue!

Best regards, lho

Hipowerguy commented 4 months ago

Hi Iho,

Thanks for the tip but the result is even worse when placing the EVSE board alone on my PC. It doesn't even communicate with the board using direct or reversed Ethernet cable. See below.

<-->

Something is missing or incorrect in your WB module. It is not just me; many others have had similar issues. Blaming the computer or the operating system is the wrong thing to do.

<-->

Best regards,

Marco Tremblay P.Eng. M.Eng.

CTO

Hi-Power Solutions Inc. / Solutions Haute Puissance Inc.

514-624-3639

Hi-Power Solutions Inc. (hipowersolutions.ca) https://hipowersolutions.ca/

Initiating framing interface

iface: ETH, name: enp0s8, mac: C4:93:00:48:B1:D3

Traceback (most recent call last):

File "/home/marco/FreeV2G/Whitebeet.py", line 169, in _sendReceive

response = self.framing.receive_next_frame(filter_mod=[mod_id, 0xFF],

filter_sub={ mod_id: sub_id }, filter_req_id=req_id, timeout=time_end - time_start)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "/home/marco/FreeV2G/FramingInterface.py", line 249, in receive_next_frame

raise AssertionError("Frame reception timed out")

AssertionError: Frame reception timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

File "/home/marco/FreeV2G/Whitebeet.py", line 113, in init

self.version = self.systemGetVersion()

               ^^^^^^^^^^^^^^^^^^^^^^^

File "/home/marco/FreeV2G/Whitebeet.py", line 307, in systemGetVersion

response = self._sendReceiveAck(self.sys_mod_id,

self.sys_sub_get_firmware_version, None)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^

File "/home/marco/FreeV2G/Whitebeet.py", line 190, in _sendReceiveAck

response = self._sendReceive(mod_id, sub_id, payload)

           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "/home/marco/FreeV2G/Whitebeet.py", line 184, in _sendReceive

raise ConnectionError("Problem with send/receive - Please check your

connection!")

ConnectionError: Problem with send/receive - Please check your connection!

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

File "/home/marco/FreeV2G/Application.py", line 52, in 

with Evse(args.interface_type, args.interface, args.mac) as evse:

     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "/home/marco/FreeV2G/Evse.py", line 8, in init

self.whitebeet = Whitebeet(iftype, iface, mac)

                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "/home/marco/FreeV2G/Whitebeet.py", line 120, in init

raise ConnectionError("Failed to initialize the framing interface on

\"{}\"".format(self.framing.sut_interface))

ConnectionError: Failed to initialize the framing interface on ""

From: lho-stx @.> Sent: Monday, April 15, 2024 2:35 AM To: Sevenstax/FreeV2G @.> Cc: Hipowerguy @.>; Mention @.> Subject: Re: [Sevenstax/FreeV2G] Why does the White Beet board communicate with controller in EVSE mode but not in EV mode using FreeV2G?? (Issue #297)

Hey @Hipowerguy https://github.com/Hipowerguy ,

good to see that you made some progress!

Regarding the FreeV2G version:

It is tied to the git tag. You can always use the latest FreeV2G version with the latest firmware. If you want to use an older firmware version (which I do not recommend) you can checkout the corresponding FreeV2G tag.

Regarding the timeout issue:

I see that you are running both FreeV2G instances from a single Raspberry Pi 4, but you are using a single ethernet interface. I assume you are using some network gear (router / switch) with it, to connect to multiple Whitebeets. This setup may work in theory when setup correctly (with additional efforts on creating VLANs), but it is not officially supported. It is known to cause issues.

Please try connecting to each board via a separated ethernet interface and without any router / switch in between. Let me know if this fixes your issue!

Best regards, lho

- Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/297#issuecomment-2055597043 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AVZ63FDXBVL4MDSJOTOHLMLY5 NYIDAVCNFSM6AAAAABFQLEEOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJVGU4TO MBUGM . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AVZ63FB3C3GBZ3U7VUU42YDY5NYIDA5CNFS M6AAAAABFQLEEOWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT 2QXV7G.gif Message ID: @. @.> >

lho-stx commented 4 months ago

Hey @Hipowerguy,

I am sorry that you experience these issues, but I need to disagree strongly regarding the ethernet. The Whitebeet modules are being integrated and tested continuously on Debian 12 and Raspberry Pi 4. They are also used by us (as well as by customers) for testing purposes of other software / hardware / products and we never experienced problems once it was all set up properly.

I agree that getting things done with FreeV2G may be tricky sometimes. Customers have different host machine setups (e.g. company issued laptops, network gear, VMs etc.), so we can not keep every possible setup in mind. Therefore we advise to try a native installation of Debian 12 with the Whitebeet connected directly to a ethernet port of the host machine or connecting the Whitebeet via SPI to a Raspberry PI 4. We found solutions for every customer, so I am quiet confident we find a solution that works for you too! You are most likely experiencing problems with setting up FreeV2G correctly, not with the Whitebeet itself.

If you want us to have a look into your environment, please feel free to create log files. Please create wireshark, UART and FreeV2G log files according to this wiki entry.

Please keep in mind that FreeV2G is a demo application to show how to work with the Whitebeet. It is neither intended nor suitable to be run in a productive environment. If you plan to use the Whitebeet in a commercial product.

Your inquiry about direct contact will be forwarded.

Best regards, lho

Hipowerguy commented 4 months ago

Hello Iho,

I am using a virtual machine on my PC running Debian 12 and it doesn't communicate with the ESVE WB board. It only works when running on the Raspberry pi 4 whether a second instance of FreeV2G is running or not.

Here are the USB logs and the Wireshark logs for the exchange that work the best. Both WB boards on the Raspberry Pi board. You already have the screen capture for the two terminals.

I hope that this will shed so light into the issue.

Best regards,

Marco Tremblay P.Eng. M.Eng.

CTO

Hi-Power Solutions Inc. / Solutions Haute Puissance Inc.

514-624-3639

Hi-Power Solutions Inc. (hipowersolutions.ca) https://hipowersolutions.ca/

From: lho-stx @.> Sent: Monday, April 15, 2024 9:09 AM To: Sevenstax/FreeV2G @.> Cc: Hipowerguy @.>; Mention @.> Subject: Re: [Sevenstax/FreeV2G] Why does the White Beet board communicate with controller in EVSE mode but not in EV mode using FreeV2G?? (Issue #297)

Hey @Hipowerguy https://github.com/Hipowerguy ,

I am sorry that you experience these issues, but I need to disagree strongly regarding the ethernet. The Whitebeet modules are being integrated and tested continuously on Debian 12 and Raspberry Pi 4. They are also used by us (as well as by customers) for testing purposes of other software / hardware / products and we never experienced problems once it was all set up properly.

I agree that getting things done with FreeV2G may be tricky sometimes. Customers have different host machine setups (e.g. company issued laptops, network gear, VMs etc.), so we can not keep every possible setup in mind. Therefore we advise to try a native installation of Debian 12 with the Whitebeet connected directly to a ethernet port of the host machine or connecting the Whitebeet via SPI to a Raspberry PI 4. We found solutions for every customer, so I am quiet confident we find a solution that works for you too! You are most likely experiencing problems with setting up FreeV2G correctly, not with the Whitebeet itself.

If you want us to have a look into your environment, please feel free to create log files. Please create wireshark, UART and FreeV2G log files according to this wiki entry https://github.com/Sevenstax/FreeV2G/wiki/guide-creating-log-files .

Please keep in mind that FreeV2G is a demo application to show how to work with the Whitebeet. It is neither intended nor suitable to be run in a productive environment. If you plan to use the Whitebeet in a commercial product.

Your inquiry about direct contact will be forwarded.

Best regards, lho

- Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/297#issuecomment-2056815722 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AVZ63FEOWX5NN7F3ZA7OQ3LY5 PGPDAVCNFSM6AAAAABFQLEEOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJWHAYTK NZSGI . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AVZ63FBEZQVKYQLJDAZ3BSLY5PGPDA5CNFS M6AAAAABFQLEEOWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT 2TCCGU.gif Message ID: < @.> @.>

lho-stx commented 4 months ago

Hey @Hipowerguy,

unfortunately answering issue comments using e-Mail discards the attached files. Please use the github issue tracker in order to upload files. You may need to rename them, because github is not supporting some file types. Please append e.g. '.txt' to files in question.

Just for my understanding: Using the Raspberry Pi charging session runs successfully, or just the communication with one of the Whitebeets?

Using a VM is technically possible, but debugging such a setup is normally out of scope of this issue tracker (you would need to bridge the interfaces). In addition to this, when using a VM you need to tell me if you captured wireshark logs in the VM or from your host. We also can not debug problems related to your virtualization host.

Thank you, lho

Hipowerguy commented 4 months ago

Here they are:

Ethernet Log both boards on RP.zip

lho-stx commented 4 months ago

Hey @Hipowerguy,

Thank you for the log files. Somethings seems strange, because I only see three farming messages, but the PEV is sending SECCDP request at the moment the log file starts.

Nevertheless, it seems you still try to use one ethernet interface in order to communicate with two Whitebeets. This can also be seen in the 'screenshot' you send eralier. This is not supported by FreeV2G (it has no mechanism to differentiate the two Whitebeets e.g. with the MAC addresses). I kindly ask you to use a separated USB interface for each Whitebeet (e.g. by using a ETH-USB adapter) when using FreeV2G.

Best regards, lho

github-actions[bot] commented 3 months ago

This issue has been marked as stale because it has been open for 14 days with no activity. Please update this issue or it will be closed in the next 7 days.

github-actions[bot] commented 3 months ago

This issue was closed because it has been inactive for 7 days since being marked as stale. If your issue still persists, feel free to reopen!