Products/ EMU Professional II/ TCP/IP

Interface · EMU Professional II

TCP/IP on the EMU Professional II: 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.

Switch interface

M-BusRemote meter reading over two wires RS-485 / Modbus RTUFieldbus for control systems TCP/IPModbus TCP and MQTT on the network LoRaRadio without cabling of its own KNXFrom Q1 2027

Two routes out of the same socket

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.

View the EMU M-Center

Rule of thumb

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 valuesModbus TCP
Data needs to go to a cloud or a dashboardMQTT
Firewall allows no inbound connectionsMQTT, because it is outbound
Several recipients for the same valuesMQTT, through subscriptions
Existing SCADA speaks only ModbusModbus TCP
Many meters, several target systemsBoth, 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.

PDFTCP/IP interface manual1475 · Professional II · English PDFModbus register manual1485 · register table · English ZIPTCP/IP update toolFirmware update for the TCP/IP version PDFM-Center manual2151 · bundling and forwarding

Data flow

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.

  1. The meter sets up the connection itself – outwards, not inwards. The firewall therefore needs no inbound rule.
  2. Every measured value goes as a message to a topic. The topic structure determines how the values are assigned later.
  3. 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.
  4. 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.

Send an enquiry about this product

Phone
+41 (0)41 545 03 00

Technical support
helpdesk@emuag.ch

Orders Switzerland
orders@emuag.ch