Platform: PEV (WHITE-BEET-PI (EV) Module with Embedded ISO15118 Sw Stack )
Firmware Version: i.e. V01_00_07
Host Controller Interface: Ethernet
Host: Own Implementation
Describe the bug
We are currently using the WHITE-BEET-PI (EV) Module with Embedded ISO15118 Sw Stack in multiple units of a test system for internal use.
Recently we discovered an issue associated with the white-beet module that we never encounter before, and we don’t have a clear view on how to resolve it.
The issue is correlated with the starting of the V2G service (Module-ID: 0x27):
as indicated in the documentation provided with the white-beet module and as done in the example of host controller implementation present in the Sevenstax repository:
Upon receiving the SLAC process was successful message (Module-ID: 0x28 + Sub-ID:0x80) from the white-beet module, our device acting as the host controller sends in sequence the following messages:
- Set Mode to EV (Module-ID: 0x27 + Sub-ID:0x40)
- Set Configuration (Module-ID: 0x27 + Sub-ID:0xa0
- Set DC Charging Parameters (Module-ID: 0x27 + Sub-ID:0xa2)
- Start Session (Module-ID: 0x27 + Sub-ID:0xa9)
NOTE: Our device waits for a response from the white-beet module with the same Module-ID + Sub-ID before sending the next command, but if the any result code is negative, it still sends all the commands in the above block (our charging test is interrupted if any result code is negative).
If everything goes well each of the commands responds with the result code 0x00: Command accepted, and the charging session starts.
But sometimes the white-beet module responds with the following pattern:
- Set Mode to EV (Module-ID: 0x27 + Sub-ID:0x40) --> 0x01: Module is busy; try again later
- Set Configuration (Module-ID: 0x27 + Sub-ID:0xa0 --> 0x11 Wrong state, not in the state to receive the command
- Set DC Charging Parameters (Module-ID: 0x27 + Sub-ID:0xa2) --> 0x11 Wrong state, not in the state to receive the command
- Start Session (Module-ID: 0x27 + Sub-ID:0xa9) --> 0x11 Wrong state, not in the state to receive the command
As the name of the first response code suggests, it may seem that the problem should be solved by sending again the first command until it is accepted.
But in the documentation, we see that for this specific command is present the following description:
Reading the documentation is not clear to us what constitutes as at start or a stop of the V2G service, but we always assumed that that command just needed to be sent before any other of the V2G service, and before sending the command Start Session (0xA9) as done also in the examples from Sevenstax.
Also, it seems that the command should be optional on our model that supports only the EV mode and it should not affect the other commands.
Therefore, we don’t understand why the V2G service is responding with those error codes and if there is something that we could change in our implementation to avoid this sporadic scenario.
To Reproduce
The issue is difficult to reproduce since it happens sporadically.
That makes debugging it quite difficult and time-consuming therefore we hope to leverage your insight on the product to quickly find the origin of the issue and deploy a solution.
Also, we never noticed the issue with the previous version that we used: v01_00_05.
Expected behavior
Each of the V2G service commands responds with the result code 0x00: Command accepted, and the charging session starts.
as it dose on all the charging sesion where the issue is not present.
Logs
the dificulty of reproducing the issue prevented us from having a complete log set.
following there is the interested portion of the log of the comunication between our host controller and the white-beet module
Additional context
The issue has been reported after we deployed a new series of devices that are equipped with a white-beet module with firmware version: 01_00_07.
We can’t associate for sure the issue with the new version, since we were unable to reproduce the issue enough times to come to a certain conclusion.
Maybe there is something that we can change on our side to avoid the issue.
We can only say that as for now we never noticed the issue with the previous version that we used: v01_00_05.
Another thing that we noticed is that the V2G service seems to become stuck when this issue happens.
What I mean is that we could have an arbitrary number of charging sessions where everything is working fine, then this issue happens and after that it will keep happening in any following charging session.
Even after changing CCS outlet or charger.
It disappears only after rebooting the white-beet module by disconnecting it from the power source.
After a white-beet module reboot it starts to work fine again until it happens next time.
Just to mention it, we did try to do a downgrade to see if the issue persisted on the previous version but we were unable to do so with the firmware updater tool provided by Sevenstax.
The tool seems to report a completed update but after checking the firmware version on the device with the appropriate command: Get firmware Version (Module-ID: 0x10 + Sub-ID:0x41) we still see as the reported version: v01_00_07.
when documenting the issue, it has occurred to me that trying to downgrade was the last thing I tried to do in the evening and the day after we were unable to reproduce the issue on that device.
I hope that is just a coincidence and the reported version is the correct version, and the module is still on v01_00_07.
Thank you in advance for your help.
Kind regards
Platform: PEV (WHITE-BEET-PI (EV) Module with Embedded ISO15118 Sw Stack )
Firmware Version: i.e. V01_00_07
Host Controller Interface: Ethernet
Host: Own Implementation
Describe the bug
We are currently using the WHITE-BEET-PI (EV) Module with Embedded ISO15118 Sw Stack in multiple units of a test system for internal use.
Recently we discovered an issue associated with the white-beet module that we never encounter before, and we don’t have a clear view on how to resolve it.
The issue is correlated with the starting of the V2G service (Module-ID: 0x27):
as indicated in the documentation provided with the white-beet module and as done in the example of host controller implementation present in the Sevenstax repository:
Upon receiving the SLAC process was successful message (Module-ID: 0x28 + Sub-ID:0x80) from the white-beet module, our device acting as the host controller sends in sequence the following messages:
NOTE: Our device waits for a response from the white-beet module with the same Module-ID + Sub-ID before sending the next command, but if the any result code is negative, it still sends all the commands in the above block (our charging test is interrupted if any result code is negative).
If everything goes well each of the commands responds with the result code 0x00: Command accepted, and the charging session starts.
But sometimes the white-beet module responds with the following pattern:
As the name of the first response code suggests, it may seem that the problem should be solved by sending again the first command until it is accepted.
But in the documentation, we see that for this specific command is present the following description:
Reading the documentation is not clear to us what constitutes as at start or a stop of the V2G service, but we always assumed that that command just needed to be sent before any other of the V2G service, and before sending the command Start Session (0xA9) as done also in the examples from Sevenstax.
Also, it seems that the command should be optional on our model that supports only the EV mode and it should not affect the other commands.
Therefore, we don’t understand why the V2G service is responding with those error codes and if there is something that we could change in our implementation to avoid this sporadic scenario.
To Reproduce
The issue is difficult to reproduce since it happens sporadically.
That makes debugging it quite difficult and time-consuming therefore we hope to leverage your insight on the product to quickly find the origin of the issue and deploy a solution.
Also, we never noticed the issue with the previous version that we used: v01_00_05.
Expected behavior
Each of the V2G service commands responds with the result code 0x00: Command accepted, and the charging session starts.
as it dose on all the charging sesion where the issue is not present.
Logs
the dificulty of reproducing the issue prevented us from having a complete log set.
following there is the interested portion of the log of the comunication between our host controller and the white-beet module
Additional context
The issue has been reported after we deployed a new series of devices that are equipped with a white-beet module with firmware version: 01_00_07.
We can’t associate for sure the issue with the new version, since we were unable to reproduce the issue enough times to come to a certain conclusion.
Maybe there is something that we can change on our side to avoid the issue.
We can only say that as for now we never noticed the issue with the previous version that we used: v01_00_05.
Another thing that we noticed is that the V2G service seems to become stuck when this issue happens.
What I mean is that we could have an arbitrary number of charging sessions where everything is working fine, then this issue happens and after that it will keep happening in any following charging session.
Even after changing CCS outlet or charger.
It disappears only after rebooting the white-beet module by disconnecting it from the power source.
After a white-beet module reboot it starts to work fine again until it happens next time.
Just to mention it, we did try to do a downgrade to see if the issue persisted on the previous version but we were unable to do so with the firmware updater tool provided by Sevenstax.
The tool seems to report a completed update but after checking the firmware version on the device with the appropriate command: Get firmware Version (Module-ID: 0x10 + Sub-ID:0x41) we still see as the reported version: v01_00_07.
when documenting the issue, it has occurred to me that trying to downgrade was the last thing I tried to do in the evening and the day after we were unable to reproduce the issue on that device.
I hope that is just a coincidence and the reported version is the correct version, and the module is still on v01_00_07.
Thank you in advance for your help.
Kind regards