Modbus MQTT Integration for Secure Energy Monitoring
How read-only PLC data, Sparkplug B and ISO 50001 support secure energy visibility.
A Modbus MQTT energy-monitoring integration is a read-only architecture that collects utility data from Modbus-connected meters and PLCs, then publishes controlled telemetry to an MQTT broker without writing back to the production network.
Manufacturing plants often hold useful energy data inside electrical meters, boiler controls, compressed-air meters, flowmeters and PLC networks. Modbus RTU and Modbus TCP make those values accessible locally. MQTT provides a practical transport for sending selected, contextualised readings to authorised monitoring systems.
The challenge is not simply extracting a register value. It is preserving control-system integrity while making each value trustworthy, traceable and secure. That requires defined read-only polling, a controlled OT boundary, engineering metadata and a clear approach to message delivery.
Why Modbus MQTT energy monitoring integration matters
Modbus remains common in manufacturing because meters, PLCs, drives and utility instruments have supported it for decades. A plant may have Modbus devices at main incomers, distribution boards, boiler houses, refrigeration plant, compressors and process skids.
A typical register map can expose:
- Voltage, current, power factor and active power
- Cumulative electricity consumption
- Gas, water, steam and compressed-air flow
- Totalised utility consumption
- Temperature and pressure measurements
- Equipment status, runtime and alarm signals
Those registers do not create a complete energy record on their own. Register 40127, for example, has little value outside its commissioning documentation unless the receiving system also knows its asset identity, unit, scale factor, data type, timestamp and quality.
ISO 50001:2018 provides the management-system context. Clause 9.1 requires an organisation to determine what it will monitor and measure, the methods it will use, when monitoring takes place, and when it will analyse and evaluate results. Granular sub-metering supports that requirement where a site needs to understand significant energy uses. The acquisition design must preserve enough information to show how readings were obtained and whether they remain valid.
MQTT does not dictate when a gateway publishes; gateway configuration does. A site could poll active power every 10 seconds, publish it every 60 seconds, and send an earlier update where measured kW changes by more than 5% from the last published value. A cumulative kWh register might publish every 60 seconds regardless of change, allowing the data record to identify communication gaps and counter resets. These engineering choices should be documented against the monitoring purpose.
Omni Vision delivers turnkey utility metering, CO2 tracking, and AI-powered production KPI intelligence — giving you real-time dashboards and actionable insights across your entire facility.
Modbus and MQTT perform different jobs
Modbus retrieves field values
Modbus uses a request-response model. A Modbus client requests defined registers from a server device, then interprets the returned words according to the supplier’s register map.
Read-only energy acquisition should allow only the function codes required by the approved device list. Common examples include Function Code 03 for holding registers and Function Code 04 for input registers. The configuration should exclude write functions, including Function Codes 05, 06, 15 and 16, unless a separately authorised control application requires them.
The gateway must also account for common register-map issues:
- Register-address offsets between supplier documentation and client software
- Signed and unsigned integers
- Floating-point format, byte order and word order
- Scale factors and decimal placement
- Instantaneous values and cumulative totalisers
- Valid ranges, rollover behaviour and reset conditions
A value can be technically readable but still wrong. A 32-bit kWh counter with reversed words may look plausible while producing a false trend. Commissioning should compare selected Modbus readings with the source meter display and a known operating condition.
MQTT distributes selected telemetry
MQTT Version 5.0 is a client-server publish/subscribe messaging transport protocol. A gateway publishes messages to an MQTT broker, and authorised applications subscribe to relevant topics. The broker distributes messages without requiring each consumer to poll a meter or PLC.
This separation matters in OT environments. The gateway handles Modbus polling and register conversion close to the field network. Energy-monitoring services receive named measurements rather than raw register words. A cloud service does not need direct access to a meter, PLC or engineering workstation.
MQTT payloads are application-defined. The protocol does not automatically add asset names, engineering units, timestamps, quality indicators or context. The integration team must define those elements before data leaves the OT zone.
IEC 61131-3 and non-invasive PLC access
IEC 61131-3:2025 defines programming languages for programmable controllers, including structured text, ladder diagram and function block diagram. Many established PLC applications were built and validated in programming environments based on that standard.
That context affects connectivity design. Adding a communications function block, tag-processing logic or cloud credentials to a production PLC can trigger change control and increase commissioning risk. Where an approved Modbus interface already exists, a separate read-only gateway can collect designated values without changing the PLC programme, task execution or control configuration.
The interface scope should state this explicitly: no PLC logic changes, no new PLC write services, and no command path from the MQTT environment to the controller. Any exception should follow the plant’s formal engineering, safety and validation process.
Secure Modbus MQTT acquisition architecture
Keep Modbus within the OT segment
Traditional Modbus was designed for local industrial communications. It should remain within a defined OT network segment rather than traverse the internet or become directly reachable from enterprise systems.
The gateway should connect only to approved devices and poll only an authorised register list. Its configuration record should include the device address, poll interval, timeout, permitted function codes, data type, engineering unit, scale factor and intended use of each reading.
The UK National Cyber Security Centre advises organisations to restrict industrial protocols such as Modbus to isolated OT segments. It also recommends brokering OT-to-IT data exchange through a demilitarised zone, using secure standardised protocols such as MQTT over TLS.
Select the boundary control by risk
NIST SP 800-82 Rev. 3 identifies OT security as a discipline that must account for safety, reliability and performance as well as confidentiality. A secure Modbus MQTT bridge should therefore be selected through an OT risk assessment, not copied from a generic IT integration pattern.
For many plants, a hardened gateway in the OT zone can establish a tightly controlled outbound connection to an approved MQTT service through a DMZ. Firewall policy should restrict the destination, port, protocol and identity. The design should avoid inbound access from cloud services to PLCs, meters and gateways.
A unidirectional gateway, often called a data diode, may be appropriate where the consequences of a return path into OT are unacceptable. NIST SP 800-82 Rev. 3 describes unidirectional gateways as hardware that permits data transmission in one direction. The NCSC also recommends a unidirectional secure transfer mechanism when operational data is replicated into a DMZ.
Account for MQTT transport behaviour
MQTT normally runs over a bidirectional transport connection. A conventional end-to-end MQTT client session therefore cannot pass unchanged through a hardware data diode. The design needs a local service that receives telemetry on the OT side and a separate relay or replicated service beyond the one-way boundary.
A data diode can preserve one-way data movement, but it changes how connection state, acknowledgements and delivery retries work. The receiving-side service should identify missing messages and report a data-quality condition rather than attempting to re-establish a connection into OT.
Directive (EU) 2022/2555, the NIS2 Directive, requires in-scope essential and important entities to apply proportionate cybersecurity risk-management measures. Article 21 includes risk analysis, incident handling, supply-chain security, access control and assessment of control effectiveness. It does not prescribe a gateway or broker topology. A documented one-way boundary may form part of a proportionate control set where the risk assessment supports it.
For UK facilities, the NIS2 Directive does not apply directly in the same way as it does in EU Member States. UK operators in scope should consider the Network and Information Systems Regulations 2018 and relevant regulator guidance. NIS2 requirements may also affect UK manufacturers that support EU-based customers or groups.
Track energy consumption, emissions, and process parameters with seamless PLC/SCADA integration via Modbus, OPC-UA, and MQTT protocols.
MQTT payloads and Sparkplug B interoperability
Publish engineering values rather than register numbers
An MQTT message should identify what the value means. A useful energy reading needs, at minimum, an asset identifier, metric name, value, unit, timestamp and quality state.
A gateway might publish active power as kW and cumulative consumption as kWh. It should distinguish a device timestamp from a gateway timestamp. It should also identify whether a value is measured, calculated, stale, invalid or unavailable.
This information allows a consumer to treat measurements correctly. A missing kWh totaliser reading needs a different response from a power value that remains unchanged for several minutes.
Use Sparkplug B where interoperable state matters
MQTT leaves the topic namespace, payload representation and session-state model to the implementation. That flexibility can create an integration burden when each gateway supplier or site uses a different convention.
The Eclipse Sparkplug 3.0.0 specification defines an MQTT topic namespace, state-management behaviour and structured payload approach for industrial systems. Sparkplug B provides the payload model used by current Sparkplug implementations. It supports richer metrics, metadata, timestamps and session-awareness messages.
For Modbus MQTT energy-monitoring integration, Sparkplug B can standardise:
- Gateway and device identity
- Metric names, data types and units
- Device and gateway connection state
- Birth and death messages
- Metric metadata and timestamps
- A consistent topic namespace across sites
Sparkplug B improves interoperability. It does not secure an OT connection by itself. Network segmentation, broker permissions, certificate lifecycle management and gateway hardening remain separate responsibilities.
Design topics around access control
Topic names should allow the broker to apply least-privilege access. A gateway should publish only to its approved branch. A monitoring system should subscribe only to the utility, site or asset data required for its function.
Avoid placing passwords, API keys, personal information or detailed security configuration in topic names or payloads. Retained MQTT messages need equal care. A retained value can give a newly connected subscriber the latest known meter state, but it does not replace a time-series record and should carry an explicit timestamp and quality status.
Securing the Modbus MQTT bridge
Treat the gateway as an OT asset
A gateway is not a passive cable between old and new protocols. It stores configuration, communicates with OT devices and holds credentials for external services. It needs an asset owner, patching process, configuration backup and controlled administrative access.
A secure baseline should include unique administrator credentials, removal of unused accounts, role-based access, controlled firmware updates and restricted physical access. The site should also retain a tested configuration backup so replacement hardware can be restored without improvising register maps or permissions.
Encrypt and authenticate the MQTT connection
TLS should protect MQTT traffic crossing the OT boundary. Where supported by the gateway and broker, client certificates provide a stronger machine identity than a shared password. The broker should apply permissions at topic level so that each identity can publish or subscribe only where it has an approved need.
Certificate management needs operational ownership. The team should record the issuing authority, expiry date, renewal process and revocation procedure. An expired certificate can stop energy-data collection unless the monitoring service identifies connection loss and informs the responsible team.
MQTT quality of service also requires deliberate selection. QoS 0 may suit frequent, non-critical values where occasional loss is acceptable. QoS 1 can create duplicate delivery, so consumers should handle messages idempotently using timestamps, sequence numbers or message identifiers. Quality of service controls message-delivery behaviour. It does not validate that a Modbus value has the correct unit or scaling.
Preserve data quality through communication faults
A secure link still needs measurement integrity. The system should record whether the gateway received a valid Modbus response, whether the value passed range checks and whether the timestamp remains within the permitted age.
| Condition | Meaning | Recommended handling |
|---|---|---|
| Good | The gateway obtained and validated the value | Permit use in approved monitoring calculations |
| Stale | The last valid value is older than the configured limit | Flag the affected period for review |
| Bad communication | The device did not return a valid response | Exclude the value from automated conclusions |
| Suspect scaling | The value conflicts with known meter or process limits | Check register map, multiplier and wiring |
| Counter reset | A cumulative totaliser falls unexpectedly | Record the reset and validate subsequent consumption |
Quality flags prevent missing telemetry from being interpreted as zero consumption. They also distinguish a genuine energy event from a gateway, network or meter fault.
Commissioning a read-only Modbus MQTT integration
Define and test the approved acquisition scope
Commissioning should begin with a joint review involving controls, maintenance, OT security, IT and energy-management stakeholders. The team should agree the devices, registers, utility streams, intervals and data owners before connecting a gateway.
The approved register list should state the Modbus function code, address, data type, scale factor, unit, expected range and polling interval for every measurement. Test each selected value against the physical meter display, a calibrated reference or a known operating state.
Demonstrate read-only operation
The acceptance test should confirm that the gateway performs only its declared read requests. Packet capture, gateway logs and firewall logs can provide evidence. The test should also verify that no Modbus write function is configured and that MQTT-side identities cannot create a command route to the gateway or PLC.
Test fault conditions before handover:
- Meter timeout or invalid Modbus response
- Loss of MQTT broker connectivity
- Gateway restart and local buffering behaviour
- Certificate expiry or rejected client identity
- Counter rollover or meter reset
- Loss of the monitoring path while production continues
Loss of energy-monitoring connectivity must not affect PLC control, safety functions or local operator access.
Maintain the interface as plant equipment changes
Meter replacements, PLC upgrades, network-address changes and certificate expiry can undermine a previously sound integration. The responsible team should review data quality, security events and change records at defined intervals.
A maintained register list, current network diagram and periodic comparison against source-meter readings protect the monitoring record. These controls extend the useful life of installed OT assets while keeping data acquisition separate from production control.
This article reflects the independent analysis and editorial opinion of EnerTherm Engineering. Product names, trademarks, and brands mentioned belong to their respective owners. EnerTherm Engineering is not affiliated with, endorsed by, or a licensee of any third-party software or product mentioned unless explicitly stated.
Simulation Engineer — EnerTherm Engineering
Rajesh Sekar is a Simulation Engineer at EnerTherm Engineering, specialising in computational fluid dynamics (CFD), finite element analysis (FEA), and thermal process simulation. He holds a degree from Cranfield University and brings extensive experience in simulation-based product development from the automotive, aerospace, and energy sectors.
