Ring TelemetryOps

An autonomous concierge that diagnoses Ring doorbell problems with Amazon Bedrock and tells customers how to fix them, notifying only when something is wrong.

Comment

Inspiration

Many Ring support contacts start with small, fixable problems: a dirty or smudged lens, a weak Wi-Fi signal, a drained battery, a doorbell that lost its transformer power. The customer sees "something is wrong" but not why. I wanted a concierge that notices these problems on its own, explains in plain language what is wrong and how to fix it, and stays silent when everything is fine. Ring's Computer Vision Guidelines shaped the design: cheap deterministic filters first, the expensive model only for the minority of anomalies, guardrails on the model's text, and no image retention.

What it does

Ring TelemetryOps watches a Ring video doorbell (Wi-Fi signal, battery, transformer power and image quality) and notifies the customer only when something is wrong.

  • A deterministic pre-check (OpenCV image analysis plus one three-level severity table: GREEN, DEGRADED, CRITICAL) classifies every metric. A critical problem is diagnosed on the first heartbeat; a degraded one needs 3 consecutive heartbeats (45 s). A doorbell press, motion or live view diagnoses at once if a problem is already present.
  • Only when the pre-check finds an anomaly, the app calls Amazon Bedrock (Claude Haiku 4.5) with the camera keyframe, the metrics and Ring-informed troubleshooting procedures. A healthy frame never leaves the server.
  • The customer sees status, problem type, confidence and a short recommended fix; a collapsed "Technical details" view gives support-ticket data. For anything electrical, the advice is to contact an electrician or Ring Support.
  • Two modes: a Digital Twin simulator of the Ring Video Doorbell 4 with physical fault injection (to demonstrate the full diagnosis), and a Ring Partner API mode that works with a real device from the Ring Developer Playground: device status, capabilities and settings, Event History, image snapshots, 5-second recordings, RTSPS stream statistics, WHEP live video in the browser and a signed webhook receiver.
  • What Ring does not share with partner apps (Wi-Fi, battery, voltage) is reported honestly as a "Partial check", never invented.

  • A funnel line shows how many analyses ran, how many healthy frames stayed on the server and how many Bedrock calls were made. Every report has a "Was this helpful?" vote.

    How I built it

  • Backend: Python and FastAPI. OpenCV for sharpness, brightness and banding checks (including cropping Ring's fixed-size watermark in pixels before measuring). A single severity table in JSON drives both the pre-check and the interface.

  • Reasoning: Amazon Bedrock with Anthropic Claude Haiku 4.5 (us.anthropic.claude-haiku-4-5-20251001-v1:0, us-east-1) with a Ring-informed knowledge base. Severity and root-cause domain come from the deterministic pre-check; the model provides the reasoning. Its answer must pass a report contract (plain language, at most 60 words, no electrical work, no description of people, no false numeric claims) with one corrective retry; otherwise a labelled local fallback keeps the same schema.

  • Ring Partner API: a small read-only server-to-server client with the required headers. Images are analyzed in memory (a clip uses a temporary file deleted right after analysis). WHEP live video goes from Ring to the browser; the server only relays the SDP exchange.

  • Frontend: plain HTML, CSS and JavaScript with a canvas-based live-view simulator.

  • Quality: 869 backend tests (pytest) and 195 frontend tests (Node), with a fake Ring server for the Partner API. I developed it as a solo project, using AI coding agents (Claude Code) under my direction.

    Challenges I ran into

  • The model ignored constraints. It copied electrical specifications and unobservable causes from the retrieved procedures, and in one scenario returned a wrong root-cause domain every time. I fixed it with a validation contract, one corrective retry, and by taking severity and domain from the pre-check.

  • Thresholds from a simulator did not transfer to real Ring images. A banding detector gave false alarms on real frames until I cropped the watermark and required periodicity, so I calibrated on real Playground frames.

  • Ring camera status only exposes online/offline. There is no Wi-Fi, battery or voltage for cameras, so the full diagnosis is shown in the simulator and the Partner mode reports a partial check.

  • An undocumented 422 GRECO_NO_VALID_KEY on the latest-image download. I now start from the newest event's timestamp and try a few events.

  • Honest limits: real Playground frames are all healthy, so Bedrock diagnosis is demonstrated in the simulator. Signed webhooks were verified with my own test tool and fixtures, not with real Ring webhooks.

    Accomplishments that I'm proud of

  • A funnel where a healthy frame never leaves the server and Bedrock is called only for real anomalies (0 Bedrock calls in my live Ring runs).

  • Live verification against the real Ring Developer Playground (snapshots, recordings, RTSPS statistics, WHEP live video) and against Amazon Bedrock.

  • A guardrailed model output: in the final live verification, 0 contract retries.

  • An 11-entry friction log with concrete suggestions for Ring's platform.

    What I learned

  • Put deterministic checks first and keep the model for what only it can do; validate its output instead of trusting it.

  • Calibrate on real data: simulator-tuned thresholds can fail on real camera frames.

  • Be explicit about what the data source does not provide, instead of filling the gap.

    What's next for Ring TelemetryOps

  • Validate the webhook receiver with real Ring webhooks and use health events if Ring exposes them.

  • Use Wi-Fi, battery and power data in Partner mode if Ring adds them to camera status.

  • Support more Ring device types and more troubleshooting procedures.

Built With

Share this project:

Updates

Submission history