Factory energy monitoring gives every line, shift and product a measurable energy footprint instead of one monthly utility bill. In this guide you will plan the meter layout, design an MQTT topic structure that scales from one building to several sites, store meter counters correctly, and build reports that show kWh per line, per shift and per part.
Why the Utility Bill Is Not Enough
The monthly invoice tells you what the plant consumed, not why. It cannot separate the paint shop from the assembly line, a productive shift from an idle weekend, or a well-tuned machine from one whose hydraulic pump runs flat out while waiting for parts. Without that breakdown, energy remains an overhead that nobody owns.
A factory energy monitoring system changes the conversation. When a line manager sees that their line used a similar amount of energy on Saturday, with no production, as on a normal shift, the question "what was running?" answers itself. When energy per part is visible next to OEE, energy becomes a production KPI rather than a facilities problem.
The Building Blocks of a Factory Energy Monitoring System
| Layer | Typical components | Role |
|---|---|---|
| Measurement | Main utility meter, sub-meters per feeder, line and large machine; gas, water and compressed air meters | Produce raw counters and instantaneous values |
| Edge | Modbus gateway, PLC, industrial PC or Raspberry Pi with Node-RED or Python | Poll meters, add timestamps, publish MQTT |
| Transport | MQTT broker | Decouple publishers and consumers, deliver live data |
| Storage | Time-series database such as InfluxDB or TimescaleDB, via Telegraf or a custom subscriber | Keep history for reports |
| Context | Production schedule, machine states, part counts | Turn kWh into energy per shift and per part |
| Presentation | Grafana, Node-RED dashboard, BI tool | Show trends, comparisons and alerts |
The MQTT broker is the hinge of the design. Meters publish once; the historian, the live dashboard, an alerting script and a future MES integration all subscribe independently. If you are choosing where that broker should run, a fully managed MQTT service keeps it available without adding a server to the maintenance team's workload.
Step 1: Decide Where to Meter
Start from the electrical single-line diagram and the list of significant energy users. A common, affordable sequence:
- Incomer: the main meter, ideally read every few seconds rather than relying on the utility's 15-minute data.
- Main distribution feeders: one meter per building, hall or major area.
- Production lines: one meter per line distribution board.
- Large individual consumers: compressors, chillers, furnaces, injection moulding machines, large presses.
- Other utilities: natural gas, steam, water and compressed air flow.
Each step adds resolution. You do not need everything on day one; you need enough to answer the first business question. The detailed wiring and Modbus polling for step three and four are covered in the electrical sub-metering tutorial.
Step 2: Design the Topic Structure
A topic hierarchy based on ISA-95 (enterprise, site, area, line, cell) keeps data findable and maps to how people think about the plant. ConnectMQ detects ISA-95 and Unified Namespace style topics and shows devices by these levels in its portal.
connectmq/<site>/<area>/<line>/<asset>/energy
connectmq/plant1/assembly/line1/main-board/energy
connectmq/plant1/assembly/line2/main-board/energy
connectmq/plant1/molding/imm-04/drive/energy
connectmq/plant1/utilities/compressors/comp1/energy
A meter payload should carry both cumulative counters and instantaneous values:
{
"ts": 1760600000,
"kwh_total": 183452.7,
"kw": 42.6,
"kvar": 11.2,
"pf": 0.97,
"v_l1": 231.4,
"i_l1": 61.8
}
Publish kwh_total as the meter's own cumulative register, never as a value the gateway sums from power readings. Counters survive gateway restarts and missed messages: if three messages are lost, the next counter value still contains the energy used in between.
Step 3: Store the Data
Telegraf's MQTT consumer is a quick way to land the data in InfluxDB, with tags extracted from the topic levels. It connects to the broker as a normal MQTT client:
[[inputs.mqtt_consumer]]
servers = ["ssl://broker.connectmq.com:8883"]
topics = ["connectmq/plant1/+/+/+/energy"]
client_id = "YOUR_CLIENT_ID"
username = "YOUR_USERNAME"
password = "YOUR_PASSWORD"
qos = 1
persistent_session = true
data_format = "json_v2"
[[inputs.mqtt_consumer.topic_parsing]]
topic = "connectmq/+/+/+/+/energy"
tags = "_/site/area/line/asset/_"
[[inputs.mqtt_consumer.json_v2]]
measurement_name = "energy"
timestamp_path = "ts"
timestamp_format = "unix"
[[inputs.mqtt_consumer.json_v2.field]]
path = "kwh_total"
type = "float"
[[inputs.mqtt_consumer.json_v2.field]]
path = "kw"
type = "float"
[[inputs.mqtt_consumer.json_v2.field]]
path = "pf"
type = "float"
[[outputs.influxdb_v2]]
urls = ["http://localhost:8086"]
token = "${INFLUX_TOKEN}"
organization = "plant"
bucket = "energy"
A persistent session with QoS 1 means messages published while Telegraf restarts are queued for it by the broker (within the session expiry).
Step 4: Energy per Line and per Shift
Because you store counters, energy for any period is simply the counter at the end minus the counter at the start. In InfluxDB's Flux language, kWh per line for one shift looks like this:
from(bucket: "energy")
|> range(start: 2026-10-15T06:00:00Z, stop: 2026-10-15T14:00:00Z)
|> filter(fn: (r) => r._measurement == "energy" and r._field == "kwh_total")
|> spread()
|> group(columns: ["line"])
|> sum()
spread() returns maximum minus minimum per meter, which equals consumption for a monotonic counter; the group and sum add the meters of each line together. Watch for meter replacements or counter rollovers, which create a step downwards; flag them in the data rather than silently correcting them.
Shift boundaries belong in configuration, not hard-coded queries. A small table of shift start and end times per site, or shift events published by the MES on a .../shift topic, lets the same dashboard work for every plant.
Step 5: Energy per Part
Energy per part (or per tonne, per batch, per square metre) is the KPI that connects energy to production. You need the part count for the same line and period, which your production counting setup can publish next to the energy data:
energy_per_part = kWh(line, shift) / good_parts(line, shift)
Use good parts, not total parts, so scrap shows up as an energy cost too. Compare the value across shifts and products, but remember that it is never zero: the idle base load of a line is spread over fewer parts on a slow shift. Separating base load from variable load, for example with a simple regression of kWh against parts, gives a fairer picture and is the basis of the energy baselines that ISO 50001 asks for, explained in collecting ISO 50001 energy data.
Dashboards That People Use
A useful set of views for different audiences:
| Audience | View | Refresh |
|---|---|---|
| Line supervisor | Live kW of their line, kWh this shift vs. target, idle consumption since last part | Seconds to minutes |
| Plant manager | kWh per line per day, energy per part trend, top 10 consumers | Daily |
| Energy manager | Base load by night and weekend, peak demand, power factor, comparison with baseline | Daily and monthly |
| Maintenance | Abnormal consumption per machine, compressor specific power, leak estimate | Live and weekly |
Night and weekend base load is often the quickest win. Plot consumption from Friday evening to Monday morning per area: anything flat and high deserves a walk-through. Compressed air is a frequent culprit, and compressed air leak monitoring quantifies it.
Alerts
Live alerts work best for conditions someone can act on right now: a line drawing power long after the shift ended, demand approaching a contracted peak, a power factor dropping below the penalty threshold. In the ConnectMQ portal you can define threshold alert rules on numeric fields such as kw or pf, and breaches appear in the alerts log. Routing those events to email or chat is done by an external subscriber such as Node-RED.
Common Mistakes
- Summing power instead of reading energy counters. Lost samples become lost kWh.
- Unsynchronised clocks. Gateways without NTP shift data between shifts. Timestamp at the edge with synchronised time.
- CT ratio errors. A wrong current transformer ratio in the meter configuration multiplies every reading. Verify each meter against a clamp meter once.
- Too many dashboards, no owner. Assign the energy KPI of each line to its manager.
- Data stuck in one tool. Publish everything to the broker first; tools come and go, the topic structure stays.
For the broader roadmap of connected production, including where energy sits next to OEE, quality and maintenance, read the smart manufacturing guide.
Run Your Energy Monitoring on ConnectMQ
ConnectMQ is a cloud MQTT broker with TLS on port 8883, MQTT 5, an ISA-95 aware devices view, a live topic explorer and threshold alerts. Try your first meter on the public broker, then create a free Serverless broker with no credit card and scale to paid or dedicated plans as more meters come online.
Frequently Asked Questions
How many meters does factory energy monitoring need?
Start with the incomer, one meter per production line and meters on the largest individual consumers. That is usually enough to find the first savings, and more meters can be added later without changing the architecture.
How often should energy meters publish?
Every 5 to 60 seconds is typical. Faster publishing helps live dashboards and demand alerts, while reports depend on the cumulative counter and are not affected by the interval.
Can I use existing Modbus meters?
Yes. A gateway polls the meters over Modbus RTU or TCP and publishes the values as JSON over MQTT. Most modern multifunction meters expose energy counters and instantaneous values in documented registers.
Does ConnectMQ store historical energy data?
No. ConnectMQ delivers live messages and retained values. Long-term history is stored by a subscriber such as Telegraf writing into a time-series database.
