Technical Guidance

Global – October 27, 2026 -- QoS 1 is the practical starting point for most industrial telemetry over MQTT, but none of the three QoS levels guarantees a complete historian, according to engineering guidance tied to the OASIS MQTT 5.0 standard.

QoS 1 reduces the risk of losing a message on an MQTT delivery hop. The receiving system must tolerate duplicates. QoS 0 fits replaceable readings where low overhead matters more than complete delivery. QoS 2 is reserved for flows where duplicate delivery on that hop is unacceptable and the extra protocol exchange is justified.

MQTT QoS covers one sender-receiver hop, not the whole pipeline

The OASIS MQTT 5.0 standard defines QoS for a single delivery flow. A device publishing to a broker is one flow. The broker sending to a subscribing collector is another, and it can use a different QoS depending on the original publication and the subscriber's granted maximum.

Global – October 27, 2026 -- Industrial teams can locate missing historian records by tracing one test message across five boundaries: broker receipt, subscriber receipt, parsing, database write and query. The approach comes from troubleshooting guidance on TDengine's MQTT ingestion, which warns that a live broker feed or a connected publisher proves only part of the chain.

One tagged test message anchors the diagnosis

Engineers should publish a single message for one equipment tag through the approved production path, such as plant/line2/pump07/pressure. They should log the exact topic, payload bytes, broker timestamp, publisher identity, destination table and intended source timestamp. Each test needs a fresh timestamp, because identical timestamps can make a successful write indistinguishable from an earlier one.

Global – October 27, 2026 -- An MQTT message is only a topic plus a payload, so a usable historian record needs four additions: stable equipment identity, typed measurements, a trustworthy timestamp and a schema that survives device and site growth. Engineers should settle these before configuring ingestion into TDengine TSDB Enterprise. Skipping that step can produce technically successful writes that create tables that are hard to query, compare or maintain.

Global – October 27, 2026 -- A historian export of tags and timestamps is rarely a training-ready dataset for Industrial AI, according to TDengine guidance that tells engineers to establish what each measurement means, when it happened, which asset produced it and whether it is reliable before data reaches an external model-training workflow.

Engineers define the pump decision before selecting data

For a centrifugal pump, the guiding question is whether a reliability engineer should review the pump given its recent operating signals. That differs from asking a model to declare the cause of a failure. Records created after a maintenance decision must not become inputs, because they would not exist when the model makes its prediction.

Global – October 27, 2026 -- A pump pressure trend shows when a value left its normal range but cannot show which alarm changed state, what severity the server reported, or when an operator acknowledged it. Those answers sit in separate OPC UA records, and historian designs must decide which questions each record has to answer.

Tag history stores values, not alarm lifecycles

An OPC UA client collects a variable through a monitored item. When DataChange criteria are met, the server sends a DataValue that the historian can store with source timestamp, server timestamp, and StatusCode, depending on the collector mapping. Sampling, deadbands, queues, and timestamp selection determine how much process behavior survives.