Device automation

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

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. Configuring automation does not disable or replace WideWired Forwarding.

Before you begin

• Only the account owner can manage automation.
• 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.

Create a script

Open Configuration → Automation, then select New script in the Scripts section:

1. Enter a name and describe what the script does.
2. Select the platform and interpreter. OpenWrt uses sh, Windows uses PowerShell, and Linux and macOS support sh or bash.
3. Enter the script and choose its default timeout. The default is 60 seconds; you can select another duration or no timeout.
4. Save the script.

Editing script content creates a new revision. Future policy runs use the new revision, while existing execution records remain associated with the version that actually ran.

Create a policy

After saving a script, select New policy in the Policies section:

1. Select the device that will run the script.
2. Select the execution stage and script. The list only includes scripts compatible with the device platform.
3. Optionally enter arguments, one per line. The script receives them in the displayed order.
4. Choose whether to inherit the script timeout, override it, or use no timeout.
5. Save and enable the policy.

When one device has multiple policies for the same stage, use Up and Down to set their order. Policies run one at a time in the displayed order. A failed policy does not prevent later policies from running. Different devices run independently and do not wait for one another.

If the device enters a new execution stage, unfinished scripts from the previous stage are canceled. Do not design two 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;
• macOS: launchd; 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 Executions in the automation page header to see every run in this network, newest first, including runs of policies that have since been deleted. Filter the list by policy and by status. Open any row for its details: status, script revision, trigger, start and finish times, exit code, and separately captured stdout and stderr.

Executions › at the end of a policy row opens the same list already narrowed to that policy; the policy filter shows the current scope, and choosing All policies widens it again. Deleting a policy does not delete its executions — they stay reachable from the page header, marked Policy deleted. When the list reaches the server's row limit, a notice says only the most recent runs are shown.

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