Workflows - Gude Expert Power Control
Switch a rack outlet on or off from a workflow, or power cycle it to reboot whatever is plugged in. For workflow builders. Setting the integration up is covered in Gude setup.
What you get
Two actions and one trigger:
- Set Outlet Power — switch outlets on, off, or toggle them.
- Power Cycle Outlet — switch outlets off, wait, and switch them back on.
- Outlet Power Changed — starts a workflow when an outlet changes state.
How outlets appear
Every outlet is its own device, so you pick outlets with the normal device picker, and the Find Devices node can gather them for you. That means one action can drive a whole rack: point Find Devices at a space, filter by the Gude integration, and feed the result straight into Set Outlet Power.
A device list can safely mix integrations. Anything in the list that isn't a Gude outlet — a light, or the power distribution unit itself — is skipped rather than failing the action, so the same list can fan out to several actions at once.
Set Outlet Power
| Field | What it does |
|---|---|
| Outlets | The outlets to control. Usually templated from Find Devices. |
| On | Required. Switch the outlets on (true) or off (false). |
| Stagger | Optional. Spreads the commands out — see below. |
An action whose On resolves to nothing fails rather than picking a direction: switching a rack off because a template came back empty is not a default worth having.
There is deliberately no "flip it" option. Flipping whatever state an outlet is currently in gives a different result on every run, so a workflow that fires twice leaves the rack the wrong way round. Say which state you want; to restart something, use Power Cycle Outlet.
Power Cycle Outlet
| Field | What it does |
|---|---|
| Outlets | The outlets to power cycle. |
| Off for (seconds) | How long each outlet stays off. 1–300, default 10. |
| Stagger | Optional. Spreads the commands out — see below. |
The unit's own firmware times the off period, so the workflow does not wait for it. The action finishes as soon as the unit has accepted the command — usually well under a second — and the outlet comes back on by itself.
Spreading a big rollout out
Switching a whole building at once is rarely what you want: a lot of screens powering up together is an inrush spike, and a lot of devices booting together is a burst of network traffic. Both actions take an optional Stagger:
| Field | What it does |
|---|---|
| Between commands | Minimum time between one command and the next, for example 2s. Leave blank to send as fast as the units accept them. |
| At a time | How many outlets may be waiting for a reply at once. Default 8. |
Between commands is the setting that matters: because the power unit times the off period itself, spacing the commands spaces the power-on events. A staggered rollout takes real time, so the action checks up front whether it can finish and sends nothing if it can't. Walkthrough: Restart every room overnight.
Reading the result
Both actions return the outlets sorted into buckets, because sending a command and the relay actually moving are two different things:
| Bucket | Meaning |
|---|---|
| Sent | The command was published. Not yet a guarantee the outlet moved. |
| Confirmed | The unit answered that it carried the command out. This is the one to trust. |
| Unconfirmed | The unit said nothing in time. Treat as unknown, not failed. |
| Rejected | The unit answered and refused, for example an outlet number it doesn't have. |
| Skipped | Not a Gude outlet, so deliberately ignored. |
| Failed | Couldn't be reached at all. |
| Not attempted | The action ran out of time before reaching these. Nothing was sent. |
Unconfirmed is the one worth branching on. The usual cause is Permit CLI commands being switched off on the unit; the other is the unit being offline. The outlet may well have switched either way, which is why it isn't reported as failed.
Not attempted only appears on a staggered rollout that ran out of time. Those outlets were never sent anything, so a partly-completed rollout is always visible rather than guesswork.
Outlet Power Changed
Fires whenever an outlet changes state, whatever caused it — a workflow, the unit's own web interface, a watchdog, or someone pressing a button on the front of the unit.
The trigger tells you which outlet changed, whether it is now on, and the cause the unit reports. That last field is what makes "someone power cycled the rack switch by hand" something you can act on.
What it can't do
- No scheduling on the unit. Off-hours power is a workflow with a Schedule trigger, not something stored on the hardware.
- A rollout does not survive a restart. If Neowit restarts mid-rollout, the remaining outlets are not picked up again. For a nightly job that is a retry the next night; for anything critical, keep the device list small enough to finish quickly.
- Per-outlet power metering is only reported by the models that have the hardware for it. For the unit as a whole, voltage, current, active power and cumulative energy are always available — so a workflow can check that an outlet reporting on is actually drawing power, which is how an unplugged or dead device gives itself away.
- Outlets go on the unit's own numbering. On multi-bank models Neowit learns the numbering from the unit; until it has, an outlet is reported as failed rather than guessed at.
Related
- Gude setup — connecting units.
- Restart every room overnight — the staggered whole-building rollout.
- Actions — how action nodes work in general.