OpenEMS Backend InfluxDB Data Model and Edge-ID Collision
How the OpenEMS Backend stores time-series data from multiple Edge gateways in InfluxDB, and a naming gotcha that can silently merge two edges' data.
All edges write to one shared measurement
The backend's InfluxDB writer puts every edge's data into a single InfluxDB measurement, whose default name is data. There is no measurement (table) per edge or per site. Each data point is separated only by a tag.
Source: io.openems.backend.timedata.influx/src/io/openems/backend/timedata/influx/TimedataInfluxDb.java
.measurement(this.config.measurement()) // default "data" (Config.java)
.addTag("edge", String.valueOf(influxEdgeId)) // tag name "edge" (OpenemsBackendOem.getInfluxdbTag())
The tag value influxEdgeId is a number parsed from the edge's name by InfluxConnector.parseNumberFromName(edgeId).
The flow on the backend
- Each Edge/gateway connects to the Backend over a websocket and pushes
TimestampedDataNotifications (channel values plus timestamps). TimedataInfluxDb.write(edgeId, ...)converts the edge name to an integer, then writes points into the onedatameasurement, each taggededge=<number>, with fields = channel addresses (for example_sum/EssSoc,meter0/ActivePower).- A history query filters by
edge=<number>to pull back a single edge's data.
So all sites, gateways and meters live co-mingled in one measurement, distinguished purely by that numeric edge tag.
The gotcha: edges collide on their trailing number
The edge-name to number regex is \D++(\d++)$, which captures the trailing digits of the name:
| Edge name | Parsed edge tag |
|---|---|
| edge0 | 0 |
| nfetestpi1 | 1 |
| gw-aaron-pi-3 | 3 |
| hillary-test-pi-1 | 1 |
Two edges whose names end in the same digit map to the same edge tag, and their data merges in the shared measurement. The backend cannot tell them apart. This is a very plausible root cause of the "Hillary Test" meter appearing inside the Sezibwa microgrid: if the test gateway's name ends in 1 and the Sezibwa gateway nfetestpi1 also ends in 1, their channels land under edge=1 together.
There is a second failure mode: an edge name with no trailing number throws inside parseNumberFromName, so its data is silently dropped (a warning is logged, nothing is written).
Recommendation
- Ensure every edge name ends in a globally unique number (unique across the whole backend, not just within a site), because the InfluxDB tag is only that trailing digit.
nfetestpi1,nfetestpi3,pi2are safe (1, 3, 2); ahillary-test-pi-1is not, because it collides withnfetestpi1. - Give any test rig a non-colliding edge ID (for example a high number like
...-99) or keep it off the production backend entirely. - When auditing per-site data, remember that filtering is by the numeric
edgetag, not by site name, so a collision is invisible unless you check the raw edge tags.