OpenEMS Edge Hardware - Help

English Forum
1

Hello,

I am building a battery energy storage application and recently discovered OpenEMS which appears to suits my needs perfectly.

I have a basic question about deploying the OpenEMS edge in a production context which I was not able to answer from the documentation.

What type of hardware can I deploy the OpenEMS on? I read on the site that it can be deployed on many commercial IOT Gateway devices, but is it possible to get a more concrete list of the types of IOT Gateway that are suitable - e.g requirements such as:

  • Processor
  • Operating system
  • Required I/O ports
  • Memory
    etc

Or ideally a list of IOT gateways which have been found to be suitable and effective for other users.

After selecting a suitable IOT Gateway edge device, is there any more information about what needs to be done to prepare the device and deploy my application on it?

Any help with this topic would greatly be appreciated!

Thank you.

2

Hi Thomas and welcome to the OpenEMS Community.

As OpenEMS Edge is Java-based it runs on every operating system. In practice a lot of developers use Windows for development, but productive IoT devices usually run Linux. Most of them rely on Debian.

The lowest spec hardware we currently run in production is a Beaglebone Black. This is what I would consider the minimum tested requirements.

Processor: AM335x 1GHz ARMĀ® Cortex-A8
512MB DDR3 RAM
4GB 8-bit eMMC on-board flash storage

Source: BeagleBoneĀ® Black - BeagleBoard

OSGi was originally made for even much weaker devices so with some development effort these requirements could be decreased even more, but this is what we use successfully in production.

Other IoT gateways that have been successfully tested:

After you chose the device you need to consider your deployment and update strategy:

If your operating system supports systemd (like Debian, Ubuntu, etc.) you can follow the docs: Deploy OpenEMS Edge :: Open Energy Management System. Regarding the update strategy, we use Debian packages natively, combined with some custom scripts. If you are interested to join forces here, please get in touch.

Alternatively you may use a separate IoT infrastructure, that e.g. allows you to deploy OpenEMS Edge (and UI) via Docker containers. You can find examples for creating custom Docker containers here in the forum.

Please keep us updated on the progress.

Regards,
Stefan

PS: Please consider joining the OpenEMS Association if you plan to use OpenEMS in production. Itā€™s not obligatory, but it helps us advertising the idea of an ā€œOpen Source Energy Management for the 100 % Energy transitionā€. Thanks!

3

Thank you Stefan. I had let this topic sit as we worked on other aspects of our project but I am ready to move forward again now.

It looks to me like the KunBus Revolution Pi is the most appropriate solution for our needs.

I was wondering if you (or anyone else) has any experience with this solution?

I am particularly interested in understanding how to get OpenEMS working with the Modbus interfaces on the RevPi - it has both RS485 (for Modbus RTU) and Ethernet (for Modbus TCP) interfaces - our chosen system setup will make use of both of these.
I would like to understand how to make OpenEMS talk to these interfaces - perhaps this is an easy problem to solve but I suppose you donā€™t know until you try it out.

We are ordering the hardware at the moment so I am trying to anticipate the next challenge.

Would greatly appreciate any knowledge sharing on this topic :slight_smile:

Thomas

4

Hi Thomas,

the kunbus revolution pi is working fine with OpenEMS. We are working with the Revolution Pi Connect+. It is a very robust hardware, it has a stable kernel and it also has Modbus RTU support. OpenEMS already has support for Kunbus Modbus RTU, Modbus TCP, Hardware Watchdog and the Data IO enhancement boards. I will try to merge our latest Kunbus driver to the official repository in the next couple of days. It provides more flexible handling of the Data IO enhancement boards.

Regarding modus, for Driver bundle it does not make a big difference if you use Modbus TCP or Modbus RTU. You simply need to create a Modbus Bridge (either TCP or RTU). Then you enable your driver and add the component id of your Modbus Bridge to that driver (see an example here).

For Modbus-RTU you need to take care of the device and especially the access rights. Kunbus has the following device chain:

#> ls -l /dev/ttyRS485
lrwxrwxrwx 1 root root 7 May 14 18:43 /dev/ttyRS485 -> ttyUSB0

# ls -l /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 May 21 19:07 /dev/ttyUSB0

To access the Modbus RTU hardware your OpenEMS needs to have either root rights or it needs to belong to the group dialout. In our case we have added the user running OpenEMS to the group dialout and then we configure the Modbus RTU Bridge to use the device /dev/ttyRS485.

Chris

2 Likes
5

Hi Chris,

Thank you very much for this information - it definitely helps make us feel at ease with the choice of the RevPi.
I am going to place an order for the RevPi Connect S and will use this as the basis for our prototype.

Thank you for the guidance on how to get the modbus connection working with the RevPi. I will revert back to you if I have any questions once we receive our hardware.

Best of luck
Thomas

6

Hi Thomas,

we uploaded a PR for the Revpi. You find it here:

Just a short note, because it may take some time until it is merged into the develop branch.

1 Like
7

Hi Christian,

Thank you for this and for sharing the latest version of the BSP.

In your previous message, you mentioned that it is necessary to create the bridge, then enable the Kunbus driver and add the component ID of the modbus bridge to the driver.

It is not clear to me how to enable the Kunbus driver based on your previous message. If you could please explain this it would be greatly appreciated.

Thanks.
Thomas