I have been working on connecting two edges using Edge2Edge. I successfully established the connection between the two edges.
Now, I want to further develop this setup. Suppose the two edges are not on the same network but are both connected to the same backend hosted on the cloud(for example, AWS). Is there a way to use the backend as an intermediate to enable communication between the two edges?
If there are other methods to connect two edges that are not on the same network, I would really appreciate your insights.
This is not existing yet, but as the Backend can proxy JSONRPC-Requests via Websocket, it should be able to implement something like this. Have a look at Bridge.Edge2Edge.Websocket and try to send those requests to Backend and from there to the other Edge.
Be prepared for communication delays, of course.
It would still be interesting to find more about the actual use-case - i.e. what exactly are you trying to achieve - and why?
If it’s just a MVP, I would simply connect the two devices via VPN.
My goal is to perform an edge2edge communication between OpenEMS edges when Modbus is not feasible. An example is reading from and controlling one or more edges (slaves) from another edge (the master). I am seeking a robust, long-term solution rather than using a VPN. In cases where grouping the edges on the same network is not reliable due to the distance between them.
I successfully implemented this communication by developing a WebSocket bridge reader that allows the master edge to subscribe to the channels of the slave edge. The WebSocket reader receives a JSON response every cycle, processes this response, and forwards the channel values to virtual devices that represent the real devices of the slave edge on the master edge.
For example, an ESS is implemented on the slave edge. On the master edge, I have a virtual ESS combined with a WebSocket bridge reader. This bridge subscribes to the ESS channels, extracts values such as activePower and other channels, and forwards them to the virtual ESS to represent the real ESS of the slave edge.
On the slave edge side, I implemented a WebSocket bridge writer (slave side). That subscribes to the debugSetActivePower channel (from master). The bridge writer processes the subscription response and forwards this value to an ESS remote controller, which controls the real ESS on the slave edge based on what applyPower sets on DebugSetActivePower on the master edge.
The problem (the same as with modbus edge2edge) I encountered is that applyPower is triggered every cycle and sets 0 on debugSetActivePower if no ESS controller is activated, instead of setting null. This behavior limits the local controller (for example, an ESS balancing controller) because the writer receives 0, and the ESS remote controller doesn’t allow the lower-priority controller (local) to work. Instead of receiving null and allowing the local balancing controller on the slave edge to control the ESS.
Ideally, when the master edge does not control the slave ESS, applyPower on the master edge should be set to null (or not be triggered at all) so that the slave edge can control its own ESS. However, this change should not affect the global behavior of applyPower or impact real ESS devices implemented directly on the master edge.
My question is, is there a way to make applyPower on the virtual ESS set null or not trigger until the master edge has an ESS controller, without changing the global behavior of applyPower and without impacting the real ESS implemented on the master edge?
The problem (the same as with modbus edge2edge) I encountered is that applyPower is triggered every cycle and sets 0 on debugSetActivePower if no ESS controller is activated, instead of setting null. This behavior limits the local controller (for example, an ESS balancing controller) because the writer receives 0, and the ESS remote controller doesn’t allow the lower-priority controller (local) to work. Instead of receiving null and allowing the local balancing controller on the slave edge to control the ESS.
Ok - understood. That is something that should be fixed in the Edge2Edge implementation then. Currently the assumption is, that the Edges are fully remote controlled and do not have a fallback controller. Doing this logic via DebugSetActivePower is certainly not a good standard way of solving that.
My question is, is there a way to make applyPower on the virtual ESS set null or not trigger until the master edge has an ESS controller, without changing the global behavior of applyPower and without impacting the real ESS implemented on the master edge?
Well the issue here is, that applyPower currently takes in int, so it always sets a value. A workaround could be to use a configuration on Edge2Edge that interpretes 0 as null. That could - depending on the use-case - still be wrong, of course.
Sorry to jump in, I might totally misunderstand your requirement or the OpenEMS architecture here. To my understanding, this is what the Backend (Master) ↔ Edge(s) (Slave) concept is for: