Managing a Device

Everything the engine does to a camera, a human first asks for on the device page. It's where an operator provisions a new camera, loads its credentials, starts it capturing, watches the images arrive, and diagnoses it when something's off. Understanding this page is understanding how the whole control plane is actually driven, because every button on it is a write to Cosmos that the engine's change feed turns into real work.

The one idea to hold on to

The Device Details page is a single pane of composed cards, and its actions don't command the engine directly — they write the camera's Cosmos config, which the change feed reconciles into orchestration redeploys, while SignalR streams the results back live. The page is the human front-end to the indirect control plane.

You reach it from the Devices list (searchable across the fleet) and land on a details page assembled from cards, each backed by a slice of the API:

Card	Shows / does	Backed by
Device Header	identity, environment, live status	monitoring mirror
Device Configuration	Bootstrap, Encrypt Fields (load credentials)	DeviceConfig
Settings · Connectivity	per-device flags, addresses, auth type	DeviceConfig, FrontEndCameras
Orchestration Management	start / stop / redeploy the camera	ImageAcquisition
Image Acquisition Streams	configure Single / Pano / Lease / Turbo rates & status	ImageAcquisition
Device Health · Latest Standard/Pano Image	health, freshest frames	monitoring mirror + SignalR
Documents	the raw Cosmos device documents	FrontEndCameras

The bootstrap-to-capture workflow

Provisioning a brand-new camera is a fixed sequence on this page — and each step maps to the concepts from earlier sections:

1. Bootstrap (Device Configuration card). Runs the shared BootstrapService: creates the CameraState durable entity and seeds the four acquisition stream configs (Single/Pano/Leased/Turbo).
2. Encrypt Fields / Load Credentials. Retrieves the camera's addresses and latest credentials, encrypts the sensitive fields, and stores them — required before any orchestration can reach the camera (it's the write side of the VAPIX credential decrypt).
3. Configure Single & Pano (Image Acquisition Streams). Set the rate (default 10s single, 120s pano), set Status = Starting, ensure Is Active — and save. Saving this is what starts the camera.

Then verify on the same page: Device Health goes green, the Single stream shows Running, and the Latest Standard/Pano Image cards begin filling in — the first run captures a panorama, then drops into single-image mode.

Start and stop are a status field

The Orchestration Management card's start/stop isn't a special command — under the hood (useDeviceOperations) it calls setStandardImageAcquisitionConfig with the stream Status set to Starting or Stopped. That write lands on the Cosmos doc, the change feed fires, and UpdateStreamOrchestrations reads the status to start (terminate + re-init + schedule new) or stop (terminate + purge) the camera's one orchestration. The device page is the human trigger for the propagation path the engine lesson diagrammed.

Gotcha: Is Active is the master switch, and changes apply on redeploy

Two things from the engine surface here. First, if a device's IsAlertCaActive is off (or it's tagged for another environment), the change-feed deploy gate skips it — the page will save your config, but nothing deploys. Second, a save returns success once the Cosmos write lands; the orchestration redeploys moments later, asynchronously. "Saved" means intent recorded, not "camera already reconfigured" — watch the stream status flip to Running to confirm.

Live updates and per-device logs

The details page subscribes to SignalR for the camera's group (image, pano, and activity-log broadcasts), so captured frames and movements appear in real time — the same broadcasts the engine emits each loop. And a device isn't just its live state; the page links to a set of per-device history screens, each a chronological record:

• Audit Log — every admin action taken on this device (see Auditing).
• AI Detection Log — Condor detections for this camera.
• Movement Log — the PTZ movement history, with reason codes.
• Timelapse · Monitoring — captured-image timelapse and the device's monitoring detail.

Wrapping up

The device page is the operator's control room for one camera: a details page of composed cards that provision it (bootstrap → encrypt → configure), start and stop it by writing stream status (which the change feed reconciles into orchestration redeploys), show its health and freshest frames live over SignalR, and link to its full audit, detection, and movement history. Every action is an indirect Cosmos write, applied on redeploy — never a direct command to a running orchestration.

Managing a device assumes you're allowed to — and that the cameras you see are the ones you're permitted to. Who can see and operate what is next: Access Control.