Subject: RE: [ocpp] OCPP Not Authorized Reason
I am in favour of extending the AuthorizationStatus enumeration. A StopReason is something very different from a reason for not authorizing. I also got the impression that StopReason is a free format text field, which would make automated processing impossible.
We can add some fairly generic statuses to AuthorizationStatus to deal with the ‘not enough funds’ and ‘fast charging not allowed’ and similar cases.
I propose the following additions:
· NoCredit – e.g. when pre-paid card is empty
· SubscriptionMismatch – e.g. when using a valid card on a type of charger that is not supported by your subscription
Van: email@example.com [mailto:firstname.lastname@example.org]
Namens Robert de Leeuw
There was a request for more information in the IdTagInfo class to be able to give more feedback to the EV Driver about the reason why the authorization has failed.
Use Case: An EV Driver swipes his card, the Charge Point asks the Central System if the card is allowed to charge. Computer says NO....
If a Charge Point has a display you want to show a reason to the EV driver why he/she is not allowed to Charge.
In OCPP 1.6 there are already a couple of different statuses, but these are limited. See:
- 7.27. IdTagInfo on page 98
- 7.2. AuthorizationStatus on page 85
Currently we have the following statuses:
Accepted Identifier is allowed for charging.
Blocked Identifier has been blocked. Not allowed for charging.
Expired Identifier has expired. Not allowed for charging.
Invalid Identifier is unknown. Not allowed for charging.
ConcurrentTx Identifier is already involved in another transaction and multiple transactions are not allowed. (Only relevant for a StartTransaction.req.)
I see 2 possible solutions:
I tend to lean to option 1... All this UTF-8 and display size stuff makes a more complex solution.... But on the other hand, we might need to go into that for messages anyway....
Do you guys see a good reason why we should or should not go for one of these options?