Automation

Run scripts when a device starts, its connectivity changes, or its service stops, and inspect the results in execution history.

Before you begin

Device automation runs scripts when a selected device enters a key execution stage. Use it to initialize system configuration, start or stop third-party components, refresh configuration after connectivity returns, or perform alerting and failover actions after a sustained outage.

Automation scripts run directly on your devices. You remain responsible for the software and system configuration they manage, including rollback.

• Only the account owner can manage automation.
• Automation runs only on Linux (including OpenWrt) and Windows devices; macOS, iOS and Android devices do not run automation scripts.
• Scripts run with the privileges of the wwnet background service, which normally has administrator or system access. Test on a non-critical device before applying a policy to production devices.
• Make scripts idempotent so they remain safe when the same event occurs again.
• Do not put passwords, access tokens, or other secrets in script content, arguments, or output.

Add a script

Open Configuration → Automation, select the device, and choose Add script in the required execution stage:

1. Choose an interpreter. OpenWrt uses sh, Windows uses PowerShell, and Linux supports sh or bash.
2. Enter the script and set its timeout, or select no timeout. The default is 60 seconds.
3. Choose whether to enable it and save. The script is appended to that device's stage queue. Cancel discards unsaved input.

After saving, confirm that the script is enabled under the intended device and stage. It runs when that stage next occurs; saving a script does not itself execute it. Review the execution record after the event.

Edit and reorder

Edit the interpreter, timeout, enabled state and content in the script block. Saving content creates a new revision; historical executions retain the revision that actually ran.

Drag a script block by its handle to reorder it within a stage; with the keyboard, press Space to pick up, arrow keys to move and Space to drop. Scripts run one at a time; a failed script does not prevent later scripts from running. Different devices run independently.

If the device enters a new execution stage, unfinished scripts from the previous stage are canceled. Do not design stages to depend on overlapping execution.

Choose an execution stage

After service starts

Runs after the wwnet background service completes a fresh start and receives the current network configuration. Joining a network while the service is already running does not run this startup script retroactively.

Use this stage to check dependencies, generate local configuration, or start third-party components managed by the operating system's service manager.

Network connected

Runs when the device first establishes a usable connection to any other device. It also runs when the device reconnects to any device after a complete disconnection has already been confirmed.

If connectivity returns within the 30-second disconnect grace period, it only cancels the pending disconnect event and does not run the connected script again.

Network disconnected for 30 seconds

Runs when a device that was previously connected to at least one other device has no usable connections for 30 continuous seconds. It does not run if a connection returns during that period.

The disconnected script does not run when:

• the service has never connected to another device since starting;
• at least one other device remains connected; or
• the service is intentionally stopped or restarted, updated or rolled back, leaves the network, is removed from the console, or is uninstalled.

Before service stops

Runs during a normal service stop or restart, update or rollback, network leave, removal from the console, and uninstall. It cannot run after power loss, an operating-system crash, or a forced process termination.

All stopping scripts share at most five seconds to finish before remaining processes are terminated. Use this stage for quick state persistence or for asking a system service manager to stop a component, not for long-running work.

Run a persistent component

An automation script should complete one operation and exit. If a third-party component must remain running, have the script install, start, or stop it through the operating system's service manager:

• Linux: systemd;
• OpenWrt: procd; or
• Windows: Windows Service Control Manager.

Do not use mechanisms such as setsid to detach child processes from an execution. WideWired could not then clean them up correctly when a timeout occurs, a policy is canceled, or the service exits.

Review execution results

Click All executions in the device's automation page header to see that device's runs, newest first, including records from deleted scripts. Filter by policy and status. Open a record for its status, script revision, trigger, start and finish times, exit code, stdout and stderr.

The execution action in a script block opens the list filtered to that policy. All policies returns to all runs for this device. Deleting a policy preserves its records within the retention period, marked Policy deleted. A notice appears when only the most recent records fit the row limit.

Output and history have the following limits:

• stdout and stderr each retain the first 256 lines, up to 4 MiB;
• each line retains up to 16 KiB;
• each policy retains up to 100 executions from the last 30 days; and
• enabled policies and their script content are limited to a combined 512 KiB per device. The console rejects a change that exceeds this limit.

Keep script output brief and actionable. Send large volumes of logs to the third-party component's own logging system.

Quick troubleshooting