Overview
The Xyte platform delivers Firmware files to Devices securely. The recommended pattern is to define a Custom Command on the Device Model that requires a File parameter with filetype set to firmware (or a similar tag).
The manufacturer then uploads Firmware files under the same Device Model, making them selectable when scheduling the upgrade Command for any End Customer.
Upgrade flow
- The End Customer schedules the firmware upgrade Command and selects one of the manufacturer's uploaded Firmware files (or uploads a custom file).
- On the next Send Telemetry API call, the response sets the Command pending flag to
true. - The Device calls Get Command API to retrieve the Command details, including the link to the Firmware file.
- The Device calls Update Command API with status
in_progress. - The Device downloads the file and performs the firmware upgrade locally.
- The Device calls Update Device API to report the new firmware version.
- The Device calls Update Command API with the final status.
Firmware upgrades often reboot the Device. Persist the fact that an upgrade is in progress before rebooting, so the Device can finalize the reporting (Command completion, new firmware version, and any other side effects) once it comes back online.
Upgrade side effects
A firmware upgrade can change how data is stored or reported on the Device. Two cases need explicit handling.
Configuration shape changes
If the upgrade changes the shape of the Configuration object, the upgrade routine must translate the previous Configuration to the new shape and call Set Config API to push the migrated value to the server.
Telemetry keys change
If the upgrade adds or removes Telemetry keys (especially when keys are retired), send a full Send Telemetry API call with the override flag set to true. This clears the deprecated keys from the Device's state on the server.