MQTT and RS-485 on one platform: keeping both device generations in the same system

Many projects begin with an assumption that survives right up to the first site visit: "the devices can all connect to the network, right?"

The honest answer is usually no. Part of the fleet is recent: those devices speak MQTT, report on boot and accept commands. Another part was installed years earlier and offers nothing but an RS-485 or RS-232 port — no network socket at all. The client is not asking for two systems and two dashboards. The client wants one platform that shows every device.

This is how we handled that split on a central management platform for connected equipment.

First, accept that old devices will not go online because you built a platform

The device side of that project was genuinely divided.

• The newer devices ran MQTT, with a steady heartbeat, status reporting and a downlink channel for commands.
• The older devices had only a serial port (RS-232 or RS-485 class), collected locally by an industrial PC or gateway. The collection program was written in Java and talked to the hardware through a serial library.

Most general-purpose IoT platforms support one of these two worlds, and it is almost always MQTT. That leaves two familiar options: replace every old device, or build a small separate system and sync its data into the main platform. The first is a cost the client may not accept. The second reliably grows into two sets of definitions and two sets of operations — the problem the client was trying to escape.

We took a third path: two parallel adapter layers inside one back end, unified above by one model.

Two channels, each minding its own segment

The pipeline splits into two channels that do not interfere with each other.

The MQTT channel. On the platform side we keep three roles: connection configuration (broker address, authentication and reconnection policy), a send-and-receive service (subscribing to topics, publishing downlink messages), and a processing service that parses inbound messages into internal device state.

The serial channel. This side handles the serial parameters itself — baud rate, data bits, parity, stop bits — manages opening, reading and releasing the port, and parses the incoming byte stream per device protocol. We used a Java serial library, split into two classes: one describes how to connect, the other how to read and write.

What matters is how the two channels look from above. Their implementation is separate, but they expose the same capabilities: device online and offline, status reporting, command dispatch, exception alarms. The business layer never knows whether it faces an MQTT or a serial device.

Collapsing both into one model: device, command, scene

Above the two channels we standardised on three layers.

• Device — unique identifier, type, location, current state, last heartbeat. Whatever sits underneath, the device object has the same shape.
• Command — downlink abstracted as a form: command type, target device, parameters, timeout, retry. An MQTT device receives the message as it is; for a serial device the collection side translates it into the matching serial frame.
• Scene — "when this condition is met, trigger this action on this group of devices". One scene can reference MQTT and serial devices together.

The value shows up later, when the fleet changes. Adding an MQTT device means one more connection; adding a serial device means one more serial configuration. The automation on the business side does not move.

Is the old equipment worth saving? Three accounts to run

When a client asks whether to adapt or replace, we do not answer with a principle. We run three accounts with them.

• Replacement cost. The device, the installation work, and the downtime. On an industrial site the downtime is often the largest of the three — larger than the hardware.
• Value of the data. A reading someone glances at once a day, or something watched second by second? If the requirement is closer to meter reading, serial collection is enough.
• Remaining life. If the fleet is due to be retired within three years, the adaptation investment is hard to recover. If the equipment has eight years ahead, the adapter layer is a good buy.

Most of the time the answer is neither extreme: key equipment networked and read directly, edge equipment through a gateway with serial aggregation. That is why we keep both channels in the platform — a client should not have to replace working equipment to adopt a new platform.

Where the data lands: why we reach for a time-series database

Device data has a distinctive shape: written constantly, queried by time, almost never updated. In ordinary relational tables it becomes uncomfortable to query once you pass a few million rows.

On the device-data side of that project we used a time-series database, with device tables created as time-series hypertables and partitioning and compression optimised around the time dimension. Pulling the history curve for one device over a time range stays responsive, and we keep the ability to join against the existing business database (MySQL or PostgreSQL).

Our rule of thumb: if the point count is in the hundreds and sampling is at minute level, a relational database is sufficient. At a few thousand points with second-level sampling, introduce the time-series database during design. Migrating afterwards costs far more than adding one more table at the start.

When we recommend replacing the device instead

Having argued for the adapter layer, its boundaries deserve equal clarity. Three situations where we advise against protocol adaptation:

• The device can no longer communicate reliably. If the serial link drops and the checksum error rate is high, no adapter layer will recover the data quality.
• The hardware does not support what is needed. Remote firmware upgrades, or parameters outside the device's internal registers, are not features you can add from the platform side.
• Security rules do not allow it. Some older devices have no authentication at all. Connected, they become a weak point inside the network. Here the work is network isolation and access control first, the platform second.

The lesson that carried over

The most valuable result of that project was not MQTT or serial support. It was the discipline of separating protocol adaptation from the business model.

Once the two were apart, we reused the same structure elsewhere: charging infrastructure monitoring, condition and reliability management for industrial equipment, and field-service apps reporting data back from site. The protocols were all different; the upper layer was the same device-command-scene structure every time.

For a client, that means something practical: you do not have to decide at project kick-off how every device communicates. Fix the model first; protocols can be added later — but start from a device inventory and a communication audit, because that list is what makes the platform decision easy. This work sits under our hardware-connected software practice; see Hardware & IoT.

Read the original Chinese note

All technical notes