ocpp library as an event based message handler (decoupled from websocket)

[villekr]

First of all thanks for building this library, I've been successfully using it for some time. I know websocket is in the core of ocpp specification but it doesn't mean that message handling library has to necessarily make tight coupling with it. Instead of receiving/sending messages from the given websocket, library could offer alternative interface for message handling, which decouples from the actual connection. This would enable e.g. running ocpp message handling logic in a serverless fashion where the connections are managed and actual messaging via websocket is done elsewhere.

Basically this should be possible already now in a little bit hacky way: provide websocket interface (recv, send) with custom logic, and instead of issuing ChargePoint.start() just using use ChargePoint.route_message(...). After-action handlers might be a little awkward in this hacky approach but perhaps manageable. (In general I really like how on and after action handlers make you to separate message handling logic and allow you to provide as fast response to charging station as possible).

What I'm looking here is if anyone has already thought of this and if there would be interest to discuss possible modifications to library's interface. I'm happy to prototype ideas and assist in development.

[OrangeTux]

Thank you for you feedback. I think I like the idea of decoupling the websocket connection from the charge point implementation. One drawback of this tight coupling is that the ChargePoint is destroyed if the websocket connection is closed. Unless you explicitly prevent this.

Now I'm thinking longer about it I'm not sure why the websocket connection is passed to the ChargePoint. I guess it's because of the internal code base where this library was based on.

How would you expect ChargePoint.route_message() to work? I guess that if you pass it a Call the function should return a CallResult or CallError. But what if you pass it a CallError or CallResult, what should it return than?

I'm happy to explore this idea further with you. One thing we need to keep in mind if and how we want to keep backwards compatibility.

[villekr]

Good to hear that this idea sounds interesting and worthwhile to push forward. Ensuring backwards compatibility is of course critical and this decoupled approach would be just alternative way to use library.

When decoupling message handling (routing to on and after hooks) from the connection handling (websocket send and receive, event invocation), some responsibility might need to be also moved out of library in that case. In this kind of event based approach, it might not be possible to handle both on and after hooks within same "event". on-hook's return value must be sent back to connection but how to continue processing then for after-hook?

For your question about CallError or CallResult I don't yet have good ideas.

[villekr]

I did some prototyping with AWS API Gateway WebSocket API and AWS Lamda. The code is here: https://github.com/villekr/ocpp-serverless-example. API Gateway doesn't support occp-j endpoint format but it was good reference for what kind of data the event handler in Lambda would get.

In the example code now Call message is send to API Gateway WebSocket API and it trigger AWS Lambda. Within AWS Lambda Call message is routed using ocpp library to specific action handler and CallResult is sent back to Call initiator via WebSocket API.

I did not yet solve how to get CallResult/CallError back to Call initiator, which is awaiting response. In stateless serverless cloud environment this will need:

• Instead of asyncio.Queue() some cloud queue service must be used (e.g. SQS or Redis)
• Call initator polls that cloud queue after sending message to websocket
• CallResult/CallError handling puts incoming message to cloud queue, which enables Call initiator to continue

Also creating route map would be ideally done only once, which can be achieved by instantiating charging_station as global variable. Furthermore patching id and connection to charging_station before calling route_message are "hacky". So proper interface for building route map and then routing events should be defined.

[villekr]

Now prototype for event based message handling in AWS is fully functional. I introduced strategy pattern to allow changing response and after-hook behaviour. Also connection and queue are injected to ChargePoint object. In order to get this working I had to override route_message and _handle_call from ChargePoint. In AWS environment connection communicates towards API Gateway Websockets API and queue is implemented using Redis (instead of ChargePoint asyncio.Queue()).

I also drafted initial idea how ocpp library interface should be designed to allow event based message handling. Basically the idea is to create router once and then route message by providing invocation specific context.

Please provide any feedback about draft ocpp router interface.

The code is here: https://github.com/villekr/ocpp-serverless-example.

[OrangeTux]

Thanks for the suggestion. I'll have a look later.

[villekr]

I think that it would be good to model Router so that it conforms to ASGI signature but also can be used directly. Actually the Router should be the base class and ChargePoint should derive from that as a special kind of router having direct websocket dependency. I'll see if I have time to work idea towards that.

[OrangeTux]

I read through the code but I failed to understand it all. The implementation seems to be tied to AWS Lambda. I'm not familiar with that product.

A couple of things I don't fully understand.

1. What is the function of AWSResponseStrategy and AWSAfterHookStrategy?
2. What do you mean with 'call initiatior'? Is that a) the ChargePoint that calls ChargePoint.call() or is it b) a Call received from the remote peer?
3. I don't quite understand how Router.route() routes a message to the correct ChargePoint instance. Do you need to register to the Router? Can you elaborate on this topic?
4. I assume Router.route() should call route_message() on a ChargePoint instance, correct?

[villekr]

I've updated now the issue (#168) and related PR (#171). Please see my comments on the issue.

Maybe we can continue the discussion in the issue and close this discussion topic?

[OrangeTux]

Sure. Let's move discussion to those places.