EVSE v02.00.01 DIN: EVCC ID too long

[ryofromjapan]

Your Setup
Platform: EVSE
Firmware Version: V02_00_01
Host Controller Interface: Ethernet
Host: FreeV2G EVSE_v2.0.1_4

Describe the bug
When we select “DIN 70121” to a protocol from EV side and carry it out, session error occurs.
When we select “ISO 15118” on the protocol, there is no session error. Charge sequence ends supposedly.
Question – Is WHITE-BEET (EVSE) workable with 8byte “EVCC ID”?

To Reproduce
When it is “DIN 70121”, "0000020000000001" is set for “EVCC ID” from EV side (8byte.)
When it is “ISO 15118”, 6 byte MAC Address is set.
Due to a specification with software from EV side, it isn’t possible to change the length of “EVCC ID”.

Expected behavior
My engineers think that “EVCC ID” is 8byte in max, from DIN SPEC 70121.

Logs
[ 45.748] [NOTICE] V2GDIN12: EV requested to start session.
[ 46.055] [ERROR ] V2GAPP: EVCC ID too long!
[ 46.056] [WARN ] V2GDIN12: Failed to set EvccId at user application!
[ 46.057] [NOTICE] V2GAPP: Received event 'Session error'
[ 46.084] [NOTICE] V2GSVC: TCP: Client disconnected or connection closed by server
[ 46.085] [NOTICE] V2GAPP: Received event 'Session stopped'

Additional context
This is my first time to write something down here on this website. Please do inform me if I'm doing it wrongly in any way here. We are a company in Japan, working as a system integrator, using your product. Let me know if you have any questions or concerns. Many thanks!

Ryo

[lho-stx]

Hello Ryo,

thank you for your clear and precise error description!

It is not possible to use the current Whitebeet firmware (V02.00.01) with more or less than 6 bytes for "EVCC ID". This is due the DIN SPEC 70121:2014-12. In Table 29 the types says:

hexBinary (max length: 8)

but the semantics says:

Specifies the EV’s identification in a readable format. It contains the MAC Address of the EVCC as six hexBinary encoded bytes, i.e. the element shall have a length of six bytes.

Therefore the Whitebeet will fail the session if the protocol is violated and "EVCC ID" is longer or shorter than 6 bytes.

We are looking into the possibility of accepting specific protocol violations in a future firmware version and we will put this on the list. I understand your frustration, but unfortunately I have no workaround for you right now.

Thanks for your patience,
lho

[ryofromjapan]

Hi Iho,

Thank you for clarifying this! Please allow me to confirm the following question.

Currently, we are developing our system in referring to <White Beet - User Manual Revision No. 2.14>
This user manual describes that the "Supported Protocol" is DIN70121-2:2012.
I checked Table 40 Semantics on this <DIN SPEC 70121:2012-08>
It doesn't have any description such as "as six hexBinary encoded bytes, i.e. the element shall have a length of six bytes." in your explanation above.
Thusly, my team thought that 8 byte EVCCID should be working.

Would you kindly let me know how you would respond to that feedback?

BR,
Ryo

[lho-stx]

Hey Ryo,

You are right, in <DIN SPEC 70121:2012-08> there is no such description. I referred to <DIN SPEC 70121:2014-12> because it replaced <DIN SPEC 70121:2012-08>. The problem is, that the requirements changed, but the namespaces stayed the same (please see the scheme definition in the <DIN SPEC 70121:2014-12> and <DIN SPEC 70121:2012-08>), so in both cases urn:din:70121:2012 is reported as supported protocol.

I discussed the issue internally and there will be a fix/workaround in the next firmware update. It will be available soon!

Nevertheless, I kindly ask you to create a wireshark log of the charging session in question and send it to me. You need to place evse.whitebeet.networkConfigSetPortMirrorState(1) right before evse.loop() in Application.py and rerun the session. Please let me know if you need support with creating the wireshark log! May I ask you what EV is used?

Thank you,
lho

[ryofromjapan]

Hi Iho,

I will come back to you asap on this. I just have one quick question for you. I feel like I'm such a first year student here, but how could I assign someone to my own inquiry on Github? It's my first time, and please bear with me.

Please do inform me if assigning someone is only possible from someone administer or product owner side. You're such a great person to give me a help. I just wanted to know how to assign.

Have a nice day!

Ryo

[ryofromjapan]

Hello Iho,

Firmware update is a great news! It is very reassuring. About creating the wireshark log, I think we can handle it by ourselves. But please give us a reasonable time. It takes some time to prepare what's necessary to be done. I will send it to you once we finish the work.

In terms of EV that we're using, it is Vector, <CANoe.SmartCharging>.

Thank you,
Ryo

[ryofromjapan]

Hello Iho,

I attach wireshark log and the text file. Would you kindly take a good look at it, and let me know feedback of yours?

Have a great day!

#164_DIN_EVCC_ID_too_long.zip

Ryo

[lho-stx]

Hey Ryo,

many thanks for the logs, I appreciate it! I will have a look, but I am quite sure our analysis of the issue is correct.

We released a new Whitebeet EVSE firmware. You are lucky, we managed to include a bug fix/workaround for your issue. Please obtain the new Whitebeet EVSE firmware at Codico, retry your session and let me know about the results! I hope the new firmware fixes your issues!

Thank you,
lho

[ryofromjapan]

Hi Iho,

I confirmed with EVSE FW(V02_01_00) and the latest FreeV2G. It's working! We do not see "EVCC ID too long!" occurring anymore. However, "Session started(Mod-ID=0x27, Sub-ID=0x80)" seems shorter than we expected. It is EVCC ID. Now it's 6byte. I attach the log file. Would you kindly confirm about it please?

20230412_EVSE_DIN.zip

BR,
Ryo

[lho-stx]

Hey Ryo,

Thank you for the log files, I appreciate your effort! I am glad that it is working now!

Yes, this is intended behavior. If you send 7 or 8 bytes for the EVCCID, the Whitebeet assumes that the MAC address is in the lower part of the bytes. This is needed to comply with <DIN SPEC 70121:2014-12> but to work also with <DIN SPEC 70121:2014-8>.

If there is anything else I can do for you please let me know! Else I would like to close this ticket!

Thank you again for the log files and best regards,
lho

[ryofromjapan]

Hi Iho,

Thanks for confirming this! Problem's solved. Please consider that the issue is closed!
I will come around again on this place, when I have questions or concerns.

Thank you,
Ryo