Creating a local controller

[1madison24]

I am attempting to add a local controller to the micro ocpp project from your account. I have been able to create a websocket server based on your WebSocketsServer implementation but am having trouble being able to send messages from the client back to the server.

Messages from the server are being received from the client but even simple 'Hello World' messages are not being received back to the server from the client.

In order to test my websocket connection I am using the Pie Socket google chrome connection which allows the Send message functionality. Currently I am using messageReceived to attempt to serial print these messages. While messageReceived was considered a protected function by the WebSocketsServer file I did make a little edit since your MicroOcpp implementation only focused on the client side.

Do you have any insight into creating a local controller in microocpp that allows an ESP32 board to connect to the MicroOCPP Simulator as well as have a client board that would also be another ESP32?

If you have any more questions on the way I am attempting to implement this I would be happy to share.

[matth-x]

Hi Madison, I'm not sure I understand how you want to use MicroOcpp in this case. Can you explain your goals a little more?

Generally, MicroOcpp is an OCPP client. The Simulator combines this OCPP client with an HTTP server for providing graphical controls in the browser. There are ways of extending this but the more you need to break out of the intended purposes, the more hacking will be necessary.

[1madison24]

While this specific code is an OCPP client I have implemented the WebSocketsServer file to create a server side for the esp32 board. A local controller is basically a middle man for the SteVe server and the charge point client while the local controller acts as a server and a client. The local controller helps maintain communication and load management. Although I have moved past the step of creating a server I am now stuck on the communication. I have been able to send simple "Hello world" messages (I have been testing through a Pie Sockets extension on google chrome) but I now need to implement the RequestQueue to specifically send OCPP messages to and from the local controller esp32. My client boards, the charge points, will also be other esp32. When I implement RequestQueue my code compiles but while running there seems to be some sort of memory leak. Do you have any tips for how to move forward?

[matth-x]

Okay, I see. I think that starting with the RequestQueue is a good idea. But first things first:

The Operation classes (e.g. Authorize, BootNotification, ...) included in MicroOcpp don't contain any Central System (CS) functionality. For each operation type which the Local Controller (LC) and the EVSEs send to each other, you need to subclass Operation and implement the server-side functionality on the LC. A subclass for an operation which the LC sends to the EVSE would look similar to FirmwareStatusNotification. You can finally initiate this operation by calling RequestQueue::sendRequest(...) with an instance of the custom operation.

For the opposite direction, i.e. when an EVSE sends an operation which the LC processes, you also need to create Operation subclasses for each possible operation. Take GetLocalListVersion as an example of an Operation subclass which handles an incoming operation. Incoming operation classes must be accessible to the OCPP lib over a factory, the OperationRegistry. Each incoming operation is registered with its operation type an a instantiation function. To set the OperationRegistry up, use its registerOperation function.

I would instantiate a separate RequestQueue for each connection between the LC and the subordinate EVSEs. For the connection between the LC and the CS, the default RequestQueue should be good. The process of building the network would look like this: first initialize the OCPP lib normally with an ordinary WebSocket client. Then, start the WebSocket server. When the WS server on the LC accepts a new socket, instantiate a new Connection and a new RequestQueue and pass the Connection to the Queue. The constructor of RequestQueue expects a Model and FilesystemAdapter instance (leave both nullptr) and an OperationRegistry. I would create a new OperationRegistry for each LC-charger connection, because then you can parametrize the instantiation function with the socket descriptor from the WebSocket server and so on.

If you suspect an illegal memory access, I would suggest to enable the debugging features of the host system. For example, PlatformIO allows to set

monitor_filters =
    esp32_exception_decoder

which prints a stack trace whenever the controller crashes.