Set Task State
Set Task State applies a saved configuration profile to a selected task through the same update path that is used by the UI, then reloads or restarts the task when the changed fields require it.
Prepare controlled task configuration presets
Use this action when an Event Manager rule, schedule, manual button, or action group must switch an existing task between known-good configuration profiles. Typical examples are day/night detector sensitivity, alarm-mode recording quality, reduced-load processing, or a rollback preset for troubleshooting.
The action persists the new task configuration. Treat every preset as a production configuration change: prepare it through the task form, test it manually, and keep a rollback preset when the target task is important for capture, detection, or recording.
Select the target task
Choose Target task that should receive the preset. The configuration form is built for that selected task, so changing the target changes which task fields can be saved.
Save a known-good profile
Fill Task configuration from the normal task form instead of typing raw JSON by hand. This keeps field names, value types, and validation aligned with the UI.
Test restart impact
Some task fields can be reloaded while others require a stop/start cycle. Test each preset outside critical hours so operators know whether a short capture, detection, recording, or downstream processing gap is expected.
Configuration parameters
| Parameter | Required | Description | Default |
|---|---|---|---|
Title | Yes | Display name of the preset action. Use a name that describes the profile, for example night sensitivity, rain mode, low CPU profile, or restore production settings. | None |
Target task | Yes | Task whose configuration will be updated when the action runs. Pick the exact task instance, not only the task type. | None |
Task configuration | Yes | JSON-compatible form data for the selected task configuration. In normal use it should be produced by the task form UI and stored as a preset, not written manually. | None |
Apply presets through the task update path
When the action runs, Banalytics finds the selected task, reads the saved task form data, validates the resulting configuration, persists it, and initializes the updated task instance. This makes the change behave like a normal task configuration update from the UI.
If the changed fields require a restart, the target task is stopped and started asynchronously. If they do not require a restart, the new configuration is reloaded without a full stop/start cycle.
Persistent profile
The preset changes the stored task configuration, so the new values can remain active after the agent restarts.
UI-compatible data
The configuration payload should come from the same form model that the UI uses for the selected task.
Restart boundary
Fields that affect sources, codecs, native libraries, or hardware resources may cause a short task restart gap.
Switch task behavior for real operating modes
Sensitivity profiles
Create separate presets for day, night, rain, high sensitivity, or low sensitivity modes. Use them to update detector thresholds, zones, delays, or filtering options on the same target task.
Performance profiles
Change CPU/GPU-heavy task parameters when the system is under load: lower FPS, increase processing interval, disable expensive options, or restore full quality during important periods.
Recording profiles
Switch recorder settings for business hours, night mode, maintenance windows, or alarm mode. This is useful when a task normally records lightly but should become more detailed after an event.
Operator preset buttons
Expose several manually triggered actions that apply tested task configurations without asking operators to edit the full task form.
Scheduled configuration changes
Combine the action with schedule rules to apply different settings at predictable times, for example quieter sound detection at night or stricter motion filtering during rain-prone hours.
Event-driven adaptation
Use Event Manager conditions to change a downstream task after a status event, alarm, or external signal. Keep these changes coarse and stable instead of updating configuration on every frame or every small event.
Controlled rollback
Create one action for an experimental profile and another action that restores the previous production profile. This is safer than editing a live task manually during troubleshooting.
Operational notes
Use UI-generated form data
Task configuration is JSON-compatible form data for the selected task. In normal operation it should be produced by the task form UI rather than typed by hand.
Configuration, not lifecycle state
This action changes task configuration. It does not start, stop, or restart a task as its main purpose. Use Action on Task for START, STOP, and RESTART workflows.
Expect restart gaps for some fields
If changed fields require a restart, the target task is stopped and started again asynchronously. Expect a short gap in capture, detection, recording, or downstream processing.
Persistent update
The update is saved to the primary task configuration, not only to runtime memory. Use this action for intentional profile switching, not for per-event temporary variables.
Avoid noisy triggers
Avoid firing this action frequently from noisy detectors. Repeated configuration saves and task restarts can create downtime, disk churn, and unstable pipelines.
Avoid feedback loops
Do not create rules where a task changes its own thresholds on every event and immediately triggers another configuration change. Use cooldowns, schedules, or explicit Event Manager conditions.
Validate risky fields
Be careful with settings that control sources, file paths, credentials, codecs, native libraries, or hardware resources. Invalid values can move the target task into initialization or processing error state.
Plan a rollback preset
If validation fails, the previous configuration is restored in memory and the update is rejected. Still test every preset before production use and keep a rollback action for important tasks.