Skip to main content

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

  1. Each Edge/gateway connects to the Backend over a websocket and pushes TimestampedDataNotifications (channel values plus timestamps).
  2. TimedataInfluxDb.write(edgeId, ...) converts the edge name to an integer, then writes points into the one data measurement, each tagged edge=<number>, with fields = channel addresses (for example _sum/EssSoc, meter0/ActivePower).
  3. 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, pi2 are safe (1, 3, 2); a hillary-test-pi-1 is not, because it collides with nfetestpi1.
  • 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 edge tag, not by site name, so a collision is invisible unless you check the raw edge tags.