IP power meter: EMU Professional II with Modbus TCP and MQTT
No fieldbus, no level converter – the TCP/IP version sits on Ethernet. Two fundamentally different approaches run over it: Modbus TCP fetches values, MQTT delivers them. The choice decides more about your architecture than about the hardware.
An IP power meter connects straight to the Ethernet network and provides its readings over TCP/IP. The EMU Professional II TCP/IP offers two protocols for this: Modbus TCP for control systems that poll the values, and MQTT for systems that receive them through a broker.
MID-certified (module B+D), active energy class B
Modbus TCP on port 502: the client reads the registers whenever it needs them
MQTT: the meter publishes to your broker – outbound, TLS-encrypted
fixed IP address or DHCP reservation per meter
EMU Professional II 3/100 for direct connection up to 100 A, 3/5 for CT connection
Order numbers
Version
Article number
Shop
EMU Professional II 3/100 TCP/IP – direct connection 100 A
What is the difference between Modbus TCP and MQTT?
There are two fundamentally different ways to access the measured values. Which one fits depends on your architecture – not on the meter.
Modbus TCP is a request-and-answer procedure: a client opens a connection and fetches registers whenever it wants. MQTT turns that around: the meter reports its values to a broker of its own accord, and whoever needs them subscribes. One is fetching, the other is delivering.
Modbus TCP
The same register model as Modbus RTU, just over Ethernet instead of RS-485. The CRC checksum is dropped, because TCP already handles that; instead every telegram carries an MBAP header with a transaction number and unit identifier. The standard port is 502.
Reading uses the same function codes as RTU, usually 3 and 4 for holding and input registers. 32-bit values are spread across two registers; the register addresses and the byte order are in the manual.
The practical advantage over RTU: several clients at once, no master monopoly, no silent interval, no topology questions. The drawback: every meter needs an IP address and a place in your network plan.
Port
502
Mode
Client asks, meter answers
Data model
16-bit registers, function codes 3 and 4
Typical for
Control systems, SCADA, automation
MQTT
MQTT works with a broker in the middle. The meter publishes its values under a topic – a hierarchical path such as building/basement/meter-03/energy – and everyone interested subscribes to that topic. Sender and receiver do not know each other; they know only the broker.
That solves two problems at once. First, nobody has to poll: values arrive when there are any. Second, the connection is outbound – the meter connects to the broker, not the other way round. As a result the firewall needs no inbound rule, which is what makes cloud connections practical in the first place.
QoS sets the delivery guarantee: 0 sends and forgets, 1 guarantees at least one delivery, 2 exactly one. For meter values QoS 1 is the usual compromise. TLS encrypts the connection.
Mode
Meter publishes, interested parties subscribe
Topic
hierarchical path, freely chosen
QoS
0, 1 or 2 – delivery guarantee
Typical for
Dashboards, cloud solutions, IoT platforms
The MQTT connection to dashboards and cloud solutions is reserved for the TCP/IP version.
Network
What does IT need for power meters on the network?
Fixed addresses
Meters polled over Modbus TCP need a stable address – either assigned statically or bound to the MAC address by DHCP reservation. A changing IP means the control system loses the device.
A segment of its own
Metering normally belongs in a VLAN of its own, separate from the office network. That makes firewall rules easier and stops a network problem in the office area from taking the billing data with it.
Firewall direction
For Modbus TCP the client has to reach the meter – an inbound connection into the metering network. For MQTT an outbound connection to the broker is enough. If data needs to leave the building, MQTT is therefore by far the simpler route through the firewall.
Firmware
For the TCP/IP version we provide a dedicated update tool; the download is further down.
Checklist before handing over to IT
Number of devices and IP addresses required
Static or DHCP reservation
VLAN and routing to the control system
For MQTT: broker address, port, TLS, credentials
A topic scheme that is still readable in five years
Topic scheme
Hierarchy by location and function rather than by device number. property/building/floor/measuring-point/quantity survives a device replacement; meter/0815 does not.
Use case
Power meters straight onto the network, or through the M-Center?
Both work, and the answer depends less on the meter than on the installation around it.
Straight onto the network
Sensible with few measuring points, where Ethernet is already in place, and when the target system speaks Modbus TCP or MQTT itself. Each meter is then a network node of its own, with its own address and its own upkeep.
The picture changes as numbers grow: twenty meters mean twenty IP addresses, twenty firmware versions and twenty places where a reading can quietly fail.
Through the EMU M-Center
The M-Center reads up to 60 devices over Modbus TCP and bundles them into a single point on the network. Instead of twenty devices, IT looks after one. And because the same device also serves M-Bus and Modbus RTU, meters from all three worlds end up in the same database.
On top of that comes what a single meter cannot do: 16 GB of storage for history, monitoring of error flags and outliers, and simultaneous forwarding to BACnet IP, OPC UA, MQTT, (s)FTP and email – control system, cloud and billing from one source, without three systems fighting over the same meter.
Up to about five measuring points and one target system: direct. Beyond that, or as soon as a second target system is added, the M-Center almost always pays off – not because of the technology, but because of operations.
Where it fits
Modbus TCP or MQTT – which suits what?
Control system needs to poll instantaneous values
Modbus TCP
Data needs to go to a cloud or a dashboard
MQTT
Firewall allows no inbound connections
MQTT, because it is outbound
Several recipients for the same values
MQTT, through subscriptions
Existing SCADA speaks only Modbus
Modbus TCP
Many meters, several target systems
Both, bundled through the EMU M-Center
Documents
Manuals and data sheets to download
This page explains the principle. Register lists, telegram structure, terminal assignment and the exact parameters of each version are in the interface manual.
How do the measured values reach Joulio-Web by MQTT?
The meter does not wait to be polled – it publishes its values itself. That changes how the firewall is configured, and lets several systems read the same value at the same time.
EMU Professional II TCP/IPMeter in the distribution board, RJ45 on the network. Publishes its measured values itself.
MQTT publish TLS
MQTT brokerAccepts the messages and distributes them to all subscribers of the topic.
subscribe TLS
Joulio-WebSubscribes to the topics, writes the values into the database and analyses them.
The meter sets up the connection itself – outwards, not inwards. The firewall therefore needs no inbound rule.
Every measured value goes as a message to a topic. The topic structure determines how the values are assigned later.
The broker distributes the message to everyone who has subscribed to that topic. Joulio-Web is one of those subscribers; a dashboard can be another.
The connections are encrypted with TLS. Without valid credentials the broker accepts no messages.
The route taken by measured values from the EMU Professional II TCP/IP through an MQTT broker into Joulio-Web. Because the meter sets up the connection, the direction of the firewall rule stays outbound.
Frequently asked questions
Frequently asked questions about the interface
What is the difference between Modbus TCP and MQTT?
Modbus TCP is fetching: a client opens a connection to the meter and reads registers whenever it wants. MQTT is delivering: the meter publishes its values to a broker, and anyone interested subscribes to them. Modbus TCP suits control systems and SCADA, MQTT suits dashboards and the cloud.
Which port does Modbus TCP use?
Port 502 by default. The CRC checksum of Modbus RTU is dropped, because TCP already secures the transmission; instead every telegram carries an MBAP header with a transaction number and unit identifier.
Why does MQTT get through the firewall more easily?
Because the connection is outbound: the meter connects to the broker, not the other way round. Modbus TCP, by contrast, needs an inbound connection into the metering network. As soon as data needs to leave the building, MQTT is therefore by far the simpler route.
Does every meter need a fixed IP address?
For Modbus TCP yes – either assigned statically or bound to the MAC address by DHCP reservation. A changing address means the control system loses the device.
At what point is the M-Center worth it instead of a direct network connection?
As a rule of thumb, from about five measuring points, or as soon as a second target system is added. The M-Center reads up to 60 devices over Modbus TCP, bundles them into a single network node, stores history in 16 GB and serves control system, cloud and billing at the same time.
How should I name the MQTT topics?
Hierarchically by location and function rather than by device number. A scheme such as property/building/floor/measuring-point/quantity survives a device replacement; naming by serial number does not.
Not sure whether TCP/IP fits?
Send us the number of measuring points, the distances and the target system. We will tell you which version makes sense – and when another interface would be the better choice.
With your consent, we use Google Analytics to see how this website is used. Google sets cookies and receives usage data, which may also be processed in the USA. You can change your choice at any time via "Cookie settings" at the bottom of the page. Privacy policy