Flow diagram

Overview

The Device-side firmware is platform-specific, but the overall control flow is the same on every Xyte-enabled Device. The recommended architecture has five stages:

  1. Initialization.
  2. Registration loop.
  3. Pre-run stage.
  4. Telemetry loop.
  5. Handling code (Commands, Configuration, etc.).

Initialization

On startup, the agent checks for persisted Auth data (the credentials returned by Register Device API).

  • If Auth data is missing, the Device enters the Registration loop and stays there until registration succeeds.
  • If a pending Command may have caused the previous reset (e.g. a reboot or firmware-update Command), the Device fetches and finalizes that Command before moving on.

After initialization, the Device moves to the Telemetry loop.

Registration loop

When the Device comes online and has network access, it attempts to register immediately. If registration fails, retry on a 10–30 minute interval until it succeeds.

Pre-run stage

After a reboot or similar reset, a previously registered Device should resync the server with its current clean state:

  1. If the Device was executing a Command (e.g. reboot), report the outcome via Update Command, and — for a successful firmware upgrade — also call Update Device.
  2. Send a Telemetry message with the Device's current state and the override flag set to true.
  3. Pull the latest Configuration from the server (see Configuration — Initial registration sync).
  4. Close any Incidents the Device itself opened previously, using Close Incidents.
  5. Emit a device booted Event via Add Event to record what happened.
  6. Send any other state the server should know about.

Telemetry loop

Every 5–30 seconds, or whenever a significant event occurs (e.g. a long-running operation finishes), the Device sends a Send Telemetry call.

The response drives the next action:

  1. HTTP 401 — the Device was deleted on the server. Clear the persisted Auth data and return to the Registration loop.
  2. HTTP 200 — no pending work — continue the loop.
  3. HTTP 200 — pending work (Commands, Licenses, Configuration changes) — branch into Handling code.

Handling code

When the Telemetry response signals pending work, the Device fetches each item via the appropriate API (Get Command, Get License, Get Config, etc.), applies the change locally, confirms via the matching update API, then resumes the Telemetry loop.

Sample sequence

End-to-end flow: register, send Telemetry, handle a pending Command.