Multi-Protocol IoT Device Integration

Most device manufacturers do not control every component of the products they sell. A heat pump manufacturer sources controllers from one supplier and sensors from another; an industrial washing machine OEM integrates motors, PLCs, and user interfaces from different vendors, each with its own communication protocol and data format.

The result is a portfolio where every product line speaks a different language.

The challenge with protocol fragmentation​

Protocol fragmentation is one of the most common structural problems in connected product development:

• Modbus RTU and Modbus TCP are dominant in HVAC, industrial, and building automation, but each device exposes different register maps with different data types and scaling factors.
• OPC-UA is the de facto standard for industrial communication, supported by virtually all major equipment manufacturers. While it provides a rich, standardized data model, integrating it requires a dedicated protocol adapter running close to the equipment.
• MQTT is widely used for direct cloud connectivity, but every manufacturer structures their topic hierarchy and payload format differently.
• Proprietary serial protocols are common in appliances and industrial equipment where legacy hardware was designed before any open standard existed.
• HTTP webhooks: some devices and gateways push telemetry to cloud endpoints via HTTP. The transport is standard, but the payload format is entirely vendor-defined.

Without normalization, each protocol requires a separate integration: a separate data pipeline, a separate schema, separate application code that handles each device type differently. The operational cost of this fragmentation grows with every new product line.

What it takes to get it right​

Normalizing data from multiple protocols requires:

1. Protocol-specific adapters, code that speaks the native protocol of each device type, handles its quirks, and extracts the meaningful data.
2. A unified internal data model, a common schema to which all incoming data is mapped, regardless of origin. This is what makes cross-product aggregation and unified dashboards possible.
3. Configurable mapping rules, the mapping from a specific device's native format to the unified model must be configurable without code changes, because device firmware updates change payload formats.
4. Edge-side execution, for devices on constrained or intermittent networks (Modbus, OPC-UA), the protocol adapter must run close to the device, not in the cloud.
5. Legacy device support, devices already deployed in the field cannot be recalled. The integration layer must handle them as-is, including protocol versions and firmware quirks that may no longer be documented.

How Connhex solves it​

Connhex Mapper is the data normalization layer. It accepts incoming data in any format (MQTT messages, Modbus register reads, OPC-UA data points, HTTP payloads) and maps them to Connhex's internal unified data model using configurable transformation rules.

The mapping is defined per device model: when a new device type is added to the platform, you define a mapping configuration that specifies which incoming fields map to which internal attributes, with type conversions and scaling where needed. No code changes are required.

Connhex Edge runs on-premises or at the edge, close to the devices. For protocols like Modbus and OPC-UA that require LAN proximity, Connhex Edge acts as the protocol gateway: it polls devices on the local network, applies the Mapper transformation, and forwards normalized data to the cloud. This architecture supports fully air-gapped device networks. The OPC-UA Bridge addon provides dedicated support for OPC-UA servers, enabling data collection from industrial equipment by Siemens, Rockwell Automation, Schneider Electric, ABB, and others.

The result is that your backend, application, and monitoring systems work with a single, consistent data model regardless of which product line the data came from. A single dashboard can show data from an HVAC thermostat using Modbus, industrial equipment using OPC-UA, and a gateway using MQTT, because all of them have been normalized to the same internal representation.

What this means for product and engineering teams​

For product teams, the benefit is a unified operational view: one dashboard, one alerting system, one data export pipeline across the entire portfolio, regardless of how many different protocols are involved.

For engineering, adding a new product line with a different protocol doesn't require a new backend. Define a Mapper configuration for the new device type and everything downstream (monitoring, rules, notifications, apps) already works. Portfolio expansions and acquisitions that would previously have required months of integration work become a configuration exercise.

See it in practice​

I discovered Connhex after an in-depth technological scouting phase. It has proven to be by far the best solution for our needs: nothing even comes close.

Paolo Zigoni

CTO - Astrel Group

Multi-protocol integration is central to the HVAC and industrial use cases, where product portfolios almost always span multiple protocols:

Connhex for HVAC · Connhex for Industrial Washing Machines

Read the technical docs​

• Connhex Mapper, Introduction
• Connhex Edge, Introduction
• Edge Addons, OPC-UA Bridge
• Installing Connhex Edge