[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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: firstname.lastname@example.org [mailto:email@example.com.
org] Namens Robert de Leeuw
Verzonden: zondag 13 november 2016 18:21
Onderwerp: [ocpp] OCPP Not Authorized Reason
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:
- 1: Add more statuses to AuthorizationStatus
- Pros: simple, only extend the enumeration, Charge Point can implement messages that fit the display.
- Cons: how do we know we have all the possible reasons (Not enough pre-paid amount, Fast Charging not allowed?)
- 2: Add a extra optional string field: StopReason to IdTagInfo.
- Pros: everything possible reason can be given.
- Cons: Central System needs to know display size of the Charge Point. How about non ascii-character sets, use UTF-8?. Central System might need to know the language if the user is unknown, and has select a language on the Charge Point.
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?