Handshake with the same Charging point keeps on happening again and again.

[antino-pranshu]

Hi mikuso,

I am creating my own csms and trying to connect to a charging point. I am able to successfully connect to it and get the heartbeat as well as the BootNotification.

But it keeps on doing handshake process after every few intervals. e.g. it did handshake on 2:00:20 pm, now after a few seconds say at 2:00:28, it again did the handshaking.

What could be the possible issue here? I am using a DC charger by the way.

Let me know if any further details are required. ~ Thanks

[mikuso]

When you say handshake process, do you mean the charger is disconnecting and then reconnecting?

[antino-pranshu]

When you say handshake process, do you mean the charger is disconnecting and then reconnecting?

By handshake I mean the authorize process. server.auth((accept, reject, handshake) => { // accept the incoming client accept({ // anything passed to accept() will be attached as a 'session' property of the client. sessionId: 'XYZ123' }); }); This event keeps on triggering after every few intervals. I am trying to understand as to why this is happening? What's causing this behaviour.

[antino-pranshu]

@mikuso any updates on this?

[tygoegmond]

Do you return a correct response in the boot notification? I'd suggest taking a look at the OCPP specification. Check it out at Open Charge Alliance.

[antino-pranshu]

Do you return a correct response in the boot notification? I'd suggest taking a look at the OCPP specification. Check it out at Open Charge Alliance.

Yes, every response I am sending is correct, I also have strictValidation set to true. So, that's not an issue.

[antino-pranshu]

Any reponse? I am getting a weird behaviour where I am able to successfully do handshake(auth) with the Charging Point. But it keeps on disconnecting and reconnecting at a very rapid pace. I have attached the Log file below. @mikuso please help out here. NewCpLogsSept14.pdf

[mikuso]

Hi @antino-pranshu

Have you managed to establish whether this is a behaviour specific to the charging station that you are trying to use? Or does the same happen with every charging station?

If so, and if you can also provide small code sample which demonstrates the problem, then I could investigate further.

[antino-pranshu]

Hi @antino-pranshu

Have you managed to establish whether this is a behaviour specific to the charging station that you are trying to use? Or does the same happen with every charging station?

If so, and if you can also provide small code sample which demonstrates the problem, then I could investigate further.

Hey @mikuso , thanks for the reply, I have been observing this same behaviour with 2 different vendors. I have only tested out with them. Both having same behaviour. I think I must be missing some configuration.

Here's my RPC code: server.txt

EDIT: also been getting 1006 and 1000 error codes onClose event.

[mikuso]

Thanks.

I have managed to get your code running, but I've not been able to recreate this issue with my own charger.

A websocket close code of "1000" indicates that the disconnect was deliberate (as opposed to being due to a connection interruption or a crash).

This really looks to me like an issue with the charger - not the server.

Have you had success with this charger when connected to other central systems?

[antino-pranshu]

Thanks.

I have managed to get your code running, but I've not been able to recreate this issue with my own charger.

A websocket close code of "1000" indicates that the disconnect was deliberate (as opposed to being due to a connection interruption or a crash).

This really looks to me like an issue with the charger - not the server.

Have you had success with this charger when connected to other central systems?

Hey @mikuso , yes the vendor claims that they have had success with other csms.

I have tried with both there chargers which is AC as well as there DC charger. Issue, persists in both of them. Just can't wrap my head around what could be wrong here.

Also , did you manage to capture any logs when you connected the csms with your machine?

Thanks.

[mikuso]

Here are the logs I captured:

OCPP Server has been started
Endpoint for handshake  ---- /
Identity for handshake ---- SIM
charging_point_id ----
auth_key for handshake ----- undefined
Trying to get cp using identity -> SIM
All available client identities:
CS has accepted the auth of: SIM
All client identities:
-> SIM
Server got BootNotification from {"chargePointSerialNumber":"012345678901234","chargePointVendor":"ChargePointSimulator","imsi":"012345678901234","chargePointModel":"Simulator","iccid":"01234567890123456789","chargeBoxSerialNumber":"012345678901234","firmwareVersion":"0.0.1"}:
BootNotification response initiated from server to SIM, whose vendor is - ChargePointSimulator, from model - Simulator}
CS: StatusNotification {"connectorId":0,"errorCode":"NoError","status":"Available","info":"conn# 0","timestamp":"2023-09-15T08:35:13.049Z"} of client SIM
CS: StatusNotification {"connectorId":1,"errorCode":"NoError","status":"Available","info":"conn# 1","timestamp":"2023-09-15T08:35:13.066Z"} of client SIM
CS: StatusNotification {"connectorId":2,"errorCode":"NoError","status":"Available","info":"conn# 2","timestamp":"2023-09-15T08:35:13.075Z"} of client SIM

The charger stayed connected without issue.

[mikuso]

Are you able to get any logs from the charger itself? It may reveal why it is behaving the way it is.

[antino-pranshu]

Are you able to get any logs from the charger itself? It may reveal why it is behaving the way it is.

Not really, no logs as of now. I can ask them to provide if they have any. By the way, the code is fine right? Is there maybe anything that can be done on the csms code level that could fix this up?.

As, I have faced the same issue with a different vendor as well.

[mikuso]

I have not been able to identify any issues in your code which would result in this behaviour.

If it wasn't for the "1000" close codes, I would have suspected an issue upstream like a failing proxy or another interfering component - but this doesn't seem to be the case.