Offline behavior

[sumlin]

It seems message recovery doesn't work. Try this one, please, but I'm not sure I think as well as you:

1. Connect to a server.
2. Send BootNotificatonRequest. It might be done with handlerBootNotificationResponse.
3. Send StartTransactionRequest. It might be done with handlerStartNotificationResponse.
4. Disconnect.
5. Send AuthorizationRequest. It might be failed with NotConnectedException on handlerAuthorizationResponse.
6. Send StopTransactionRequest. It might be failed with NotConnectedException on handlerStopTransactionResponse.
7. Connect.
8. Your program have to send StopTransactionRequest again and might be done with handlerStopTransactionResponse.

[TVolden]

I found a bug that caused the websocket to stay open when I killed the session on the server. I fixed that, and created a feature test, to test the feature you set up here. I'm not sure if this fixes your issue, since the bug was only for simulated purposes. But please check it out.

[sumlin]

Have you tried to do it with SOAP protocol? But sure, I'll check this out.

[TVolden]

I can do it with the SOAP protocol sure. 😃

[abankeszi]

Hey @TVolden!

I have some other problems regarding offline behavior, thought I would share them in this issue.

TLDR: I suggest to just throw the NotConnected back to the user and let them handle the queue themselves.

---

- The transaction queue is not persistent Charge Points may run for days without connection and could be reset or turned off before a connection is re-estabilished. In this case, the whole transaction queue is wiped.

- The transaction queue doesn't handle transaction ids properly When the StartTransaction fails to send, a Charge Point may still enable charging and start an offline transaction. When the connection is re-estabilished and the StartTransaction is resent, the transactionIds for messages that are queued up in the meantime (MeterValues, StopTransaction) will still be null, and they never get updated. The queue is not accessible by the user to update either.

- StatusNotifications with error codes are not getting queued up StatusNotifications that contain error codes other than NoError should be resent when a connection is re-estabilished. They don't need to be in the same queue, as they don't need to wait for it to empty, but they do need to be stored and resent.

The second and third issues could be fixed in the library, but I think persistency should be handled by the user. Therefore I suggest to simply throw the NotConnected back to the user and let them handle a persistent message queue as they see fit.

[TVolden]

Hi @abankeszi,

You make a fair point.

I had to objectives with the lib:

1. Make it easy to get OCPP compliant.
2. Possible to change the inner workings of the lib.

I'm not quite there with the second objective, since the components have grown to handle to much stuff. But it is possible to introduce custom handling by implementing a custom communicator and wrap it around the librarys. By this approach, you you can persist the queue, throw exceptions or anything you want to. Be aware that by doing this you risk compatibility problems when ever the library change, since my main focus is not to change the exposed APIs.

One way to do this, is to fork my lib, create a custom communicator and a custom client and then reintroduce it to the lib with a PR.

What do you say? Is this an acceptable way to handle it?

Thomas

[abankeszi]

One way to do this, is to fork my lib [...] Be aware that by doing this you risk compatibility problems when ever the library change [...]

That's basically why I didn't want to fork the lib in the first place but ended up doing so. I'll see if and how I can move my solution into the core library code after I'm done with my upcoming deadline.

Adam

[nilpotence]

hi @abankeszi @TVolden

Any news on this issue ? I'm having the same issues as described by @abankeszi for message queuing when the ChargePoint is offline (transactionId issue, queue and StatusNotification persistence) and I'm considering my options. @abankeszi : did you end up implementing a custom communicator / custom client as suggested by @TVolden ? if so, do you plan on merging this back into the lib ?

Let me know if I can be of any help in resolving this issue ;)

Best,

Sylvain

[TVolden]

hi @nilpotence

Yeah sure, can wait to see the result.

[abankeszi]

Hi @nilpotence,

No, I've simply disabled the transaction queueing and let the NotConnected errors go back to the caller (via CallErrorException) as you can see in [this commit] in my fork. Then I just checked the CallErrorException on the caller-side if it's a NotConnected error, and saved the original request in a Redis queue.

I'm planning on refactoring the code back to lib, but implementing other features have been higher priority recently. I'll try to allocate some time for it in the coming weeks.

Adam