Skip to content

Case study · Property protection

From IoT leak sensor to automatic shut-off and a booked technician

Water sensors and smart valves in members' homes, wired to the dispatch system so a leak closes the valve, alerts the member and opens a work order, with interlocks so a valve never closes on the wrong home.

3
Interlocks before any valve can close
1
Event path from sensor to work order
Logged
Every event, with the decision and the reason
Per home
Consent and arming, never global

Context

Members can install leak sensors and a motorized shut-off valve. The vendor's cloud sends events, but on its own it only beeps. The business wanted a leak to become a closed valve, a text to the member and a technician on the way.

The problem

  • An automated valve close on the wrong property, or before the member agreed to it, is a real-world safety and liability problem, not a bug.
  • Sensors and valves are registered in the vendor cloud under device IDs that have no natural link to a member or a job site.
  • The first audit found every historical leak event had produced zero work orders. The automation everyone assumed existed did not.

Architecture

  1. 01Map devices to homes explicitlyEvery device is bound to one member and one service address in a mapping the staff can see and correct. Unmapped devices raise an alert instead of guessing.
  2. 02Three interlocks before a closeA valve closes automatically only if that same home has passed a test close, the member has given consent, and staff have armed it. All three are per home.
  3. 03Close first, then everything elseWhen the policy allows it, the valve command goes out before notifications and dispatch, so a slow downstream API never delays the part that stops the water.
  4. 04Every event leaves a trailEach sensor event is recorded with what the system decided and why, which is how the zero-work-order gap was proved and then closed.

Security model

  • Device control credentials are held server side only; the member app can request a close, it can never hold a device token.
  • Manual mapping changes disarm automatic dispatch for that home until re-armed, so an edit can never silently re-route a valve command.
  • Staff actions on valves are role-gated and logged.

Tasks now automated

  • Matching a sensor event to the right member and service address
  • Deciding whether the valve may close, and sending the close command
  • Texting the member that a leak was detected and the water is off
  • Opening the technician work order
  • Recording every event with the decision and reason

Time returned

4 to 0
Manual steps per leak event

Read the alert, look up the member, call them, open a work order. All four now run on their own.

Seconds
Event to valve decision

The close command goes out first, before any notification or dispatch call.

24/7
Coverage without an on-call person

The policy runs on every event, including nights and weekends.

Time figures are estimates per unit of work, based on the manual steps the build removed. Every other number on this page is measured.

Outcome

A leak event now produces a valve decision, a member text and a work-order attempt, each recorded with its result.

The safety model is explicit and reviewable: anyone can read the three conditions and see which one is missing for a given home.

With physical systems, the interlock design matters more than the automation. Write the conditions down before writing the code.

Next step

Tell us which system is slowing you down.

A 15 to 20 minute scoping call. If it is a fit, scope, price and timeline follow in writing.