When I use errn = decode_iso1ExiDocument(&iStream, &exiDoc) (variables have been initialized, version 0.9.3, iso1), when I decode ChargeParameterDiscoveryRes (see attachment): "", a -110 error is reported, and an error is returned when decoding the SignatureValue element , how can I solve this?
The attachment is indeed an XML file, I gave the EXI data in the reply, and the -110 error is returned when I use OpenV2G to decoder the EXI data. Through debugging, it was found that during parsing, an error value was returned during the parsing of the SignatureValue element. And through the XML file, you can see that "<ns5:signaturevalue></ns5:signaturevalue>" is empty, I don't know if it is related to this, I hope to give some guidance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The attachment is indeed an XML file, I gave the EXI data in the reply, and the -110 error is returned when I use OpenV2G to parse the EXI data. Through debugging, it was found that during parsing, an error value was returned during the parsing of the SignatureValue element. And through the XML file, you can see that "<ns5:signaturevalue></ns5:signaturevalue>" is empty, I don't know if it is related to this, I hope to give some guidance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OpenV2G allows one to encode/decode valid XML data. Deviant data is possible in EXI, but not implemented in OpenV2G.
In the case you are describing <signaturevalue> expects base64 data.
In your case there is no data and some EXI encoders may choose to encode the sequence as follows:
1. StartElement("SignatureValue")
2. EndElement // Note: this is not the expected EndElement but the EndElement for deviant data</signaturevalue>
The proper EXI sequence would be:
1. StartElement("SignatureValue")
2. Characters(""); // empty
3. EndElement // expected end element
You may try to add some data like changing your XML input from
<ns5:signaturevalue></ns5:signaturevalue>
to
<ns5:signaturevalue>Zm9v</ns5:signaturevalue>
or so and retry. Every EXI implementation will pick the right EXI sequence and OpenV2G will work just fine.
Note: EXI implementations can be tweaked to always pick the expected first level EXI event codes for expected data.
I hope this helps,
-- Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you very much for your reply and it was very helpful to me.
We used EXIficient to encoder the XML (see fu for details), then used OpenV2G to parse it and found that it reported a -160 error. Tracing to the location of the error return, the code hint is: iso1TransformType->Algorithm.charactersLen = 0, which does not meet the condition of iso1TransformType->Algorithm.charactersLen >= 2, how can we solve the problem? Also I would like to know if EXIficient java GUI is compatible with OpenV2G?
In the ISO 15118 specification specific EXI options are used. One of the setting is not to use string tables. By default any EXI implementation uses them to get better performance.
see https://github.com/EXIficient/exificient#command-line-interface --> "-noLocalValuePartitions"
You also need to set maximumNumberOfBuiltInProductions and maximumNumberOfBuiltInElementGrammars to 0 (zero).
Note: You can set these options through the GUI also. See "Configure Advanced Encoding Options".
Also I would like to know if EXIficient java GUI is compatible with OpenV2G?
As long as you use the same EXI options they are compatible. EXIficient supports all possible EXI options while OpenV2G supports only the subset prescribed by the ISO specification.
-- Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you very much for your patient answer. For the error code number I already know the relevant h file. But as a developer who is new to V2G, I still don't quite understand many parts of it. I have done the response configuration in EXIficient java GUI as you said, and generated a new .exi file (the exi data did change), and when I decode it by OpenV2G, it still returns EXI_ERROR_STRINGVALUES_NOT_SUPPORTED error at the same position. This makes me confused, is there something wrong with the content of the ChargeParameterDiscoveryRes.xml file I tested (wrong format of the related content or other errors, see the attachment for the new EXI data), which causes the OpenV2G parsing exception? Can you explain it in more detail, thank you very much!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I seem to have managed to delete (instead of download) your exi file.
I might have mentioned the wrong option.. please set exiFactory.setValuePartitionCapacity(0); // no string table
Hi, I seem to have managed to delete (instead of download) your exi file.
I might have mentioned the wrong option.. please set exiFactory.setValuePartitionCapacity(0); // no string table
When I use errn = decode_iso1ExiDocument(&iStream, &exiDoc) (variables have been initialized, version 0.9.3, iso1), when I decode ChargeParameterDiscoveryRes (see attachment): "", a -110 error is reported, and an error is returned when decoding the SignatureValue element , how can I solve this?
exi:
8098022B9C35B47683EB4D8A895A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBD5148BD8D85B9BDB9A58D85B0B595E1A4BD0D5A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBCC8C0C0C4BCC0D0BDE1B5B191CDA59CB5B5BDC9948D958D91CD84B5CDA184C8D4D910311A4A218812B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A429687474703A2F2F7777772E77332E6F72672F323030312F30342F786D6C656E6323736861323536420B67C079DD3E44BCC07B2C2D0C41B8D69379AA45C1AF0DE1C92BC16BF5B0EA2B31420A00000000000280E018500B0802A4A2188008000801204407100840901C20088130544019480000006207300818604000
exi:
8098022B9C35B47683EB4D8A895A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBD5148BD8D85B9BDB9A58D85B0B595E1A4BD0D5A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBCC8C0C0C4BCC0D0BDE1B5B191CDA59CB5B5BDC9948D958D91CD84B5CDA184C8D4D910311A4A218812B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A429687474703A2F2F7777772E77332E6F72672F323030312F30342F786D6C656E6323736861323536420B67C079DD3E44BCC07B2C2D0C41B8D69379AA45C1AF0DE1C92BC16BF5B0EA2B31420A00000000000280E018500B0802A4A2188008000801204407100840901C20088130544019480000006207300818604000
exi:
8098022B9C35B47683EB4D8A895A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBD5148BD8D85B9BDB9A58D85B0B595E1A4BD0D5A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBCC8C0C0C4BCC0D0BDE1B5B191CDA59CB5B5BDC9948D958D91CD84B5CDA184C8D4D910311A4A218812B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A429687474703A2F2F7777772E77332E6F72672F323030312F30342F786D6C656E6323736861323536420B67C079DD3E44BCC07B2C2D0C41B8D69379AA45C1AF0DE1C92BC16BF5B0EA2B31420A00000000000280E018500B0802A4A2188008000801204407100840901C20088130544019480000006207300818604000
Hi,
you are sharing an XML instance. OpenV2G works with EXI only.
w.r.t. error codes, here you can find the information what each code means
https://sourceforge.net/p/openv2g/code/HEAD/tree/trunk/src/codec/ErrorCodes.h
e.g., #define EXI_ERROR_UNKOWN_EVENT_CODE -110
Hope this helps,
-- Daniel
The attachment is indeed an XML file, I gave the EXI data in the reply, and the -110 error is returned when I use OpenV2G to decoder the EXI data. Through debugging, it was found that during parsing, an error value was returned during the parsing of the SignatureValue element. And through the XML file, you can see that "<ns5:signaturevalue></ns5:signaturevalue>" is empty, I don't know if it is related to this, I hope to give some guidance.
The attachment is indeed an XML file, I gave the EXI data in the reply, and the -110 error is returned when I use OpenV2G to parse the EXI data. Through debugging, it was found that during parsing, an error value was returned during the parsing of the SignatureValue element. And through the XML file, you can see that "<ns5:signaturevalue></ns5:signaturevalue>" is empty, I don't know if it is related to this, I hope to give some guidance.
OpenV2G allows one to encode/decode valid XML data. Deviant data is possible in EXI, but not implemented in OpenV2G.
In the case you are describing <signaturevalue> expects base64 data.
In your case there is no data and some EXI encoders may choose to encode the sequence as follows:
1. StartElement("SignatureValue")
2. EndElement // Note: this is not the expected EndElement but the EndElement for deviant data</signaturevalue>
The proper EXI sequence would be:
1. StartElement("SignatureValue")
2. Characters(""); // empty
3. EndElement // expected end element
You may try to add some data like changing your XML input from
<ns5:signaturevalue></ns5:signaturevalue>
to
<ns5:signaturevalue>Zm9v</ns5:signaturevalue>
or so and retry. Every EXI implementation will pick the right EXI sequence and OpenV2G will work just fine.
Note: EXI implementations can be tweaked to always pick the expected first level EXI event codes for expected data.
I hope this helps,
Thanks a lot for your reply!
Do you have any good tools for XML and EXI conversion, and if so, I hope you can recommend them?
Hi,
There are some publicly available, see https://www.w3.org/XML/EXI/#implementations
e.g, EXIficient provides a command line tool and a GUI if needed.
http://exificient.github.io/java/
Disclaimer: I am the author of EXIficient.
I hope this helps,
-- Daniel
Thank you very much for your reply and it was very helpful to me.
We used EXIficient to encoder the XML (see fu for details), then used OpenV2G to parse it and found that it reported a -160 error. Tracing to the location of the error return, the code hint is: iso1TransformType->Algorithm.charactersLen = 0, which does not meet the condition of iso1TransformType->Algorithm.charactersLen >= 2, how can we solve the problem? Also I would like to know if EXIficient java GUI is compatible with OpenV2G?
Hi,
I pointed you already to the error codes
https://sourceforge.net/p/openv2g/code/HEAD/tree/trunk/src/codec/ErrorCodes.h
#define EXI_ERROR_STRINGVALUES_NOT_SUPPORTED -160
In the ISO 15118 specification specific EXI options are used. One of the setting is not to use string tables. By default any EXI implementation uses them to get better performance.
see https://github.com/EXIficient/exificient#command-line-interface --> "-noLocalValuePartitions"
You also need to set maximumNumberOfBuiltInProductions and maximumNumberOfBuiltInElementGrammars to 0 (zero).
Note: You can set these options through the GUI also. See "Configure Advanced Encoding Options".
As long as you use the same EXI options they are compatible. EXIficient supports all possible EXI options while OpenV2G supports only the subset prescribed by the ISO specification.
-- Daniel
Thank you very much for your patient answer. For the error code number I already know the relevant h file. But as a developer who is new to V2G, I still don't quite understand many parts of it. I have done the response configuration in EXIficient java GUI as you said, and generated a new .exi file (the exi data did change), and when I decode it by OpenV2G, it still returns EXI_ERROR_STRINGVALUES_NOT_SUPPORTED error at the same position. This makes me confused, is there something wrong with the content of the ChargeParameterDiscoveryRes.xml file I tested (wrong format of the related content or other errors, see the attachment for the new EXI data), which causes the OpenV2G parsing exception? Can you explain it in more detail, thank you very much!
Hi, I seem to have managed to delete (instead of download) your exi file.
I might have mentioned the wrong option.. please set
exiFactory.setValuePartitionCapacity(0); // no string table
GUI
see attached image
File
see attachemend also.
-- Daniel
Hi, I seem to have managed to delete (instead of download) your exi file.
I might have mentioned the wrong option.. please set
exiFactory.setValuePartitionCapacity(0); // no string table
GUI
see attached image
File
see attachemend also.
-- Daniel
EXI stream.
Note, you need to set the XSD schema in the GUI!
Last edit: Daniel Peintner 2022-09-06
Thank you very much for your reply, following your method does work, thanks again!