Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.cyberwave.com/llms.txt

Use this file to discover all available pages before exploring further.

​
What are Workflows?

Workflows in Cyberwave let you create automated sequences of robot operations. Connect nodes visually to build complex behaviors without writing procedural code. Workflows can run on the cloud (Celery tasks) or on the edge device depending on the trigger type. Cloud triggers handle schedule, webhook, event, and manual execution. The camera_frame trigger runs ML inference directly on the edge — no video leaves the device.

​
Workflow Components

​
Nodes

Nodes are the building blocks of workflows. Each node performs a specific action:

Trigger Nodes

Start the workflow: manual, schedule, webhook, event, MQTT, email, or camera_frame (edge)

Call Model Nodes

Run ML inference — cloud VLM/LLM or edge-local object detection

Twin Nodes

Control digital twin position, rotation, and state

Joint Nodes

Set individual joint positions or run trajectories

Condition Nodes

Branch based on sensor data, twin state, or model results

Delay Nodes

Add timing between operations

​
Connections

Connections define the execution flow between nodes:
  • Sequential: Execute nodes one after another
  • Parallel: Execute multiple nodes simultaneously
  • Conditional: Branch based on conditions
Connection validation prevents invalid graphs: trigger nodes cannot accept incoming connections, cycles are blocked, and camera_frame triggers can only connect to call_model nodes.

​
Trigger Types

TriggerWhere it runsHow it fires
ManualCloud (Celery)User clicks “Run” in the UI or triggers via SDK/API
ScheduleCloud (Celery)Cron or interval timer
WebhookCloud (Celery)HTTP POST to a webhook URL
EventCloud (Celery)Business event matching conditions
MQTTCloud (Celery)MQTT message on a topic
EmailCloud (Celery)Incoming email
Camera FrameEdge deviceEvery camera frame, locally — never sends video to the cloud

​
Creating a Workflow

1

Open Workflows

Navigate to Workflows in the dashboard.
2

Create

Click Create Workflow. Give it a name, optional slug (unique within the workspace), and visibility.
3

Build

Drag nodes from the palette to the canvas. Connect nodes by dragging from output to input ports.
4

Configure

Configure each node’s parameters (twin UUID, model, confidence threshold, emit_event settings, etc.).
5

Activate

Click Activate. For edge workflows, sync to the device with the CLI or wait for the next automatic sync.

​
Edge Workflows (Camera Frame)

The camera_frame trigger is designed for on-device ML inference. The backend generates a Python worker file that runs directly on the edge — raw video frames never leave the device.

​
How it works

​
emit_event configuration

The call_model node’s emit_event parameter controls when detection events are published back to the cloud. All settings are baked into the generated worker at codegen time.
FieldTypeDefaultDescription
enabledbooltrueSet to false to run inference without publishing events
event_typestring"detection"Business event type published to the cloud
severitystring"INFO"Event severity (INFO, WARNING, CRITICAL)
emit_modestring"always"Controls when events fire (see below)
cooldown_secondsfloat5.0Minimum seconds between consecutive events
emit_mode values:
  • always — publishes for every detection, subject to cooldown. Skips frames with no results.
  • on_enter — publishes only when new object classes appear that were not in the previous frame. Useful for “person entered the zone” alerts.
  • on_change — publishes only when the detection count changes. Useful for occupancy tracking.

​
Syncing to the edge

After activating a workflow in the UI, push it to edge devices: 
# Interactive: picks the workflow, discovers target twins, sends sync via MQTT
cyberwave workflow sync

# Explicit
cyberwave workflow sync <workflow-uuid>

# Or sync a specific twin directly
cyberwave edge sync-workflows --twin-uuid <twin-uuid>
The CLI sends a sync_workflows command via MQTT. Edge core receives it and immediately pulls the latest worker files from the backend — no need to wait for the periodic cycle. The edge device also syncs automatically on boot and periodically (default ~5 min, configurable via CYBERWAVE_WORKER_SYNC_INTERVAL_LOOPS).

​
Execution Modes

Workflows can be triggered by:
TriggerDescription
ManualRun on demand from the dashboard or SDK
ScheduleRun at specific times (cron)
EventsRun when sensor data matches conditions
APITrigger from external systems via REST or MCP
Camera FrameRun on every camera frame at the edge device

​
Monitoring Executions

Track workflow execution status and results: 
runs = cw.workflow_runs.list(workflow_uuid="workflow-uuid")

for run in runs:
    print(f"Status: {run.status}, Started: {run.started_at}")
Each execution tracks status at both the workflow level and individual node level, including started_at, finished_at, and error_message fields.

​
Check if a Workflow is Running

Use is_running() to quickly check if a workflow has any active execution without manually querying runs: 
wf = cw.workflows.get("workflow-uuid")
if wf.is_running():
    print("Workflow is currently executing")
This returns True when any run has status running, waiting, or requested. In the dashboard, a Running indicator appears next to the Active badge in the workflow editor header whenever the workflow has an active execution. It refreshes automatically every 2 seconds.

​
Example: Edge Detection Workflow

A camera_frame workflow that runs YOLO on the edge and emits alerts:

​
Best Practices

  • Keep workflows focused — create separate workflows for distinct operations rather than one large workflow. This makes debugging and maintenance easier.
  • Add error handling — include condition nodes to handle failure cases gracefully. Consider what should happen if a joint can’t reach its target.
  • Use meaningful names — name nodes and workflows descriptively. “Alert on person in zone A” is better than “Node 1”.
  • Use on_enter emit mode for alerts — avoids flooding with repeated events while the same object stays in frame.
  • Set appropriate cooldowns — balance between responsiveness and event volume. 5s is a safe default; lower for time-critical use cases.
  • Eject before customising — never edit wf_*.py files directly. Copy them to a custom name and deactivate the originating workflow.