search

SwitchEV / RISE-V2G

The only fully-featured reference implementation of the Vehicle-2-Grid communication interface ISO 15118
MIT License
220 stars 92 forks source link

Crash when CurrentDemandRes does not contain optional ReceiptRequired element #26

Closed AxelVoitier closed 6 years ago

AxelVoitier commented 6 years ago

Hi Marc,

I just stumbled upon this crash in EVCC side when ReceiptRequired element is not emitted by a SECC in CurrentDemandRes:

2018-11-11T23:04:56,170 DEBUG [Thread-1] V2GCommunicationSessionEVCC: New state is WaitForCurrentDemandRes
2018-11-11T23:04:56,175 DEBUG [Thread-1] TCPClient: Message received
2018-11-11T23:04:56,175 DEBUG [Thread-1] EXIficientCodec: Received EXI stream: 80980214CE3D7EC29385C0D0E00000002040C409003030C0080006143030313132323333343435353636373738380008
2018-11-11T23:04:56,177 DEBUG [Thread-1] EXIficientCodec: XML representation of CurrentDemandRes:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns6:V2G_Message xmlns:ns6="urn:iso:15118:2:2013:MsgDef" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns7="urn:iso:15118:2:2013:MsgBody" xmlns:ns2="urn:iso:15118:2:2010:AppProtocol" xmlns:ns4="urn:iso:15118:2:2013:MsgDataTypes" xmlns:ns3="urn:iso:15118:2:2013:MsgHeader"><ns6:Header><ns3:SessionID>5338F5FB0A4E1703</ns3:SessionID></ns6:Header><ns6:Body><ns7:CurrentDemandRes><ns7:ResponseCode>OK</ns7:ResponseCode><ns7:DC_EVSEStatus><ns4:NotificationMaxDelay>0</ns4:NotificationMaxDelay><ns4:EVSENotification>None</ns4:EVSENotification><ns4:EVSEIsolationStatus>Valid</ns4:EVSEIsolationStatus><ns4:EVSEStatusCode>EVSE_Ready</ns4:EVSEStatusCode></ns7:DC_EVSEStatus><ns7:EVSEPresentVoltage><ns4:Multiplier>0</ns4:Multiplier><ns4:Unit>V</ns4:Unit><ns4:Value>400</ns4:Value></ns7:EVSEPresentVoltage><ns7:EVSEPresentCurrent><ns4:Multiplier>0</ns4:Multiplier><ns4:Unit>A</ns4:Unit><ns4:Value>2</ns4:Value></ns7:EVSEPresentCurrent><ns7:EVSECurrentLimitAchieved>false</ns7:EVSECurrentLimitAchieved><ns7:EVSEVoltageLimitAchieved>false</ns7:EVSEVoltageLimitAchieved><ns7:EVSEPowerLimitAchieved>false</ns7:EVSEPowerLimitAchieved><ns7:EVSEID>001122334455667788</ns7:EVSEID><ns7:SAScheduleTupleID>1</ns7:SAScheduleTupleID></ns7:CurrentDemandRes></ns6:Body></ns6:V2G_Message>
2018-11-11T23:04:56,177 DEBUG [Thread-1] WaitForCurrentDemandRes: CurrentDemandRes received
Exception in thread "Thread-1" java.lang.NullPointerException
    at com.v2gclarity.risev2g.evcc.states.WaitForCurrentDemandRes.processIncomingMessage(WaitForCurrentDemandRes.java:53)
    at com.v2gclarity.risev2g.evcc.session.V2GCommunicationSessionEVCC.update(V2GCommunicationSessionEVCC.java:178)
    at java.util.Observable.notifyObservers(Observable.java:159)
    at com.v2gclarity.risev2g.evcc.transportLayer.StatefulTransportLayerClient.processIncomingMessage(StatefulTransportLayerClient.java:122)
    at com.v2gclarity.risev2g.evcc.transportLayer.TCPClient.run(TCPClient.java:102)
    at java.lang.Thread.run(Thread.java:748)

If I modify the SECC by just adding this ReceiptRequired to False in the CurrentDemandRes, then it works. Message sets conditions are: TCP, EIM, DC.

I checked in the standard, the only requirement relating to this condition is [V2G2-593]. It does says "The SECC sets “ReceiptRequired = FALSE" indicating that the Message Set MessageReceipt shall not be used by the EVCC.". But, to my interpretation which we can discuss openly ;), this does not actually impose the SECC to send it, as it does not use the word "shall" for it.

Like it does in [V2G2-788] for instance (but that only applies in PnC message sets, not EIM).

Because otherwise I don't see any other use case for having this element in CurrentDemandRes defined as optional. Unless I missed something, of course.

Cheers, Axel

MarcMueltin commented 6 years ago

Hi @AxelVoitier,

Thanks very much for that hint. This is indeed an error in RISE V2G. The field 'ReceiptRequired' is optional in both CurrentDemandRes and ChargingStatusRes. I fixed it with commit cc26d2a