Restricting charging to selected cars (i.e. emulating plug n charge with OCPP 1.6)

[kbenhabe]

Dear all,

I will soon purchase an OCPP compliant car charger - and installed and am reviewing this add-on (connected to nothing yet). To be honest I feel selecting a car charger ahead of its integration to HA to be painful, as all resellers I talk to are all electricians and literally none have heard of OCPP, ModBus or even APIs ... but ok I keep talking to vendors of OCPP 1.6 certified car charger resellers and hope that one day someone will be able to answer my basic questions. I observe pretty well no OCPP 2.x chargers are available yet on the market (at least in Spain where I live)

In the meantime I have a question for this fine team. My wife runs a bed n breakfast - and I'd like to only grant access to (smart) EV charging only to approved cars. I understand that with OCPP 2.x this comes in directly built in as plug n charge. Is there a way to somehow achieve the same result with this HA OCPP add-on with an OCPP 1.6 capable charger? Ideally could I receive the id of a car that just plugged in, compare it to my list of approved vehicles and only then grant charging ? Ideally reading the car's VIN or any other mechanism ?

Thanks in advance! Karim.

[kbenhabe]

Somehow attempting to answer my own question, I had a look at https://assets.vector.com/cms/content/products/vcharm/docs/WhitePaper_Identification_of_ElectricVehicles_in_CSMS_via_OCPP.pdf
https://uploads-ssl.webflow.com/607417b42ba2bfea543956dd/60c33c6cc823f9bb6bd4f275_Whitepaper-Autocharge-vs-ISO15118-Plug-and-Charge.pdf

And it seems that the EV is supposed to send its MAC that will be used to fill the IdToken OCPP field. So if we can retrieve it we could compare it with either a hardcoded list of EV MACs or a small SQL DB with those; thereby allowing a plug n charge experience with a bit of Jinja 2 templating ... in theory

Would love to hear any experience on those IdToken. As I haven't bought the car charger yet (as I struggle deeply to find any reseller willing to comment on OCPP capabilities or even if a server can be configured on the OCPP compliant models they sell) - would anyone know if the IdToken field is returned with an EV identifier ?

[GrantKeymer]

@kbenhabe

Yes it seems a pity that enabling OCPP disables the plug n charge capability and we have to resort to workarounds such as constantly monitoring the charger status as mentioned elsewhere. In my case I envisage using HA to automate my charging for about 6 months of the year when solar power is sufficient. Here in New Zealand that is from mid September until April. During the other months it's much easier to disable OCPP and resort to the app, selecting charge current to max and setting a timer.

Once I have managed to get my charger connected via OCPP I'm happy to inspect the packets coming from the charger and see if any vehicle ID is being passed. For now I'm stuck at first base unable to get my charger (Wallbox Pulsar Plus) communicating to HA. Marten has given me a suggestion so I'll follow that up and try to make sense of what is going on.

It's good to hear your idea of making a list of authorised vehicles at a BnB. Makes a lot of sense for your particular use case. Throwing ideas around in a specialised forum like this is a great way to add value for all participants. It can spark ideas for others, and as time goes by, we will have a template for various different use cases which can be built on and adapted to suit pretty much anybody who wants to experiment with OCPP-compliant EV chargers and HA.

Kind regards, Grant.

[drc38]

@GrantKeymer you may want to check this repo out for ideas https://github.com/evcc-io/evcc

[GrantKeymer]

@drc38 Thank you very much for pointing out the existence of that repo. Lots of great reading and food for thought.

[lbbrhzn]

My Wallbox Pulsar Plus does not automatically start charging in OCPP mode. It will send a StatusNotification with status 'Preparing'. You then need to start the charging remotely, using a RemoteStartTransaction. This can be triggered manually (with the Charge_Control switch) or with an automation. The RemoteStartTransaction will trigger the charger to send a StartTransaction message, which contains the IdTag you mention. The Wallbox Pulsar sets it to the name of the charger, it does not contain any vehicle or RFID tag related information.

Here's a log fragment that shows the relevant messages:

