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.
Broker and subscriber checks come first
If the broker shows no evidence of the test message, table mapping is not the problem. Teams should check hostname, port, TLS listener and environment, since development and production brokers with similar topic names are easy to confuse.
On the subscriber side, topic matching is case-sensitive, and plant/+/pump07/pressure matches one intermediate level while plant/# can match several. The guidance lists further failure points:
- SUBACK results that show whether the broker accepted the requested filter or QoS
- Subscription permissions, which publishing rights do not imply
- Duplicate client IDs that displace the collector
- $share/... filters that spread messages across group members
Parsing and write errors can hide behind a running task
Plain MQTT prescribes no JSON schema, equipment identifier or timestamp field. A payload field named pressure_kpa will not populate a mapping that expects pressure without an explicit transformation. A rejected, null or out-of-range primary timestamp can fail the write while message intake continues.
TDengine's Enterprise MQTT connector, configured in taosExplorer, uses taosX to subscribe, parse and map data into tables. A task marked Running does not prove the row was committed. Exception strategies can archive, discard, report or cache invalid records, so a discarded record may leave no row and a cached one may not yet be queryable. Feature availability depends on product edition and deployment.
Five counts show where the record disappeared
Queries must cover the source timestamp window, not only the publish time, because replay or retry can separate the two. Teams then compare one published message, one broker receipt, one subscriber receipt, one accepted write and one queryable record. The break sits at the boundary just before the first count that diverges.