Firmware update procedure

A firmware update changes the behaviour the rest of this documentation set describes. Which is why every procedure in this set carries a revision, and why the first step of any update is a revision check rather than a transfer. This document describes the sequence, the preconditions and the rollback position; it does not name a version number, because version numbers are published with the release they belong to, not scattered through prose.

Preconditions

• A power source that will not be interrupted for the duration of the update exists for the device being updated.
• A configuration backup has been taken, so a rollback has something to restore to.
• The revision of the firmware currently on the device is recorded, and the target revision has been checked to apply to this SKU and this hardware revision.

Sequence

1. Confirm applicability

Check the target firmware's applicability against the device's model and hardware revision on the model page. Applying a revision written for a different hardware revision is the failure this check exists to prevent; if it is unclear, stop and ask rather than proceeding.

2. Record the current revision and take a backup

Record the revision currently installed and export the device's configuration. This record is what makes a rollback possible and what a support request must contain.

3. Schedule the update window

Update during a window in which the affected circuits can be off or in a known state. A gateway update briefly interrupts local rule execution; a device update takes that device out of service while it restarts.

4. Apply the update

Apply per the distribution channel you are using. An update may be pushed from the gateway to its endpoints or applied locally; keep to one channel per window so that a partial outcome is not ambiguous.

5. Verify the revision after restart

After the device restarts, read back its revision and confirm it matches the target. A transfer that completes without a post-restart revision check is not a verified update.

6. Verify behaviour, including the local path

Run one schedule or scene with the uplink absent and confirm it still executes. An update that changes local behaviour is discoverable only here. See Failover and local policy.

Failure modes

• Update applied but revision unchanged: the image did not commit; the update did not take effect, and the device must not be treated as updated.
• Behaviour changed after update: the new revision's rules apply; compare the document revision this set published against the installed revision, which is the same comparison the ?firmware= warning makes.
• Device unreachable after update: the device is restarting or the update failed; restore the configuration backup and contact support with the recorded revision.
• A device dropped from the registry after update: re-register it against the identity it had, rather than pairing it as new.

Limitations

• No firmware version number appears on this page. Version identifiers change with each release and are published in Release notes and on the model pages, with the document revision they were tested against.
• The document you are reading applies to the SKUs listed in its applicability badge; a device outside that list must be checked against its own model page before any update.

What this document does not cover: the checks that isolate a fault after an update are in Diagnosis checklist, and the access rules that decide who may perform the update are in Hardening and access.