Smart Visitor Assistant

Ring alerts, ranked by AI, so you know what to check first

Comment

Inspiration

A doorbell alert is only useful if you can understand it quickly. Most home security apps send every motion event the same way, so people learn to ignore them. For an elderly person living alone, or someone who cannot hear a doorbell, a missed or confusing alert matters. We wanted an app that tells you what to look at first, and why, in plain words and large, clear visuals.

What it does

Smart Visitor Assistant turns Ring doorbell and motion events into a short, ranked list a homeowner can act on.

  • AI priority levels: every alert gets a score from 0 to 100 and a level (critical, high, medium, low), plus a "Why this priority?" list so the result is explainable.
  • Plain-language summaries: for example, "Someone rang the doorbell at 2:10 AM. They are not on your expected-visitor list. It is late, so check before opening."
  • Home summary: one headline that says what needs attention first.
  • Pre-approved visitor workflow: add a plumber, a family member or a courier with a day, a time window and an optional "one visit only". When they ring inside that window the arrival is logged as expected and stays low priority. Unknown visitors ask for a decision: Let them in, Don't open or Ask to wait.
  • Visitor history: every arrival with entry time and the decision taken.
  • Accessibility: a full-screen urgent alert with a slow colour pulse (under one flash per second) and vibration, text size up to 200%, a high-contrast theme, large buttons, screen-reader labels, and priority always shown as icon + word + colour, never colour alone.

How we built it

Backend (Node.js + Express)

  • Receives Ring webhooks (v1.1) for motion_detected, button_press, device_offline and device_online, verifies the X-Signature HMAC-SHA256 header, and uses meta.request_id for idempotency.
  • Calls the Ring Partner API (/v1/devices, /v1/history/devices/{id}/events) and handles the OAuth refresh-token flow, saving the rotated refresh token. Event History polling is the fallback when webhooks cannot reach a local machine.
  • A built-in Ring event simulator sends events in the same shape as real webhooks, so the full pipeline runs without hardware.
  • Live updates reach the app through Server-Sent Events.

Priority scoring. The score is rule-based, so every result can be explained:

$$ s = \operatorname{clamp}_{[0,100]}\big(b + 30\,n + 25\,r + 10\,u - 35\,e\big) $$

where $b$ is the base score for the event type (doorbell 50, person 40, camera offline 60, other motion 15), $n$ is 1 during quiet hours for a person or doorbell, $r$ is 1 for repeated detections within 10 minutes, $u$ is 1 for an unknown doorbell visitor and $e$ is 1 for a pre-approved visitor. Levels: critical at $s \ge 80$, high at $s \ge 60$, medium at $s \ge 35$, otherwise low.

App (Flutter, Dart) with Home, Alerts, Visitors and Settings tabs. The app only talks to our backend, never to Ring directly.

Testing: 10 automated backend tests cover signature rejection, duplicate webhooks, the pre-approved flow, night-time escalation and the visitor decision flow.

Challenges we ran into

  • Server-only API. Ring's endpoints block browser requests, so everything had to go through a backend.
  • Webhooks need a public HTTPS URL. That is awkward on a laptop, so we added Event History polling. This created duplicates (the same real event arriving by webhook and by polling), which we solved by merging events from the same device and type within a short window.
  • Quiet hours that cross midnight (22:00 to 06:00) and timezone handling needed careful logic.
  • Token rotation. Each refresh invalidates the old refresh token, so it must be saved every time.
  • No door control. The documented Ring API has no unlock or two-way-audio endpoint, so "Let them in" is recorded in the app and does not act on the door. We built the workflow to be honest about this.
  • Documentation gaps. Some documentation pages returned 404, so we based the Event History parsing on the official ring-api-helloworld sample.

What we learned

  • Explainable rules beat a black box for a security product: users trust an alert more when they can see why it ranked high.
  • Accessibility works best as a design rule from the start: large type, redundant cues (icon, word, colour) and slow, safe flashing.
  • Idempotency, signature checks and token handling matter as much as features when working with webhooks.

What's next

  • Show Ring snapshots and live view (WHEP) in the alert screen.
  • Optional AWS Bedrock rewriting of summaries in simpler words (the hook is in the code and is off by default).
  • Caregiver mode: notify a family member when an elderly user does not respond to a high-priority alert.

Code: https://github.com/HudebiaShaikh/Smart-Visitor

Built With

Share this project:

Updates

Submission history