MQTT design should define device identity, topic hierarchy, timestamps, quality, QoS and offline replay. Higher QoS is not automatically more reliable because storage, sessions and platform deduplication also matter.
Key Takeaways
- Topics should be stable and scalable
- Telemetry and commands should be separated
- Offline data should retain original acquisition time
Technical Principle and Project Value
MQTT design should define device identity, topic hierarchy, timestamps, quality, QoS and offline replay. Higher QoS is not automatically more reliable because storage, sessions and platform deduplication also matter. In a real project, topics should be stable and scalable and telemetry and commands should be separated must be considered in the same architecture. Begin with the workload, field devices and operating model rather than one marketing specification.
Parameters to Confirm During Implementation
A practical sequence is to confirm broker and authentication and topic convention, then verify qos choice and message size/frequency, and finally test offline data should retain original acquisition time with the real equipment. Record pass criteria so the design can be repeated across sites.
Why Real-Workload Testing Is Necessary
Unlimited queues and retries can create a recovery burst that delays real-time messages. Public content and project documents should therefore state model, firmware, regional network, options and environmental conditions and avoid unverifiable claims such as 'works for every project' or 'absolute reliability'.
How Tespro Fits
Tespro TG-424 can organize edge data and publish through MQTT-related network protocols. Confirm TLS, QoS, persistent sessions and buffering by software version.
Decision and Verification Table
| Decision factor | What to verify |
| Topics should be stable and scalable | Confirm against broker and authentication and document pass/fail criteria in the pilot or site test. |
| Telemetry and commands should be separated | Confirm against topic convention and document pass/fail criteria in the pilot or site test. |
| Offline data should retain original acquisition time | Confirm against qos choice and document pass/fail criteria in the pilot or site test. |
Compatibility and Selection Checklist
- ✓ Broker and authentication
- ✓ Topic convention
- ✓ QoS choice
- ✓ Message size/frequency
- ✓ Offline window
- ✓ Command security
Frequently Asked Questions
Q: Should all industrial data use QoS 2?
A: No. QoS 2 has higher overhead and should match deduplication and reliability needs.
Q: Can offline replay create duplicate data?
A: Yes. The platform should deduplicate using device ID, timestamp and sequence.
Q: Can MQTT commands directly control equipment?
A: They need authentication, authorization, validation and local safety logic before any hazardous action.
