How it decides.

Seven stages, in order

Every event falls through the same stages. Most stop early, and usually that's the point. Where an event stops is the answer to “what did the agent do?”

1. Take it in. A change the poller saw on its 60-second check, or an alarm the gateway pushed.
2. Drop the known. Spare switches that are offline by design, and devices that aren't mine to touch, like a work laptop, are thrown out before any rule runs.
3. Refuse one reading. A device has to be seen down on 5 polls in a row, and for 300 seconds.
4. Find the owner. Which runbook, if any, owns this kind of problem. No owner means it tells me and does nothing.
5. Check it's allowed now. The guards, below.
6. Do one thing. One allowed action, then stop.
7. Look. A fix only counts when the device is seen working again, never because the controller said OK.

A home network is noisy. Devices reboot, phones roam between access points, the internet hiccups for a second. The first three stages throw that away, so the agent only ever thinks about acting on something real, owned by a runbook, and allowed right now. An alarm from the gateway never triggers a fix on its own. The poller is the only path that acts.

One real event, walked through

27 October 2026, with the agent armed. I unplugged an access point at the patch panel.

1. Taken in: the poller saw it offline at the next check.
2. Not on any known list, so it went on.
3. Seen down on every poll. At poll 6, about five minutes in, it passed the wait.
4. Owned by R1, the access point runbook.
5. No guard held it: no maintenance window, no firmware update, and its switch and the gateway were up.
6. It asked the controller to power-cycle the access point's port. The controller refused.
7. With nothing to look at, it escalated to me and recorded the action as failed.

That drill could only ever end in a refusal, which is its own case file. It's still the best walk-through I have, because it reached every stage.

The runbooks

A runbook owns one kind of problem and is allowed one action for it. Each has its own on/off switch, and one master switch sits above them all.

R1: an access point goes offline

Seen down on 5 polls and for 300 seconds, with every guard clear: R1 power-cycles the access point's switch port once, then waits up to 240 seconds to see it come back. At most 2 actions per access point every 6 hours, one per outage, and at least 6 minutes apart. It used to try a restart first. The controller won't restart a device it can't reach, so for an offline access point that step never fires.

R2: a camera goes offline

Same threshold. R2 power-cycles the camera's port, then has to see two things within 120 seconds: the port's link actually drop and come back, and the camera reconnect to the video recorder. At most 2 actions per camera every 6 hours, at least 3 minutes apart.

R3: a stuck Wi-Fi client (retired)

R3 was built to disconnect a Wi-Fi client stuck on a self-assigned address, one that never heard back from DHCP, so it would reconnect and ask again. It refused wired clients and infrastructure. It acted on nobody when 3 or more clients were stuck at once, because that's DHCP failing, not the clients.

It never acted, and I retired it on 2 November 2026. A drill with a test phone showed the controller never reports a self-assigned address for a Wi-Fi client. It keeps showing the old address, then none. So the trigger couldn't fire. For the next 7 days I counted Wi-Fi clients that stayed connected with no address at all. There were two, on one day. The long one got its address back after 13 hours without ever reconnecting. A trigger on “no address” would have disconnected a healthy device.

R4: the internet is slow or failing over

Nothing at home can fix a problem at the internet provider, so R4 diagnoses instead of fixing. Each internet alarm gets a snapshot on the spot: which line is carrying traffic, its latency against normal, throughput, the gateway's load, and how long a connection to two public servers takes from inside the house. R4 sorts the alarm into a one-off, an evening pattern, a failover storm, or stuck on the backup line, and checks that the line fails back.

After a verified failback it runs one speed test, at most 1 every 6 hours and 2 a day, never on the backup line. Only two things send me a notice: 30 minutes stuck on the backup line, and 3 failovers in a day. Each sends at most one notice every 6 hours, held until the internet is back to deliver it.

The guards

These run just before acting. Each one refuses before anything is written, so a refusal never spends the breaker's budget.

• Listed targets, by hardware address. Only a device whose hardware address is mapped to a port can be acted on. One access point's name ends in a space, and a lookup by name missed its port.
• Maintenance windows. While I've marked a window open for work in the network closet, and for 10 minutes after, outages are planned and left alone.
• Firmware. A device the controller is updating or adopting is busy, not dead. It's left alone, and for 15 minutes after.
• Upstream. If the device's switch, the gateway or another watched device is down too, the cause is shared. Power-cycling each device fixes nothing, so it tells me instead.
• Settle. After any of those clears, the device gets a full threshold to come back by itself. A freshly powered access point takes two to three minutes to boot.
• Power check. Just before a power-cycle it reads the port. No link and no power draw means nothing is plugged in, so it says “check the cable” instead of trying.
• A fresh look. The device is read once more. If it's back, it's left alone.

The brakes

• Four actions exist. Restart a device, power-cycle a switch port, reconnect a Wi-Fi client (unused since R3 retired), and run a speed test. Changing a setting, firmware or a firewall rule isn't refused by a rule. The code to do it isn't there.
• Never-touch ports. Every switch port that feeds more than one device is on a never-touch list: switch uplinks, the storage box, the gateway, and the agent's own computer.
• Rate limits. At most 2 fixes per device every 6 hours. The breaker trips at 3 actions in an hour or 5 in a day. It switches off every runbook, pages me, and stays off until I switch it back on. It remembers across restarts, so a crash loop can't quietly reset it.
• Old news. An alarm more than 10 minutes old is thrown away with a receipt, never acted on.
• Fail-safe. Switching it off is one setting, obeyed within one poll. Stopping the program stops the watching too. It can stop watching. It can never start acting on its own.

Where an event stops is the whole answer. Most of the time the right stage to stop at is an early one.