Building a multi-node IIoT System with NORVI X and MQTT Broker

Introduction: Why multi-node IIoT Needs a Different Architecture

A single IoT controller monitoring one machine cell is straightforward. You connect the sensors, write the firmware, publish to an MQTT topic, and you are done. Scaling that to a factory floor with 20, 50, or 200 monitoring points — each with its own set of analogue inputs, digital states, and RS-485 instruments — is a fundamentally different engineering challenge.

The instinct is to build one large controller with enough I/O to cover everything. In practice, that approach creates a single point of failure, forces long cable runs across the facility, and makes firmware updates a plant-wide maintenance event. Industrial deployments need distributed nodes — small, independent controllers located close to their sensors — connected through a shared communication backbone.

The NORVI X is built for exactly this architecture. Its ESP32-S3 core, hot-swappable modular I/O, and built-in MQTT client make it the natural building block for a modular IIoT system MQTT deployment. This article covers how to design the node architecture, structure the MQTT topic hierarchy, configure the broker, and wire everything from field sensors to a Grafana dashboard — across as many nodes as the application requires.

NORVI X as a Modular IIoT System MQTT Node

Before looking at multi-node architecture, it is worth understanding what makes the NORVI X the right choice as the repeating unit in a distributed IIoT deployment.

Self-Contained Processing and Connectivity

Each NORVI X node runs an ESP32-S3-WROOM-1U-N16R2 dual-core processor at 160 MHz with 16 MB flash and 2 MB PSRAM. That compute capacity handles Modbus RTU polling across an RS-485 bus, analogue input sampling from AI4 expansion modules, digital state reading from DI16 modules, local data buffering on the onboard microSD card, and MQTT publishing — all simultaneously and without task starvation.

Connectivity options cover every facility topology. The X1 variant uses Wi-Fi 802.11 b/g/n and Ethernet for wired plant networks. The X2 adds a SIMCOM A7672 cellular modem for nodes in areas without local network access. The X3 uses a Quectel EC25 modem for high-speed 4G LTE. Because every node manages its own connection independently, a network failure at one node does not affect any other.

Hot-Swappable I/O Expansion

The modular I/O architecture is what makes NORVI X the correct foundation for a modular IIoT system MQTT deployment. Each node starts with the CPU module and expands through I²C-connected expansion modules — AI4 for 4–20 mA analogue inputs, DI16 for sixteen-channel digital state acquisition, UART-IO for RS-485 Modbus instruments, R8 and R4 relay output modules, and RTD4 for PT100/PT1000 temperature probes. Modules are hot-swappable, so field engineers adjust node I/O capacity without powering down the control system.

A node deployed at a compressor station might carry one AI4 module for pressure and temperature sensors, one UART-IO module for a Modbus energy meter, and one DI16 module for run/fault/alarm states. A node at a conveyor line might carry two DI16 modules and one relay output module. Each node’s physical I/O footprint matches its local application — and the MQTT payload structure reflects that.

Designing the MQTT Topic Hierarchy for Multi-Node Systems

In a multi-node IIoT deployment, MQTT topic design is as important as hardware selection. A well-designed topic hierarchy makes data routing, dashboard configuration, and access control straightforward. A poorly designed one creates a maintenance problem that grows with every node you add.

Payload Structure and Timestamping

Every NORVI X node carries a DS3231 precision real-time clock that maintains accurate timestamps through power interruptions. The firmware assembles each MQTT payload as a JSON object containing the device ID, an ISO 8601 timestamp from the DS3231, and a data object with channel keys and values. Because every payload carries a hardware timestamp — not a broker receipt timestamp — time-series data remains accurate even when network latency varies or when the broker is temporarily unreachable and the node buffers payloads to the microSD card for later delivery.

Broker Setup: From Mosquitto to Cloud-Managed MQTT

The MQTT broker sits at the centre of a modular IIoT system MQTT architecture. Every NORVI X node publishes to the broker; every dashboard, alarm processor, and data pipeline subscribes from it. Broker selection and configuration directly affect system reliability and security.

On-Premises Broker with Mosquitto

For plant networks without internet connectivity, Eclipse Mosquitto running on a Linux server or industrial PC is the standard choice. Mosquitto is lightweight, handles thousands of concurrent connections, and supports TLS 1.2 with client certificate authentication. Configure the broker with persistent sessions so that nodes reconnect after a network interruption and receive any messages they missed while offline. Set message retention on status topics so that a new subscriber immediately receives the last-known state of every node on connection.

Place the Mosquitto broker on a server with a static IP on the plant LAN. Each NORVI X node points to that IP at port 8883 for TLS-secured MQTT. The broker’s access control list restricts each node’s publish permissions to its own topic namespace — node-03 cannot publish to node-07’s topics, which prevents accidental or malicious data pollution.

Cloud-Managed Broker: AWS IoT Core and Azure IoT Hub

