Prepare one working source and one receiver
- A valid local tag from the first-data guide, with its unit and sampling behaviour recorded.
- A broker address reachable from the gateway, port, authentication and TLS requirements supplied by the broker owner.
- A permitted publishing topic, a separate subscribing client and distinct client IDs.
- A proposed reporting interval and a record of which fields the receiving application needs.
The official quick start offers an optional local Mosquitto/MQTTX test. Its unencrypted, unauthenticated simulation settings are not production defaults.
Agree what a message means
Write down the device identity, measurement name, unit, expected reporting interval and destination topic. Decide how the receiver will distinguish a new sample from an older or invalid one. Inspect the format supported by your installed release; do not promise timestamp or quality fields until you have checked the actual payload.
Connect the verified tag to reporting
Follow the matching E2C Factory guide to add the tag to a Tag Group and select its reporting strategy. In Data to Cloud, configure a Standard MQTT service and its Publish message using that group and the agreed topic.
Use the broker connection and security settings supplied for your test. When a broker runs on another computer, the gateway needs that computer’s reachable address; localhost would refer to the gateway itself.
Observe the independent receiver
Connect the subscriber to the same broker with its own client ID and subscribe to the exact publishing topic. Wait through the configured reporting interval and save an example message. Compare the received measurement with the local tag, including any scaling and unit conversion applied by the receiving application.
Demonstrate freshness and recovery
Observe a safe change in the measured condition, or use an explicitly labelled simulator, and check that the receiving value follows it. Record the local observation time and receiver arrival time; clock differences and reporting intervals affect the comparison.
With the test owner’s agreement, briefly interrupt the test destination and restore it. Record whether new data resumes and whether older messages appear. Evaluate any configured buffering from the actual result and release documentation; do not assume complete historical delivery.
Check completion and choose the next step
- The expected subscriber receives the expected topic from the intended source.
- The payload can be interpreted with the agreed identity, unit and freshness rules.
- A new observation reaches the receiver and recovery behaviour is recorded.
- The broker owner, credentials owner and continuing service responsibility are known.
Keep one sanitised payload and the configuration reference with your project worksheets. Use the OEM pilot plan to define a repeatable integration, or business purchasing to discuss project scope.