Use Case O02: Set DisplayMessage for Transaction

[RobertDeLeeuw]

No description provided.

[thanaParis]

I'm looking into this use case for a 'Scan and Charge' feature where the CSMS sends a QR code image to the charger via SetDisplayMessage, triggered by a Started TransactionEvent after plugin without prior authorization. The QR code could then be scanned and payment information entered at the encoded link; after payment is authorized this triggers a RequestStartTransaction from the CSMS thus authorizing a charge.

I have some questions:

1. Do you know when this use case will be available for EVerest's sil simulator?
2. I am mystified by the MessageStateEnumType used in display messages. Do you know how these statuses will map to the charging process? For example, if "Charging" is the status when electricity is flowing, and "Idle" is the status when there's no transaction at the charger, does this mean a charger plugged in but not authorized, with an active transaction because of a TxStartPoint of EVConnected, must be "Unavailable"? The specification is worryingly unclear on this.
3. Do you have any sense of how EVerest will interpret messages of format 'URI'? I am hoping it will be possible to load an image onto a charger using the URI format to pass the url of an image asset, but there are no requirements in the specification dictating the 'correct' handling of URI content.

[RobertDeLeeuw]

2: Hmmm, you are right, the definitions are not very clear. I believe I meant (I wrote this part) the state of the charging station, not of the charging sessions.

• Idle: "when no transaction is ongoing/no body is using the charger". So the charger is not in use by anybody. I will ask OCA to clarify this a bit more.
• Charging: "charging session ongoing" not taking into account if there is any energy flow. So basicly between TransactionEvent Started and Ended.

3: Good one, OCPP does not really specify what is provided in the URI. This we need to discuss within cloud communication group. Not even sure this is part of EVerest. I think EVerest should store the DisplayMessages and the info to the display driver to display. So it will be up to the implementation of the charger manufacturer.

[thanaParis]

Thank you for the reply! This is very helpful.

Charging: "charging session ongoing" not taking into account if there is any energy flow. So basicly between TransactionEvent Started and Ended.

So, if a charger has a TxStartPoint of EVConnected, it would be "Charging" after plugin, but if it has a TxStartPoint of Authorized and a driver plugged in before authenticating, the charger would be "Unavailable" after plugin?

I think EVerest should store the DisplayMessages and the info to the display driver to display. So it will be up to the implementation of the charger manufacturer.

This makes sense to me too, even though it's unfortunate from the CSMS side because it means we can't know for sure what OCPP 2.0.1-compliant chargers actually support for UI purposes. Being able to negotiate UI updates strikes me as very important for true interoperability between charging stations and CSMSs. It would be ideal if the charger could report UI preferences (width, height, mime-type) via OCPP messages, with protocol use cases for supported formats--that way an OCPP 2.x CSMS could list specific UI use cases as requirements for interoperability with OCPP 2.x charging stations. Without such use cases available, I don't think interoperability can be determined by implementing the protocol alone, since being able to update the UI is a fundamental need, not a custom value-add, and the current UI options only properly support text, which is insufficient.