TDengine

MQTT QoS 1 Suits Most Industrial Telemetry; Duplicates Need Handling

Image
MQTT QoS 1 Suits Most Industrial Telemetry; Duplicates Need Handling

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.

Five-Boundary Trace Pinpoints Missing MQTT Historian Data

Image
Five-Boundary Trace Pinpoints Missing MQTT Historian Data

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.

TDengine MQTT Ingestion Needs a Schema Contract Before Mapping

Image
TDengine MQTT Ingestion Needs a Schema Contract Before Mapping

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.

TDengine Defines Industrial AI as Human-Reviewed Decision Support

Image
TDengine Defines Industrial AI as Human-Reviewed Decision Support

Global – October 27, 2026 -- TDengine is framing Industrial AI as decision support built on three layers (data, context and analysis) rather than as autonomous plant control, with accountability remaining with engineers and operators.

Industrial AI applies standard methods to physical operations

The approach uses machine learning, computer vision and generative AI on data from equipment, sensors, control systems, operational records and engineering documents. What makes an application industrial is the work it supports: pumps, compressors, production lines, energy systems and material flows. Enterprise AI, by contrast, mostly handles digital workflows such as drafting documents or summarizing meetings.

TDengine Guide: Historian Data Needs Context Before AI Training

Image
TDengine Guide: Historian Data Needs Context Before AI Training

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.

Knowledge Graphs give Industrial AI traceable plant context

Image
Knowledge Graphs give Industrial AI traceable plant context

Global – October 27, 2026 -- An Industrial Knowledge Graph links assets, measurements, events, documents and procedures as connected entities. This gives Industrial AI more relevant context than raw document search, according to a TDengine explainer for OT architects.

Graph links symptoms to causes, checks and approved actions

Nodes cover equipment concepts, fault conditions, maintenance procedures, rules, documents and events. Links express relations such as causes, applies to, requires or precedes. A compressor alarm, for example, can be tied to its troubleshooting procedure, operating conditions and earlier investigation records.

Roller press case shows reuse of a hydraulic pressure investigation

A roller press shut down after hydraulic pressure fluctuated. The maintenance record captured the observed condition, a possible cause, the handling sequence, the pressure limit and required spare parts.

Industrial AI Data Platforms Should Be Judged by One Decision

Image
Industrial AI Data Platforms Should Be Judged by One Decision

Global – October 27, 2026 -- Plants selecting an industrial data platform for AI should start with a single operational decision, such as whether a reliability engineer must review a compressed-air pressure drop within an hour, rather than with a list of AI features. That decision defines the required sources, history, context, access controls and response time.

Four data sources feed the compressed-air pilot

The example pilot investigates periods when header pressure falls while compressor energy use rises. It needs PLC compressor state and control values, historian pressure, flow and power trends, IoT vibration readings, and maintenance records. None of these sources has to be replaced; the test is whether the evidence can be found, understood, governed and accessed together at the necessary time scale.

OPC UA Historians Need Alarm Records, Not Just Tag History

Image
OPC UA Historians Need Alarm Records, Not Just Tag History

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.