Inspiration

On December 5, 2025, water came through my ceiling. A drain pipe upstairs was sloped the wrong way, and the toilet above my dining room flooded two floors of my condo. Because it was a condo, the approvals alone took months, and the whole repair took over six months. I moved back in, new engineered hardwood and all.

One week later, on June 20, 2026, my basement flooded. Heavy rain, gaps in the foundation by the electrical panel, more than 60 units in my building under water. My insurer's first question decided everything: was it sewer backup, or clean rainwater coming in above ground? That one answer set which coverage limit applied.

Both times, the only evidence I had was my phone, because I happened to be home. Watermark is the record I wish had been running.

What it does

Watermark is a Ring Appstore app. When a Ring Flood & Freeze sensor detects water, Watermark opens a live session on a Ring Indoor Cam that already sees the room. Opening that session makes the camera record, and Watermark keeps pulling frames with Ring's own timestamps until the sensor reads dry.

What comes out is one evidence pack for the insurer: the timeline, the frames, room readings, device health, and a section listing everything the record cannot vouch for. The pack is checked against the 7 questions my adjuster actually asked on my real claim. It answers 2, partly answers 2 more, and leaves the other 3 to me because they are about the house and the policy. It never names a cause, because that is the adjuster's call.

Why it is needed: I tested Ring on its own with my real devices. I put my Flood & Freeze sensor in a bowl, pointed my Indoor Cam at it and poured water in slowly. Ring alerted my phone at 8:35 PM. The camera's own history showed nothing after 8:27, with water sitting right in front of it. Slowly rising water does not trip motion detection, and the Ring Chime cannot be set to sound for a flood sensor at all.

How I built it

  • Ring Partner API: the Early Access sensor webhooks (flood, freeze, tamper), device status, WHEP live sessions, image download with Ring's media timestamps, account linking, and chime playback.
  • ringwire: a typed Python client for the Ring Partner API that I wrote, open sourced and published on PyPI. Watermark's server is built on it.
  • Server: FastAPI. Every webhook is stored before anything else happens, because Ring keeps no history for sensor events. A reconcile loop polls device status, so a missed webhook can neither start nor end a recording silently.
  • Web app: Next.js, with my own design, following Ring's UX guide for partner apps.
  • AWS: EC2 hosts the live demo, S3 stores frames and packs, Rekognition labels what is in each frame, and IoT Core carries dispatch commands for the rover I am building next.
  • Honesty checks: a script fails the build if any number in my docs disagrees with the recorded run data, and I kept a friction log of every API surprise as I hit it.

Measured through the real Ring API on Ring's Developer Playground: the first Ring frame arrived a median 6.85 s after the sensor event across 10 runs, ranging from 6.6 to 11.2 s. The Playground has no sensors, so the sensor event there is simulated, and every pack says so on its first page.

Challenges I ran into

  • No device access outside the US. My Ring account linked fine, but the API returned an empty device list. I found the Developer Playground through another entrant's forum question, and built and measured everything there.
  • Image download never captures. It only reads recordings that already exist, so the live session became the core of the design, not a nice-to-have.
  • Sensor events have no history. If my server misses a webhook, Ring cannot give it back. Store first, then reconcile against status.
  • The Playground camera goes offline about 16 minutes after a token is issued. I learned to run measurements in the first 15 minutes.
  • Amazon Bedrock was blocked on my account ("Error 002") in every region I tried, even after Support called the case approved. I moved frame labelling to Rekognition.
  • Rekognition cannot see shallow water. On my real June flood footage, it labelled water on hardwood exactly like a dry floor. So Watermark only lets it add "water visible", never "no water". The sensor stays the record of wetness.
  • My first live test failed. The sensor sat tilted in the rounded bowl with only one contact in the water, and Ring said nothing. Setting it flat, both contacts down, fixed it, and it went in the friction log.

Accomplishments that I'm proud of

  • The controlled test: real devices and real water, and a camera that recorded nothing on its own while the sensor reported water. That is the gap Watermark exists to close.
  • An evidence pack that says what it cannot prove, instead of overstating what it can.
  • Checking the pack against my real adjuster's questions, not questions I invented.
  • Two open source contributions: ringwire on PyPI, and a pull request adding the first sensor script to Amazon's own Ring sample repo.

What I learned

Ring already knows when the basement floods; the camera just isn't listening to that signal. Motion detection is built for people at the door, not water creeping across a floor. And for an insurance claim, timestamps and honestly disclosed gaps are worth more than a confident summary.

What's next for Watermark

  • A rover for rooms with no camera: a 3D-printed rover that carries the Indoor Cam to the water. The code and its AWS IoT Core dispatch are in the repo; it has not driven on my floor yet.
  • Whole buildings: property managers and insurers with sensors in every unit, getting this record for all of them with nobody home. My building had more than 60 units flooded on the same day.
  • Written frame captions and summaries through Amazon Bedrock, once it opens on my account.
  • Real Ring sensors in production once Ring's sensor scope leaves Early Access.

Built With

Share this project:

Updates

Submission history