Open andreasringdal opened 1 week ago
Hi Andreas,
the current "raw" hook was only the first step. As you suggested an authentication hook and also a status hook (free/connected and current meter values) will be usefull.
With your suggested method signature: The transaction id is not possible I think (at least with OCPP 1.6). At first the charger sends the Authorize request - kind of a pre charging request. If that is successfull the charger sends the StartTransaction request with the same token. The server needs to authorize this again. Afterwards the transaction data is written to the database and the id gets created. And the final step is to send the "OK" together with the id to the charger. So the transaction id only gets created after all authorizations. With OCPP 2.x the transaction id becomes a uid which is created and send by the charger. OCPP.Core.Server stores this in the transaction (db) but uses internally the database id for reference. With OCPP1.6 the backend (OCPP.Core.Server) could create a uid and pass that in the authorization hook and store it in the database. This way you have a reference of the transaction.
@dallmann-consulting Issue added to discuss commit 61511ff and further development of extensions/plugins
Extension framework is a great way of customizing OCPP.Core.
There is one more hook that we will need to add for our use. Authorize based on tagId and chargerId
Current the method will be something in the line of
Background
On the system we are forwarding OCPP messages to we have assigned charging token to users and chargers to rooms/areas in the system.
We authorize users based on their current access to the room.
My current hack in Ocpp.server is to call a stored procedure with a custom connection string.
Planned Autorize Extension takes tagId + chargepointid as input and checks if the combination is allowed to use this charger at the current time.
The same procedure is run at starttransaction and stoptransaction.
We will develop our authorize extension custom for our system, but the hooks will be general for reuse.
We have current transaction data stored in our system and does not require information regarding transactionid and startTag but this information might be of use for Authorize adons for others