Overview

The device side firmware implementation is platform and flow specific. Bellow details of a suggested architecture implementation for an Xyte enabled device.

The flow contains five main parts:

Initialization
Registration loop
Pre-run initializations
Telemetry loop
Handling code (commands / config / etc)

Initialization

When the agent first starts it should check if "Auth data" is present (should be persisted to local storage).

If no "Auth data" is present, the device should move to the "Registration loop" until registration is successful.

A check should be made if there is a pending command that might caused the device to reset (e.g. reboot, firmware update, etc). If so, the device should get and process the command, and update the service once the command finished.

The devices moves to the "Telemetry loop" stage.

Registration loop

When the device comes online and gains network access, it should immediately start trying to register with the server. It is suggested to wait 10-30 minutes between registration attempts, but to continue trying until successful.

Pre-run stage

After the device successfully boots from a reboot (or other similar event), and the device was previously registered. It is recommended to reset the server states to match the new "clean" device state.

In this phase it is recommended to do the following:

Check if the device was performing a command (e.g. reboot) and update the server via Update Command and Update Device in case of a successful firmware upgrade.
Send a Telemetry with the current device's state with the override flag set to true
Pull latest configuration from the server Configuration - Initial device registration
Clear any incidents opened directly by the device with Open Incident by using Close Incidents
Use Add Event to add "device booted" event describing what happened to the device.
Any other pertinent updates to the server.

Telemetry loop

Every 5-30 seconds or when a significant event happens (e.g. some operation finished), the device should update the server on its current status using the Send Telemetry mechanism.

A suggested implementation is for the device to collect data from the system and use Send Telemetryto update the server.

Depending on the response three flows might happen:

401 Authorization error - The device was deleted, it should clear "Auth data" and move to the "Registration loop".
200 Success - No pending commands/etc, continue the flow.
200 Success - Pending commands / licenses / etc move to "Handling code".

Handling code

When the Send Telemetry response contains notifications on pending commands, configuration updates, licenses, etc. The device should parse the data and make the appropriate calls to the server to get the updates, apply them and continue with the "Telemetry loop".

Sample sequence

Example of full flow: register, send telemetry and handle a pending command.