Recover a lost Zigbee device

Recovering a lost Zigbee device means separating fresh radio contact from cached state, then using the right repair or removal flow without sending risky test commands. ALYT tracks actual contact separately from cached state, uses different offline timing for powered and sleeping devices, suppresses false child-device alerts during a hub or radio outage, and provides Reconnect and Delete in the device menu. For Zigbee, recovery is local to the home’s hub; do not reset the coordinator to remove one device, and do not use lock or unlock as a connectivity test. The Zigbee add-device flow opens the same acquisition picker from web Integrations → Zigbee → Add a device, phone Settings → Integrations → Zigbee → Add a device, and Home/Devices Add a device when Zigbee is the selected protocol. That picker shows the full brand and model catalogue in one view with server-wide search and pagination; there is no separate all-brands library, no browse-all link, no catalogue-opening link, no close-catalogue browser step, and no second short picker inside acquisition. The hub tile shows totals as metadata. Disabled cohorts keep the original picker. If selection is stale, offline, not authorized, or read-error, ALYT refuses effects and supports read retries.

How ALYT decides a Zigbee device is lost

ALYT starts new Zigbee monitoring in an unknown state, not online. A device becomes unavailable only from verified contact rules, not from replaying old cached state after a reboot. Hub reboot does not make stale devices healthy. The native route now shows an Add a device header and its content sits below the toolbar.

Availability timing

Device type	When ALYT marks it unavailable
Powered Zigbee device	After 600 seconds of silence and a failed probe
Unknown sleeping family	After 25 hours without verified contact
Aqara DJT11LM	After 11,700 seconds without verified contact

Notes:

• Actual radio contact is distinct from cached state, discovery, and interview metadata.
• Hub or radio outages suppress child-device alert storms.
• When hub transport is restored, ALYT grants a reporting window before marking devices unavailable again.
• Do not treat an old cached vibration state such as true as a fresh incident.

Before you start recovery

Use recent reports and model behavior as your guide.

• For battery devices, old timestamps are observations, not proof of the physical cause.
• A sleepy device may still be paired but not currently awake.
• Waiting for battery wake is a state, not success.
• Fresh actual evidence closes repair.

For locks, avoid unsafe tests:

• Do not issue lock or unlock as a connectivity test.
• Existing stale held-lock labels are treated as unproven, not as pending success.
• Lock command intent lifetime is 15 seconds.
• Pre-repair command IDs are fenced so earlier commands cannot be mistaken for repair success.

For model metadata, trust the actual model and family over misleading power metadata. For example, if a lock advertises mains power but belongs to a battery family, treat it as battery-operated behavior.

Reconnect a device

Use Reconnect from the device menu in web or mobile. TV supports status and navigation only; it does not offer repair or delete controls. On the acquisition flow, the user first chooses the allowed type on a model, reads that selected model guidance, and then starts pairing; selecting or reading a model does not open a radio.

What Reconnect does

Reconnect is durable and idempotent. ALYT:

• cancels any older repair intent
• quarantines old writes
• preserves stable identity
• preserves IEEE, endpoint, room, routine, and security membership
• targets a new interview and model-specific configuration
• opens a bounded join window only when needed

A reconnect does not succeed because the user pressed a button or because ALYT is waiting. It completes only when the device produces fresh actual evidence.

Recovery sequence

1. Open the device menu and choose Reconnect.
2. Follow the wake or pairing instructions shown for that model.
3. Wait for fresh contact or interview evidence.
4. Confirm recovery only after new device evidence arrives.

If the device is still sleeping, waiting for wake is part of recovery, not proof that the repair worked.

Model-specific wake and rejoin guidance

Kwikset SmartCode 910 Zigbee

During the controller pairing window, use four presses of interior button A.

Also:

• confirm the lock’s interior matches the manufacturer guide first
• keep the door open
• retain existing PINs
• do not substitute the Program-button factory reset

Aqara DJT11LM

Use a roughly 5-second pairing press if rejoin is needed.

Before instructing a full rejoin, first attempt a brief sensor wake and observe whether actual traffic appears.

Buttons or pairing only help when a matching repair has been explicitly started for that device identity. The catalogue keeps the existing version 26.107.0, the declared-capability and physical-qualification distinctions, and Green Power readiness unchanged.

Notifications during an outage

ALYT creates one issue notification per outage and another on silent recovery, scoped to the exact tenant, home, and endpoint or device target.

When a user taps the notification, ALYT validates current account and home membership before showing details. Notifications never execute device commands, and navigation does not rely on display name alone.

Delete instead of reconnect

If the device is gone for good, use Delete.

Before deletion, ALYT previews affected references, including parent routines calling a child routine that would become empty. If the preview changes, a new review is required.

What deletion does

Delete:

• cancels queued intent
• serializes against commands and configuration
• sends a targeted leave with rejoin=false and removeChildren=false
• removes live references from endpoints, routines, security, camera, notification, dashboard, widget, cache, and the hub table
• disables routines that lose triggers or conditions
• removes empty routines after review
• retains historical security audit records

A sleeping device may require physical reset. Do not assume a queued leave means confirmed removal.

If the leave is unconfirmed, ALYT requires an explicit second local-removal confirmation.

After deletion, a minimal tombstone prevents late reports or rejoins from recreating the device until an explicit new Add Device window admits a fresh acquisition.

API and permission notes

The recovery UI is user-scoped, and cross-home authorization is enforced. Household permissions are narrower than staff.

For Zigbee association progress and interviews, ALYT uses internal routes such as:

• POST /integrations/zigbee/joins
• POST /integrations/zigbee/interviews

For hosted homes, Zigbee pairing and interviews route through the home’s hub, not a server-side coordinator.

Developer credentials matter only when relevant:

• DEV credentials act in the developer sandbox.
• LIVE credentials only for their own installed connector.

These key-access boundaries do not broaden household repair permissions.

What not to do

Avoid these common mistakes:

• Do not treat cached state as proof of current contact.
• Do not use lock or unlock to test connectivity.
• Do not shorten passive-device deadlines without model evidence.
• Never reset the coordinator to remove one device.
• Do not assume a battery device is repaired because it has been told to wake.
• Do not navigate by display name alone when handling recovery from a notification.

Recovery checklist

Use this checklist when a Zigbee device appears lost:

1. Confirm whether the device is powered or sleepy.
2. Compare the last verified contact against the correct timeout.
3. If there was a hub or radio outage, allow the recovery reporting window.
4. Start Reconnect.
5. Follow model-specific wake or pairing instructions.
6. Wait for fresh contact or interview evidence.
7. If the device is intentionally gone, review impact and use Delete instead.

Successful recovery depends on new evidence from the device, not on cached state or command acknowledgements alone.