2021-12-29 12:43:37 INFO (MainThread) [ocpp] charger: receive message [2,"e7ee9045-abae-40e3-b26f-16ef7f6ec386","StatusNotification",{"info": "","vendorId": "","vendorErrorCode": "","connectorId": 1,"errorCode": "NoError","status": "Preparing","timestamp": "2021-12-29T11:43:37Z"}]
2021-12-29 12:43:37 INFO (MainThread) [ocpp] charger: send [3,"e7ee9045-abae-40e3-b26f-16ef7f6ec386",{}]
2021-12-29 12:43:47 INFO (MainThread) [homeassistant.components.automation.start_charging] Start charging: Running automation actions
2021-12-29 12:43:47 INFO (MainThread) [homeassistant.components.automation.start_charging] Start charging: Executing step device automation
2021-12-29 12:43:47 INFO (MainThread) [ocpp] charger: send [2,"36442a74-9fa3-495b-b057-3fdd71990abe","GetConfiguration",{"key":["AuthorizeRemoteTxRequests"]}]
2021-12-29 12:43:48 INFO (MainThread) [ocpp] charger: receive message [3,"36442a74-9fa3-495b-b057-3fdd71990abe",
{
"unknownKey": [],
"configurationKey": [
{
"readonly": false,
"key": "AuthorizeRemoteTxRequests",
"value": "false"
}
]
}]
2021-12-29 12:43:48 DEBUG (MainThread) [custom_components.ocpp] Get Configuration for AuthorizeRemoteTxRequests: false
2021-12-29 12:43:48 INFO (MainThread) [ocpp] charger: send [2,"d1e2155c-3f1f-4e0d-a71b-298976d00d2f","RemoteStartTransaction",{"idTag":"charger","connectorId":1}]
2021-12-29 12:43:48 INFO (MainThread) [ocpp] charger: receive message [3,"d1e2155c-3f1f-4e0d-a71b-298976d00d2f",
{
"status": "Accepted"
}]
2021-12-29 12:43:49 INFO (MainThread) [ocpp] charger: receive message [2,"3e951ff7-34a4-42c1-ab8f-8c12fcb20f93","StartTransaction",{"connectorId": 1,"meterStart": 0,"idTag": "charger","timestamp": "2021-12-29T11:43:49Z"}]
2021-12-29 12:43:49 INFO (MainThread) [ocpp] charger: send [3,"3e951ff7-34a4-42c1-ab8f-8c12fcb20f93",{"transactionId":1640778229,"idTagInfo":{"status":"Accepted"}}]
2021-12-29 12:43:49 INFO (MainThread) [ocpp] charger: receive message [2,"ed905418-2a07-4198-9f79-0e49cf665960","StatusNotification",{"info": "","vendorId": "","vendorErrorCode": "","connectorId": 1,"errorCode": "NoError","status": "SuspendedEV","timestamp": "2021-12-29T11:43:49Z"}]
2021-12-29 12:43:49 INFO (MainThread) [ocpp] charger: send [3,"ed905418-2a07-4198-9f79-0e49cf665960",{}]
2021-12-29 12:43:51 INFO (MainThread) [ocpp] charger: receive message [2,"7f4a6748-e635-4c9b-9471-65db88b8ede2","StatusNotification",{"info": "","vendorId": "","vendorErrorCode": "","connectorId": 1,"errorCode": "NoError","status": "Charging","timestamp": "2021-12-29T11:43:51Z"}]
2021-12-29 12:43:51 INFO (MainThread) [ocpp] charger: send [3,"7f4a6748-e635-4c9b-9471-65db88b8ede2",{}]
2021-12-29 12:44:00 INFO (MainThread) [ocpp] charger: receive message [2,"871a268d-6f47-4019-aadd-2608efd329b0","MeterValues",{"meterValue": [{"timestamp": "2021-12-29T11:43:59Z","sampledValue": [{"value": "18","format": "Raw","location": "Outlet","context": "Sample.Clock","measurand": "Energy.Active.Import.Register","unit": "Wh"} ]} ],"connectorId": 0,"transactionId": 0}]

[GrantKeymer]

@lbbrhzn - Thanks for posting the log fragment showing the sequence of messages. Taking the first 2 messages as an example, one of which is sent by HA to the charger and the following one which is the reply from the charger, I've tried to do a simulation in Weasel...

Have I got everything correct there?
Is the connection supposed to close immediately after the charger sends its reply to HA?