Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ocpp library as an event based message handler #168

Open
villekr opened this issue Jan 19, 2021 · 4 comments
Open

ocpp library as an event based message handler #168

villekr opened this issue Jan 19, 2021 · 4 comments
Labels
enhancement New feature or request

Comments

@villekr
Copy link
Contributor

villekr commented Jan 19, 2021

Enhancement issue based on original discussion topic: #165.

Main motivation for this is to:

  • Allow ocpp library usage without tight decoupling with websocket
  • Introduce ASGI compliant interface for http and websocket messages
@villekr
Copy link
Contributor Author

villekr commented Jan 25, 2021

Current branch in PR #171 supports now the following usages:

  1. Current way of bundling both websocket connection and routes within one class, which derives from version specific ChargePoint classes (see examples/v16/central_system.py)
  2. (New) stateful event based way where Central System holds Charging Station instances and based on id routes messages to correct instance (see examples/v16/central_system_asgi_stateful.py).
  3. (New) stateless event based way where messages are routed directly to correct action handler and it's up to action handler to figure out based on context-argument charging_station related information (see examples/v16/central_system_asgi_stateless.py).

Both new ways implement ASGI interface and therefore must be run behind ASGI server (e.g. uvicorn).

Current implementation should now give clear idea of change but will still require quite a much polishing to make usage clear.

The final goal is to implement also ASGI http.request handling but this will be out of scope of ocpp library in my opinion as the implementation will be heavily environment specific (e.g. AWS).

@OrangeTux OrangeTux mentioned this issue Jan 26, 2021
26 tasks
@villekr
Copy link
Contributor Author

villekr commented Feb 25, 2021

I've been lately too busy on other work so haven't been able to proceed any further with this. However, my plan is to next try to make a "ASGI first" version and then try to think how current ocpp implementation would fit to that model.

@villekr
Copy link
Contributor Author

villekr commented Apr 6, 2021

Quite a much time has passed since I had time to proceed with this change. But now I have a next iteration draft ready. Let me first review what has been done so far:

  • The first iteration was a prototype event based approach (to be able to run ocpp central system as serverless). Code is here: https://github.com/villekr/ocpp-serverless-example. Conclusion: serverless approach seems doable but code was just sort of hack.
  • The second iteration was an attempt to modify ocpp library so that it would support both current ChargePoint based and event based stateless approaches. Code is here: ocpp library as an event based message handler #168 #171. Conclusion: the observation is that event based approach can't be implemented without braking compatibility with the ChargePoint based approach. Also the library interface and usage will get a bit confusing when there are two ways how library can be used.
  • The third iteration was an attempt to try to think "ASGI first". I also realised that (obviously) ASGI approach is relevant only for Central System implementation (i.e. it can't be used as such for Charging Station implementation). Of course the original motivation for this whole change originatest from Central System implementation and e.g. challenges on scalability. So, this time I wrote ASGI support as a separate library, which depends on ocpp. Code is here: https://github.com/villekr/ocpp-asgi. Conclusion: From the central system implementation perspective the ocpp-asgi library has familiar concepts like ocpp but handlers have different signature to support fully event based and stateless approach. I had to copy and modify on and after decorators to work a little bit differently as well as add small changes to routing methods.

The code is by no means polished but the intention should be now clear. Please review the code a let me know what you think about the road ahead. I have no specific interest to start maintaining this library specifically so if this ocpp library can be extented to this direction then I'm happy to collaborate. However, at the same time I feel that ocpp-asgi -library tries to solve a different problem as ocpp -library. So in a way, it could also be it's own library.

@villekr
Copy link
Contributor Author

villekr commented Jul 26, 2021

I've worked further to enable even based message handling (and ultimately running OCPP as serverless e.g with AWS Lambda). The library has evolved to 0.2.0 version, which could be stated as an alpha version. It has ASGI compliant interface and supports WebSocket as well as HTTP events (HTTP is what makes serverless possible).

ASGI approach is relevant only when implementing Central System so it's even more clear that this must be a separate library.

Please see and if anyone is interested or has business need for something like this then please let me know.
https://github.com/villekr/ocpp-asgi

I've also described the motivation and cloud architecture iterations that have inspired to continue this work.
https://ville-karkkainen.medium.com/towards-event-based-serverless-ocpp-backend-system-part-i-motivation-and-architecture-options-5d51ba09dfd6

@Jared-Newell-Mobility Jared-Newell-Mobility added the enhancement New feature or request label Sep 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

2 participants