Water control & safety
How Guardian bounds water damage: a hard physical limit on every valve open, with fast-reaction layers on top.
This is the most important page in the docs. Water protection systems get sold on their most dramatic feature — “the cloud closes your valve!” — and that framing is backwards. Guardian’s protection is layered, and the layer that matters most is the least glamorous one: the valve never opens without a limit. Understand the layers and you’ll know exactly what you’re protected against, and what you’re not.
Layer 1 — the open limit (the primary safeguard)
Every command that opens the LinkTap valve carries a volume or duration limit. There is no “just open it indefinitely” — every open is bounded. When the metered volume or elapsed time hits the limit, the valve closes on its own.
This is what physically bounds the worst case. If a hose bursts the moment you open the valve and every other layer fails — no sensors, no app, no internet — the burst still ends when the limit is reached. You get a bounded, known quantity of water instead of an unbounded flood running until someone notices.
Set your default limit to match real usage: enough for a normal fill or a day’s hookup use, and no more. A limit sized “generously, just in case” is a limit that does less for you on the day it matters.
Layer 2 — the Flooding Sentry (in-app, every tier)
The Flooding Sentry is Guardian’s in-app flood watchdog. While the app is open on a device on the rig’s network, a flood signal from any Shelly Flood sensor makes the Sentry close the valve immediately — no cloud, no plan required. It works for everyone, on every tier.
Where the open limit bounds the total, the Sentry cuts the water sooner: the leak stops when it’s detected, not when the limit runs out.
Layer 3 — the cloud fallback (every tier, app closed)
Flood sensors also push their alarm to Guardian’s cloud, which closes the valve through LinkTap’s cloud — even when your app is closed and you’re nowhere near the rig. Measured end to end, it takes about 16 seconds from the sensor alarm to the valve-close command. This runs on every plan, including Free: the shutoff is a safety feature and is never held back by tier — and neither is the away push notification that tells you it happened, nor operating the valve yourself from off the LAN. What the paid plans add around it is the rest of the away picture: automatic remote monitoring (so status stays current without you refreshing), extra alert destinations, and hosted history.
To be clear about what this layer is: it’s a fast-reaction layer on top of the hard limit — it stops the water in seconds instead of at the limit. It is not the thing standing between your boat and the bottom of the marina. That job belongs to the limit (layer 1) and to your boat’s own equipment (see the warning below).
What happens if…
Honest failure analysis. In every row, notice which safeguard survives: the limit.
| Scenario | What still protects you | What you lose |
|---|---|---|
| Internet goes down | Everything local: app control, the Flooding Sentry (app open on the LAN), and the open limit. | Remote access, push alerts, and the cloud fallback until it’s back. |
| App closed, Free plan | The cloud fallback still closes the valve (~16 s from alarm) and still pushes the alert to your phone, and the open limit still bounds any running open. | No Flooding Sentry (it needs the app open). Nothing else at the flood layer — the auto-shutoff still fires, and you can still open the app and CLOSE the valve from anywhere (closing is free on every plan). What Free lacks is on the control side: opening the valve from the app needs a paid plan, status only updates when you open the app and refresh, and none of it is kept as hosted history. |
| App closed, Basic/Premium | The cloud fallback closes the valve (~16 s from alarm) and pushes an alert; the limit still bounds everything. | Nothing meaningful — this is the away-from-the-rig configuration, with status staying current on its own rather than only when you refresh. |
| Flood sensor battery dead | The open limit — it doesn’t depend on sensors at all. | Early detection: no flood signal means no Sentry and no cloud fallback. Check sensor batteries as part of seasonal maintenance. |
| Gateway loses power or Wi-Fi | The limit travels with the open command, so a session already running still ends at its limit. | New commands (including remote or automatic closes) wait until the gateway is back. |
The pattern: detection layers can fail — batteries die, Wi-Fi drops, plans lapse. The limit can’t be forgotten, because the app never sends an open without one. That’s why it’s the primary safeguard and the others are described as layers on top.
Leaving the rig
- Short trips, hooked up: keep the limit tight and rely on the cloud fallback and its push alert — both on every tier.
- Longer absences: the strongest move is the oldest one — close the valve at the spigot. A closed valve has no failure modes. Guardian then tells you if water shows up anyway (bilge, plumbing, rain intrusion).
- Any absence: make sure the valve is at the source spigot, not the rig’s inlet — otherwise the hose is outside your protection entirely. See valve placement.
Flow metering and abnormal use
Because the G2S valve meters flow, Guardian isn’t limited to all-or-nothing protection. Abnormal continuous flow — water running when your usage pattern says it shouldn’t be — trips the valve and shuts water off at the source. Combined with a sensible open limit, that catches the slow failures (a weeping fitting, a stuck toilet valve) that never touch a flood sensor’s probes.