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.
Topic levels carry identity only when governed and stable
A topic such as plant-a/line-3/press-17/telemetry names a site, line, asset and message class. The JSON body should carry values that change over time, such as pressure, temperature, quality and event timestamp. If a device identifier can move position in a topic, or a level mixes identity with changing state, the durable identity should come from a payload field or an asset registry. The topic may reinforce the payload identity but should not contradict it without an explicit resolution rule.
TDengine supertables take shared tags while measurements stay as columns
In TDengine, a supertable defines a shared structure, and its subtables hold individual sources and carry the supertable's tags. The model needs a primary timestamp and at least one measurement column. Tags should be reserved for descriptive values shared by every row from a source, so a fast-changing value such as pressure does not belong in a tag. A table per physical asset suits regularly sampled telemetry, and separate supertables may be needed where device types or message classes use different measurement schemas. Arbitrary incoming field names should not be allowed to create columns, because that makes fleet-level queries unreliable.
Typed parsing rules block silent conversions after firmware changes
A numeric-looking value can arrive as a number, a quoted string, null or a different unit after a firmware update. The source recommends fixing the expected type and unit for each measurement, rejecting or quarantining non-numeric values, and defining whether null means unavailable, unchanged, omitted or malformed. Nested values should be extracted through named paths. Arrays should be split into records only when every element has a clear identity and timestamp.
Source event time must stay separate from ingestion time
Source event time should set the historical position of a measurement, with timezone, epoch unit or text format, allowed clock skew and post-reboot behavior validated. Using database arrival time after buffering or replay makes an old process condition look current. Ingestion time can be stored separately to expose delay, backlog recovery or gateway clock problems. Where no trustworthy event time exists, the historian's reliance on arrival time should be documented.
Mapping previews and two-asset test runs verify the contract
TDengine TSDB Enterprise's MQTT ingestion documentation describes topic analysis, a JSON extractor, mappings for table names, supertable names, ordinary columns and tag columns, and mapping previews. These implement a reviewed contract but do not define it. Sample messages should cover normal values, a missing optional field, a malformed value and a nested structure. Connector expressions should not be copied from examples without checking the deployed version.
Verification should publish controlled messages for two distinct assets, including a known timestamp, an expected unit, a null or missing optional field and a value that must be rejected. Queries should confirm that each asset resolves to its intended table, tags remain stable while measurements vary, event time and precision are preserved, and errors surface in the configured exception path. The check should be repeated after any producer software update or new asset type.