For deployments where NORVI X nodes connect over 4G LTE or where remote visibility without a plant-network VPN is required, cloud-managed brokers remove the operational overhead of running your own MQTT infrastructure. AWS IoT Core and Azure IoT Hub both support certificate-based mutual TLS authentication, per-device policy enforcement, and direct integration with time-series storage and analytics services.

The NORVI X X3 variant with the Quectel EC25 modem publishes directly to AWS IoT Core or Azure IoT Hub over 4G LTE using signed X.509 certificates stored in the device firmware. Because the certificates are device-specific, even if a node is physically compromised in the field, its credentials cannot be used to access any other node’s data. This security architecture is a baseline requirement for any modular IIoT system MQTT deployment in regulated industries.

Wiring the Field Layer: Sensors to NORVI X Nodes

Each NORVI X node connects directly to its local sensors and instruments without any intermediate gateway hardware. This direct-connection architecture reduces failure points and simplifies commissioning.

Analogue Sensors via AI4

Connect 4–20 mA two-wire transmitters — pressure sensors, level transmitters, temperature transmitters, flow transmitters — directly to the AI4 expansion module’s current input terminals. The AI4 provides loop power for two-wire transmitters and accepts both current and voltage signals on each channel. Wire the transmitter positive terminal to the AI4 channel input and the negative terminal to the signal ground. The firmware reads each channel on a configurable polling interval and publishes the engineering-unit-converted value over MQTT.

Digital States via DI16

Connect machine status outputs — motor run contacts, fault relay contacts, limit switches, proximity sensors — to the DI16 module’s optically isolated input terminals. Connect the digital signal to the channel input terminal and the signal common to the DI16 ground. The optical isolation prevents ground loops between the machine control system and the NORVI X node — critical in environments with VFDs, welding equipment, or other high-frequency switching loads nearby.

RS-485 Instruments via UART-IO

Wire the RS-485 A and B terminals from the Modbus instrument to the UART-IO expansion module’s RS-485 interface. Install a 120-ohm termination resistor at the far end of the RS-485 bus if the node is not the last device on the line. Configure the Modbus polling parameters — device address, register map, baud rate, and parity — in the node firmware. The UART-IO module polls the instrument at the configured interval, parses the register response, and feeds the decoded values into the same MQTT publish pipeline as the AI4 and DI16 data.

From MQTT Broker to Grafana Dashboard

Once all NORVI X nodes publish to the broker, the final step connects the broker to a visualisation platform. Grafana with an InfluxDB time-series backend is the standard open-source stack for industrial IIoT dashboards.

A Telegraf agent subscribes to the NORVI X topic hierarchy using a wildcard subscription and writes incoming JSON payloads directly into InfluxDB, using the node ID and channel name as measurement tags. Grafana queries InfluxDB and renders per-node trend panels, digital state timelines, alarm history tables, and multi-site comparison views. Because the topic structure is hierarchical and consistent across all nodes, Grafana dashboard templates use variable substitution to cover every node at every site without manual panel duplication.

For teams that prefer a managed cloud option, NORVI Cloud provides hosted MQTT ingestion and dashboard capability natively configured for NORVI X nodes. Either way, the modular IIoT system MQTT architecture scales linearly: adding a new node means commissioning the hardware, assigning a node ID, and pointing the firmware at the broker. The dashboard template picks up the new node automatically through wildcard subscriptions.

Store-and-Forward: Handling Network Interruptions

Industrial networks are not perfectly reliable. Cellular coverage fluctuates, plant Wi-Fi has dead spots, and Ethernet switches reboot during maintenance windows. A production-grade modular IIoT system MQTT deployment needs to handle network interruptions without losing data.

Each NORVI X node writes telemetry payloads to the local microSD card when the MQTT broker is unreachable. The firmware maintains a write pointer and a read pointer in the SD card log. When connectivity restores, the node reads from the SD log in chronological order and publishes the buffered payloads to the broker before switching back to live publishing. The broker receives the backfill payloads with their original DS3231 timestamps, so the InfluxDB time series shows no gaps — even for outages lasting hours.

This store-and-forward behaviour requires no configuration. It operates automatically as part of the NORVI X firmware architecture, and the SD card capacity — up to 256 GB — provides years of local buffering capacity at typical industrial polling rates.

Conclusion: NORVI X Delivers a Production-Ready Modular IIoT System MQTT Platform

The combination of NORVI X nodes, a structured MQTT topic hierarchy, and a time-series broker-to-dashboard pipeline produces a modular IIoT system MQTT architecture that scales from a single machine cell to a multi-site industrial network without changing the fundamental design. Each node operates independently, contributes its data to the shared broker namespace, and fails gracefully through local SD buffering.

For systems integrators designing plant-wide IIoT infrastructure, OEMs embedding monitoring capability into production equipment, and engineers building multi-site utility monitoring networks, the NORVI X multi-node architecture delivers the distributed intelligence, open connectivity, and field-proven reliability that industrial deployments require. Commission one node, validate the data pipeline, and replicate across the facility – one NORVI X at a time.