[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ocpp] "Not Authorized" Reason
Hi Robert, The NotInGroup status could be returned if you try to
stop a transaction with an otherwise valid card that is not in the same group (parent id) as the card that started the transaction. The Reserved status should be returned when you try to
start a transaction on a charge point that is currently reserved for another card (not in the same group). I am not sure about the (Commanded) Unavailable status. If a CPO wants to keep the charge point unoccupied for maintenance, then he can simply
set the charge point to Unavailable and it will not read any cards anymore. Regards, -Franc Van: Robert de Leeuw [mailto:robert.de.leeuw@ihomer.nl]
Hi Brendan, Again, StopReason was a typo, should have been: NotAuthorizedReason, again, sorry for that. Do you propose to add both? More possible values for: AuthorizationStatus, and an optional text field "NotAuthorizedReason" or "AuthorizeResponse" I don't see how the central system can return the status: "NotInGroup". Can you explain a bit more? "Reserved"? OCPP 1.6 states: "If the parent idTag in the reservation has a value (it is optional), then in order to determine the parent idTag that is associated with an incoming idTag, the Charge Point MAY look it up in its Local Authorization List or Authorization Cache. If it is not found in the Local Authorization List or Authorization Cache, then the Charge Point SHALL send an Authorize.req for the incoming idTag to the Central System. The Authorize.conf response contains the parent-id." So when should a Central system return an AuthorizationStatus: Reserved? Same goes for "(Commanded) Unavailable" Charge Point is unavailble, it should even do an Authorize request...
Kind regards, Hoge Ham 85 5104 JC Dongen John F. Kennedylaan 3 5555 XC Valkenswaard
2016-11-14 15:29 GMT+01:00 Brendan McMahon <Brendan.McMahon@esb.ie>: Hi Franc, Robert, (folks), I strongly agree with Franc that it would be wrong to have a field called StopReason
in the IdTagInfo structure as a way to communicate why a transaction was never started in the first place. To support all plausible business models and associated use cases, I think that there needs
to be BOTH: ·
Appropriate extra values for the AuthorizationStatus enumeration: e.g.: o
Reserved – all working not currently in use are (soon to be) reserved to other drivers. o
(Commanded) Unavailable – e.g. maintenance visit immediately pending o
OutOfCredit (Central)
o
ContractMismatch – Contract does not allow use of (requested/implied) charging type/speed [at this time] ·
Provision for the Central System to return a (possibly driver language-localized) custom message (suitably formatted, based on the known display characteristics). o
“You’re account credit will allows only <X> {minutes/hours/kWh} of charging” o
This charging site closes at 10PM
o
This {charge point | charging site} will be unavailable tomorrow <from> - <to> [due to <reason>] ·
Separately, some thought ought to be given to similar mechanisms in regard to Authorize responses to (attempts to) stop an ongoing transaction: o
AuthorizationStatus (additional:) §
NotInGroup (groupIdTag, a.k.a parentIdTag in OCPP 1.6) §
AcceptedLawEnforcement o
AuthorizeResponse text (examples) §
Account credit overdrawn: no further charging possible until topped-up. §
charge point/site unavailability notices Best Regards,
Brendan McMahon | Systems Architect | ESB ecars | T:
+353 1 702 6708 /
+353 87 662 2150 | www.esb.ie
From:
ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org]
On Behalf Of Buve, Franc Hi Robert, 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 Regards, -Franc Van:
ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org]
Namens Robert de Leeuw Hi All, 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?
Kind regards, Hoge Ham 85 5104 JC Dongen John F. Kennedylaan 3 5555 XC Valkenswaard
* ** *** ** * ** *** ** * ** *** ** *
* ** *** ** * ** *** ** * ** *** ** * |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]