Charging Station > Notification: Check Json connection + Update heartbeat if necessary

[LucasBrazi06]

When the heartbeat is not sent to the backend for a given period of time a notification is sent to the Admins. Before sending the notification, check the Json connection with a simple OCPP command like ClearCache and if it works, update the last heartbeat of the charging station and do not send the notification to the Admins.

[fcoutellier]

@OliveGerste : Could you please take care of this issue?

[jerome-benoit]

When the heartbeat is not sent to the backend for a given period of time a notification is sent to the Admins. Before sending the notification, check the Json connection with a simple OCPP command like ClearCache and if it works, update the last heartbeat of the charging station and do not send the notification to the Admins.

I think you can first test if the WebSocket is open (each WS have a queryable status attribute) for OCPP-J, then do a functional test on the charging station. We have to find the less intrusive OCPP command for the functional test, cache clearing is too intrusive. Something like get configuration, get local list version or get something with an output from the charging stations.

[LucasBrazi06]

I think you can first test if the WebSocket is open (each WS have a queryable status attribute) for OCPP-J, then do a functional test on the charging station. We have to find the less intrusive OCPP command for the functional test, cache clearing is too intrusive. Something like get configuration, get local list version or get something with an output from the charging stations.

Yes, I had thought about the OCPP Trigger Message but it has to be implemented LucasBrazi06/ev-dashboard#1125 May be implementing both issues would be fine.

[jerome-benoit]

I think you can first test if the WebSocket is open (each WS have a queryable status attribute) for OCPP-J, then do a functional test on the charging station. We have to find the less intrusive OCPP command for the functional test, cache clearing is too intrusive. Something like get configuration, get local list version or get something with an output from the charging stations.

Yes, I had thought about the OCPP Trigger Message but it has to be implemented LucasBrazi06/ev-dashboard#1125 May be implementing both issues would be fine.

We are already retrieving all OCPP parameters key/value with Get Configuration. The functional test can just be the retrieval of 'HeartbeatInterval' or 'HeartBeatInterval' key/value. All vendors have it.

[LucasBrazi06]

We are already retrieving all OCPP parameters key/value with Get Configuration. The functional test can just be the retrieval of 'HeartbeatInterval' or 'HeartBeatInterval' key/value. All vendors have it.

The conf is a bit too much for a kind of simple "ping". The OCPP heartbeat is sent by the charger as far I can remember.

[jerome-benoit]

We are already retrieving all OCPP parameters key/value with Get Configuration. The functional test can just be the retrieval of 'HeartbeatInterval' or 'HeartBeatInterval' key/value. All vendors have it.

The conf is a bit too much for a kind of simple "ping".

You can do a request to query a unique OCPP key and get only one key/value. Just like you can set a value to one OCPP key at a time.

[LucasBrazi06]

You can do a request to query a unique OCPP key and get only one key/value. Just like you can set a value to one OCPP key at a time.

Only if you are sure this OCPP param exists over all charging stations...

[jerome-benoit]

You can do a request to query a unique OCPP key and get only one key/value. Just like you can set a value to one OCPP key at a time.

Only if you are sure this OCPP param exists over all charging stations...

'HeartBeatInterval' is required and exists on all vendors firmware implementation with a possible case change on the b. There's a bunch of OCPP required keys that exists on all charging stations: AuthorizeRemoteTxRequests, ClockAlignedDataInterval, ConnectionTimeOut, GetConfigurationMaxKeys, LocalAuthorizeOffline, LocalPreAuthorize, MeterValuesAlignedData, MeterValuesSampledData, MeterValuesSampledDataMaxLength, NumberOfConnectors, ResetRetries, ConnectorPhaseRotation, ...

Iteration over two or three of them to get their value from the station is cheap, already the possible with implementation of the charging station client. The most obvious are 'HeartBeatInterval' 'HeartbeatInterval' and 'NumberOfConnectors'. Even the Hager firmware have the two.

[LucasBrazi06]

'HeartBeatInterval' is required and exists on all vendors firmware implementation with a possible case change on the b. There's a bunch of OCPP required keys that exists on all charging stations: AuthorizeRemoteTxRequests, ClockAlignedDataInterval, ConnectionTimeOut, GetConfigurationMaxKeys, LocalAuthorizeOffline, LocalPreAuthorize, MeterValuesAlignedData, MeterValuesSampledData, MeterValuesSampledDataMaxLength, NumberOfConnectors, ResetRetries, ConnectorPhaseRotation, ...

Iteration over two or three of them to get their value from the station is cheap, already possible with implementation of the charging station client. The most obvious are 'HeartBeatInterval' 'HeartbeatInterval' and 'NumberOfConnectors'. Even the Hager firmware have the two.

ABB had no OCPP params at all at the beginning and there are many chargers not implementing the standard mandatory OCPP params, so not reliable enough imho. Clear Cache on the other way has always been working so far... To be tested...

[jerome-benoit]

ABB had no OCPP params at all at the beginning and there are many chargers not implementing the standard mandatory OCPP params, so not reliable enough imho. Clear Cache on the other way has always been working so far... To be tested...

First iterate on a short list of OCPP parameters then clear cache as a last resort. Deleting stations local data made to deal with connectivity issue with the central storage for testing connectivity on a network equipment that might have issues has a very high probability to lead to data loss.

[fcoutellier]

@LucasBrazi06 : What is the final statement for this issue? Tobias need some clarity after this long thread. Thanks!

[LucasBrazi06]

@LucasBrazi06 : What is the final statement for this issue? Tobias need some clarity after this long thread. Thanks!

Goal is to retrieve an OCPP param via get configuration and to not send the notification in that case + update heartbeat.

[fcoutellier]

@OliveGerste : Is that clear enough now?

[OliveGerste]

@fcoutellier Yes, I will take care of this

[fcoutellier]

Need some clarification from Serge

[fcoutellier]

Test: 1) disconnect the charging station and waiting for the heartbeat test 2) modify the ocpp parameter related to the heartbeat and check the logs

[jerome-benoit]

I've recently made changes to ensure only the two heartbeat related keys 'HeartBeatInterval' 'HeartbeatInterval are queried.

So far, no false positive on charging stations disconnection have been reported.

[LucasBrazi06]

Here it's more the heartbeat in the database.

[jerome-benoit]

Here it's more the heartbeat in the database.

Tobias have already implemented the features requested here. I’ve just make changes to use OCPPUtils.requestChargingStationOcppParameters() only to query the heartbeat related OCPP parameters instead of all of them.

[LucasBrazi06]

Ah ok, perfect then! Thanks!