MyEMS: an open source energy management system with industrial protocol coverage

The standard comes first, the dashboard comes second

MyEMS is an open source energy management system, and the first thing the introduction says is that it refers to the ISO 50001 energy management system standard, with the Chinese national standard GB/T 23331-2020 given alongside it.

That framing decides what the software is for. The system is meant for collecting, analysing and reporting energy and carbon emissions, and the list of media is long, electricity, water, gas, cooling and heating, and the list of sites is equally long, buildings, factories, shopping malls, hospitals, parks, and the energy and carbon management centres that oversee them.

The readme also states the scale it claims, nearly a thousand project cases and a testing certification from the CMA, and describes the project as developed and maintained by a company of senior professionals in order to ensure long-term support. Those are the project's own statements, and they are the sort of claim worth testing against a deployment of your own rather than taking at face value.

The repository is MIT style permissive in spirit and carries a licence file that the hosting platform cannot classify, and the last push was on 2026-10-19. The release line is the six series, with 6.7.0 on 2026-07-26, 6.8.0 on 2026-08-29 and 6.9.0 on 2026-09-27, and the readme commits to a small version every month and a large one every year.

The module list is the architecture

The repository is a multi-service application, and the directory names describe the design better than any diagram would.

The protocol collectors are the interesting part, because industrial metering is a protocol problem before it is a data problem. There is myems-bacnet, myems-modbus-tcp, myems-opc-ua and myems-s7, which covers the four building and industrial protocols a site engineer is most likely to meet between them, and the fact that they are separate services rather than one collector with plug-ins is a statement about how much each one differs from the others.

Around them sit the services that make the collected numbers useful. myems-aggregation is the layer that receives the readings, myems-normalization turns what the meters report into comparable values, myems-cleaning deals with the data quality problems that every metering deployment has, and myems-api is the interface. On top of that sit myems-web, the site facing application, and myems-admin, the administration console.

There is a database directory for the schema and the migrations, a docs directory, and an others directory for the parts that do not have a name of their own.

The split also tells you where the hard parts of this kind of system live. Aggregation and normalisation are where a meter that reports a scaled integer, in a unit that depends on the register, becomes a number in kilowatt hours that can be charted against a tariff, and cleaning is where the gap in a series gets filled rather than plotted as a straight line through a night with no data.

Community and enterprise are two products in one repository

The readme splits the documentation in two, with a features page for the community edition and another for the enterprise edition, and the difference is worth understanding before you plan a deployment.

The introduction describes the enterprise additions as optional functions, and the list is long. Photovoltaics, energy storage, charging piles, microgrids, virtual power plants, equipment control, fault diagnosis, work order management and artificial intelligence optimisation.

Read that list as two groups. The first four, photovoltaics, energy storage, charging piles and microgrids, are about the site generating and storing and consuming power, which changes the shape of the energy data because the site is no longer a pure consumer. Virtual power plants take that further, aggregating several sites into one that can trade.

The second group, equipment control, fault diagnosis and work order management, is what turns a monitoring system into an operations system, because a number on a chart that nothing acts on is a report, and a number that raises a work order against a specific machine is a system.

The community edition is the part that collects, analyses and reports the energy and carbon numbers, and the enterprise edition is the part that acts on them. The open source repository contains the code for both, which is a notable arrangement, and it means the boundary between the two is a matter of configuration and of which documentation page you read rather than of which repository you clone.

Ten mirrors and twenty-one readme translations

Two details in the readme are unusual enough to be worth reading on their own.

The first is the download list. The community edition is available from ten places, and the readme marks the first as recommended. The list runs from GitHub through Gitee, Bitbucket, GitLab, GitCode, Gitlink, AtomGit, Gitea and Codeberg to a Launchpad repository, which is a spread that says something about where the project's users are and about the reliability of a single host for a deployment that has to keep running.

The second is the language list. There are twenty-one readme files, and they are the visible half of a translation effort: Simplified and Traditional Chinese, English, German, Spanish, French, Italian, Dutch, Polish, Portuguese, Russian, Japanese, Korean, Arabic, Persian, Thai, Hindi, Indonesian, Malay, Turkish and Vietnamese.

That count tells you something the rest of the readme does not. A project that ships twenty-one translations of its documentation is a project with an international user base, and it is also a project whose day to day communication happens elsewhere, because the support channels named in the readme are QQ and WeChat groups.

For an English speaking adopter this is the part to plan around. The documentation exists in English, the community is in Chinese chat platforms, and the code is the part that has to be read.

The badges tell you how the project is checked

The quality signals in this repository are unusually varied, and each one covers a different failure mode.

There is a CodeQL scanning workflow, which is GitHub's static analysis for security patterns, and it matters more in a system that talks to building equipment over industrial protocols than it would in an ordinary web application. There is a Scrutinizer code quality badge and a Scrutinizer build status badge, and a Codacy grade badge, so three separate analysis services are pointed at the same tree.

The commit history tells the rest. The release cadence claimed in the header, one small version each month and one large one each year, is visible in the tag dates, with 6.7.0, 6.8.0 and 6.9.0 in three consecutive months of the third quarter of 2026, and the last push on 2026-10-19.

The documentation site has a large screen dashboard presentation and a set of web and admin interface screenshots, which is the sort of thing that tells you the front end is a real application rather than a reporting page, and that the system is expected to be displayed on a wall in a control room as well as opened on a laptop.

The architecture diagrams in the repository, a function view, a site view and a data flow diagram, are the other thing to read before anything else, because they are the only place where the relationships between the services are drawn.

Support through chat groups, and a promise of permanence

The support model is stated in one line in the header, free technical support within the QQ and WeChat groups, and it is the piece of the project a non-Chinese adopter has to think about hardest.

A QQ group is a chat room, not a forum. Answers arrive as messages, they are searchable only as far as the group retains them, and the timezone and language are the author's. There is a community page and a contact page on the site, and the readme commits to permanent open source, which is a statement of intent rather than a technical guarantee.

What the readme does describe in detail is the version policy, and that is the thing that tells you how the project treats the people running it. A small version every month and a large one every year is a schedule a site engineer can plan around, because the monthly releases are the ones that carry fixes and the annual one is the one that carries the migrations.

The topics on the repository match the scope of the system, energy consumption, energy efficiency, energy management, energy monitoring, energy storage, microgrid and photovoltaics, with a large screen dashboard as the visible surface.

So the shape of the project is clear. An application server with a database and a set of protocol collectors, a reporting layer aligned to a management system standard, a community edition for measurement and an enterprise edition for control, and a support community that lives in two Chinese messaging apps.

Editorial conclusion

MyEMS fits a site engineer who has to collect meter data from a mixed building, some Modbus meters, a BACnet chiller and an OPC UA server, and who has to report electricity, water, gas, cooling and heating against a compliance standard, because the collectors and the reporting live in one repository and the system is designed around the ISO 50001 shape of an energy management programme. It is the wrong choice if your estate is small, because the deployment is an application server with a database and a set of services rather than a tool you point at a spreadsheet, and it is the wrong choice if you need support in English, since the community channels are QQ and WeChat groups. Before you deploy it, read the community and enterprise feature pages side by side, because the optional functions are the difference between the two editions, and check the protocol list against the meters you actually have.

Frequently asked questions

Official sources

1. Issues
2. MyEMS/myems on GitHub
3. Project website
4. README
5. Releases