Remote diagnostics for a connected hardware product

The scenario

Consider an installed connected device that occasionally loses its cloud connection. A support team needs to distinguish poor connectivity, old firmware, and a failing peripheral without asking a customer to perform an undocumented reset sequence. The proposed diagnostic flow would collect a small, explainable health snapshot and preserve a clear boundary between observation and changing the device.

Define a diagnostic contract alongside firmware

The device would expose a versioned set of health counters: boot reason, uptime, firmware and board revisions, queue usage, and selected connectivity errors. Each field would have units and interpretation notes. A missing or reset counter would be distinguishable from a healthy zero.

Zephyr and MCUmgr could provide selected management primitives on supported devices. The product would enable only the operations it actually needs and protect the chosen transport. Availability of a management protocol would not justify exposing a general remote shell in a customer product.

Let the customer see what the session collects

The mobile app would explain the diagnostic steps and request the appropriate device access. A session would collect the declared fields, run bounded connectivity checks, and show the resulting status. Read-only checks would be separate from an action such as restarting a component or changing network configuration.

An authenticated backend would verify account ownership before accepting a support bundle or allowing a support operator to retrieve it. If a remote path is unavailable, a local Bluetooth or wired service path could be evaluated for that hardware. A disconnected device would not be labelled healthy just because a previous cloud snapshot exists.

Make the bundle useful without making it exhaustive

A bundle would contain a diagnostic reference, schema version, device revisions, timestamps with clock-quality notes, and bounded health history. Wi-Fi passwords, access tokens, raw customer content, and unnecessary identifiers would be excluded. Retention and deletion would be defined before enabling uploads.

Support tools would link the bundle to the relevant troubleshooting guide and record who accessed it. The first iteration could remain a manual review flow. Tests would cover old firmware, partially collected sessions, customer cancellation, and a support operator without permission to view that device.

What to validate

• Health fields remain interpretable across supported firmware versions.
• A diagnostic session cannot silently become a configuration-changing operation.
• Bundles exclude credentials and have an enforced retention policy.
• Offline, interrupted, and unauthorized sessions have distinct outcomes.

The tradeoff

Remote diagnostics can make a failure easier to understand, but collection itself consumes device resources and creates a data lifecycle. Begin with a few actionable counters and add detail only when it answers a recurring support question.