Fleet Operations

An operation is a plan that Nexigon Hub carries out across selected devices over time. Use operations when a change needs per-device progress tracking or a staged rollout, such as deploying software to canary devices before the rest of a fleet.

For a single action on one device, a device command may be sufficient. To create a staged workflow, follow Run a Fleet Operation.

Targets and Enrollment

Each operation belongs to a project. Its selector describes which devices to target using device IDs, groups, search, status, and property predicates. All supplied conditions must hold.

A snapshot operation resolves its selector once at startup. A dynamic operation has an enrollment interval and adds newly matching devices while it runs. Enrollment adds work; a device that stops matching keeps its assigned work.

Dynamic operations can either close when current work finishes or remain running to enroll future matches. The API’s closeWhenConverged setting controls this. The web interface keeps dynamic operations open for later matches.

Stages and Guards

Stages divide a rollout into progressively larger rings, such as 1, 10, and 100 percent of matching devices. Assignment is deterministic for an operation and device. Each device belongs to the first stage that includes it and runs the step sequence once.

All enrolled devices appear in the target table. Targets in a stage that has not been activated remain pending. Advancing activates the next stage; earlier activated stages can continue at the same time.

A guard controls advancement from the highest activated stage, called the frontier stage. It can require a minimum success percentage, limit failures, check reported properties, or wait for a scheduled time. A stage can advance automatically when its guard passes, or wait for an operator to advance it.

Steps and Device Responsibilities

Every target runs the same ordered steps. Nexigon Hub can set, update, or remove a property and wait for a property predicate to match. These steps do not require operation polling on the device.

A command step asks Nexigon Agent to execute a command published by the device. Both command execution and operation polling must be enabled. The agent reports the command result before requesting more work.

A reliable rollout separates desired state from observed state. For example, a system update operation can set dev.nexigon.ota.config, then wait for dev.nexigon.ota.status to report the expected installed version. This confirms that the device applied the change rather than only receiving it.

Pause, Completion, and Failure

Pausing stops enrollment and new work without undoing completed steps. A device can still report a result for work it already received. Resuming continues the operation; cancelling stops it permanently.

Once the final stage is activated and all targets reach a terminal state, an operation that closes on convergence finishes. Terminal states include success, failure, timeout, and cancellation. Failures can block stage advancement through guards and affect the operation’s final status.

See the Operations reference for status values, selector errors, timing rules, and API fields.