Offline behaviour (TransactionMessageAttempts / TransactionMessageRetryInterval / Queueing)

[chargeguy]

Hi!

Is the OCPP offline behaviour (considering the configuration parameters TransactionMessageAttempts and TransactionMessageRetryInterval and queueing of messages) already supported in the library?

Best regards!

[tropxy]

Hi, thanks for reaching us. To be fair, we dont have the functionality... That feature is applicable only for the Charge Point scenario and, currently, our library uses the class ChargePoint for both Charge Point and Central System scenarios.

If you urgently need that feature now, I foresee two possibilities:

1. You create your own queue where you put all the messages to be sent to the Charge Point and you use our lib call message as it is. For every transaction-related message, in case you get a Timeout error or if the response is an OCPP error (for which you will get a None as an answer), you retry to send again up to the maximum stated by TransactionMessageAttempts. Given our lib design, the retry interval would be fixed to whatever time you have chosen to create the ChargePoint instance. Just taking the example from our lib and tweaking it a bit, it would look something like this:

class ChargePoint(cp):
    async def send_and_retry(request, number_of_retries=1):
        if number_of_retries == 0:
            print("Message dropped due to continuous failure to be delivered")
            return
        try:
            response = await self.call(request)
            if not response:
                response = self.send_and_retry(request, number_of_retries=number_of_retries-1)
        except asyncio.TimeoutError:
                response = self.send_and_retry(request, number_of_retries=number_of_retries-1)
         return response
        
    async def send_boot_notification(self):
        request = call.BootNotificationPayload(
            charge_point_model="Optimus",
            charge_point_vendor="The Mobility House"
        )
        
        response = await self.send_and_retry(request, 2)

        if response.status ==  RegistrationStatus.accepted:
            print("Connected to central system.")
        
        await asyncio.gather(cp.start(), cp.send_boot_notification())

2. Another option is to override the call method in our lib (https://github.com/mobilityhouse/ocpp/blob/4b86f595993696732d77ee35c1970db4c6657531/ocpp/charge_point.py#L223) and make it work the way you need it, so that you could increase the timeout (self._response_timeout) for every retry and also just retry for the specific InternalError code and not for all Error codes:

if response.message_type_id == MessageType.CallError:
    LOGGER.warning("Received a CALLError: %s'", response)
    if response.error_code == ChargePointErrorCode. internalError:
        ### retry sending####
    return

I hope this helps for now. If you wish to use some of the ideas above to create a PR for our lib we are more than welcome.

Cheers, André

[jr-tactiq]

Did you ever resolve this question?

It is related to my question #119 about handling loss of connection to the server

[Jared-Newell-Mobility]

@jr-tactiq So to answer your question in detail - (considering the configuration parameters TransactionMessageAttempts and TransactionMessageRetryInterval) - This library supports the OCPP message which can read (OCPP 1.6 section 6.24 GetConfiguration.conf) or write (OCPP section 6.9. ChangeConfiguration.req) from the Central System to the Charge Point. It is the charge point that is required to handle the configuration parameters. This is not specific to OCPP messaging, moreover, you are free to implement these in code as you please on the Charge Point. Queueing of messages is also outside of OCPP, however, it would be a nice enhancement for this library.