Robot MQTT Wills: Interpret Connection-Loss Evidence
Interpret MQTT 5.0 Will messages as connection-related evidence, retaining delay and session settings separately from robot application and device health. This guide concerns robot integration and delivery review. The proposed observations are editorial assessment guidance, grounded in the linked original documentation and subject to the deployed version. They do not describe an on-site test of a particular machine or establish whole-system acceptance from a single interface response.
Define the event represented by the Will
Document Will topic, payload meaning, connection identity and configuration revision. A server publishes a Will under protocol conditions rather than directly measuring motors, sensors or business processes. An offline indication cannot automatically establish that every physical function stopped, and absence of a Will cannot establish complete device or application health.
For this review, identify the delivered device, software and configuration revisions first. Record unsupported, disabled and untested capabilities separately. Evidence from another model is useful context, but cannot establish what the delivered combination actually provides. Keep the original input beside the settings used to interpret it.
Review connection and delay conditions
Retain Will Flag, actual payload, delay and relevant session settings for the protocol version and client implementation. A disconnect screenshot alone does not establish publication timing. Exceptional connection loss, orderly disconnect and session conditions can follow different paths. Keep endpoint records rather than assuming every disconnect must produce the same Will outcome.
Retain the original input and the reason for the decision, rather than a successful screenshot alone. Change only the variables agreed for the comparison, and keep the before-and-after configuration. List conditions that were not exercised explicitly; they should not silently become part of the accepted operating range.
Separate orderly exit from exceptional observations
Record orderly disconnect, exceptional connection interruption and application failure separately. A stalled application with an existing connection differs from server-observed connection loss. The matrix helps identify additional health evidence. Protocol liveness mechanisms should not be presented as though they continuously function-test every business module, peripheral or physical capability in the robot installation.
Use the three illustrated observations as starting questions, rather than as diagnoses of an installation that has not been inspected. Check record completeness, units and identity before selecting the next observation. An unresolved result is more informative than a confident explanation assembled from missing fields or unrelated test runs.
Review Will and later-state ordering
After reconnect, new state publications need association with device identity, connection phase and message provenance. Avoid letting the last-arriving text replace all health information, especially when retained and live publications coexist. Isolated review should keep original samples and adoption order, explaining whether an older observation can still influence the current display.
Let the site owner choose an approved isolated way to exercise relevant exceptions. Record normal operation, the exceptional condition and recovery separately. The purpose is to establish how the application recognises and explains untrustworthy input, without requiring production equipment to act on deliberately invalid results.
Deliver layered health evidence
Deliver Will meaning, effective settings, connection records and independent application-health evidence, identifying unobserved functions. Revisit the design after session, delay or state-topic changes. A maintainer should understand the boundary between communication observations and machine capability rather than treating one green online icon as a substitute for actual task and device-state evidence.
Deliver the configuration, representative samples, result table and unresolved questions together. Agree who reviews subsequent changes. The receiving team should be able to select one conclusion and trace it back to its input and decision path without relying on the original author to reconstruct the missing steps.
Original documentation and further reading
Continue with related articles in this section, or use selection guides to prepare the next review. Apply the device-specific documentation and agreed operating conditions when implementing a test.