Pathlight

12:10 on a Tuesday. Maya's café has a Ring camera over the front door and another over the counter. The lunch line has reached the door again, and two people look at it, turn around and leave. Her cameras recorded all of it. Neither can tell her that it happens every weekday, when it starts, or whether moving the pastry display last week made it better. (Maya and her café are our demo story; the walk-bys in the video are real.)

Pathlight gives those Ring cameras a map. Every visit lands on the owner's own floor plan as an anonymous path, so the cameras can finally answer business questions: where people go, where they wait, when the rush starts and whether a change worked. No new hardware, no installer and no calibration.

Real Ring cameras on a real linked account → signed webhook → recording → a path on the floor plan.

Inspiration

Small businesses already bought the cameras. What they can't buy cheaply is the answer to "where do my customers go?"

• More than 100 million Ring cameras are already installed (TechCrunch, 2026), and the U.S. has 36.2 million small businesses (SBA Office of Advocacy, 2025).
• Lines cost real money: 77% of U.S. adults say they will leave, or think about leaving, a restaurant when they see a long line (Nation's Restaurant News, 2021).
• The usual fix is dedicated counting hardware at $300–$1,200 per door, plus cabling and a subscription (vendor price guide, 2026). And a door counter only counts entries. It can't show where in the room the queue forms.

Ring already tells an owner what happened at the door. We wanted the same cameras to explain how the whole space is used.

What it does

1. Turn a floor plan into a twin

Upload a PNG or JPEG floor plan. Our TwinForge engine traces rooms and doors into an editable 2D/3D model, and Amazon Bedrock can read the drawing so furniture isn't mistaken for walls. The owner confirms two real measurements before anything is published.

2. Put the Ring cameras on it

Drag each camera to where it hangs, aim it, and pair it with an authorized Ring device. The owner picks the camera type, because Ring's API doesn't report one.

3. Every Ring visit becomes a path

Ring sends a signed motion webhook. Pathlight downloads the recording, finds the person with YOLO11n, projects their feet onto the floor plan and deletes the recording. When the next camera picks them up, the visit continues instead of starting over. Import last 7 days pulls past recordings from Ring Event History, so the first day already has real data.

4. Answers the owner can act on

• People heatmap in 2D or 3D, over any time span.
• Site analytics: visits per day against last week, visits by hour, a busy-times grid, time spent per zone, and entrances.
• Queue alerts when the counter zone passes the owner's limit.
• Today's actions: plain advice such as "open a second register around 12 PM", with the numbers it came from.
• Did the change work? The week before a layout change against the days since, area by area.
• Cars kept separate: Ring Smart Alerts vehicle events are counted by hour for the parking lot and never inflate visits.
• A weekly note from Amazon Bedrock, written from aggregate numbers only and checked figure by figure before the owner sees it.
• Several properties per account, on the web and on Android.

The hard part: positions without calibration

Camera analytics usually starts with an installer measuring reference points for every camera. A café owner won't do that. Pathlight works from what the owner can give it in a minute: where the camera hangs, where it points and what kind it is. From those weak priors it estimates where each person stands:

• the detected foot point is the person's ground position (Hoiem et al., IJCV 2008);
• a linear angle-per-pixel bearing across the lens's field of view, using the equidistant wide-angle model (Kannala & Brandt, TPAMI 2006);
• a near/far cue from where the feet meet the floor (Criminisi et al., IJCV 2000; Aghaei et al., WACV 2021).

Every position is drawn as an estimate with an uncertainty footprint (after Bertoni et al., MonoLoco, ICCV 2019), never as a measurement.

How we built it

Ring Partner API, called from the server at runtime. Tokens never reach the browser or the phone.

What Pathlight uses	Why
One-way account linking + OAuth token exchange	The owner authorizes Pathlight from Ring
Device inventory, status, capabilities, configurations	Pairing, and reading e2e_encryption before touching any video
Signed webhooks (HMAC-SHA256), durable deduplicated inbox	Each motion event becomes a visit, exactly once
Recorded clip download	The source for each path; deleted after analysis
Event History	Backfills the last 7 days on day one
Smart Alerts sub_type	People and vehicles are counted apart
Snapshots and WHEP live view	Camera previews and a bounded live view
Subscriptions	Reads the account's Ring plan, which recordings depend on

Amazon Bedrock (Nova Pro, Converse API) writes the weekly note, proposes rooms and doors from the floor-plan drawing as JSON that TwinForge validates, and gives optional, cautious activity labels on opted-in snapshots. Amazon SES sends verification, password-reset and opt-in camera-offline email.

The rest of the stack: Python, FastAPI and SQLite (WAL) for the API and worker; OpenCV 5 with YOLO11n (ONNX) for person detection; React and Three.js for the 2D/3D twin; Capacitor for Android; one Docker image on Railway. CI runs 177 backend tests, 48 browser tests, an Android build, and dependency, code and secret scans on every push.

Does it work? We measured it

We ran a 20-pass walk-by test with the three physical Ring cameras, comparing Pathlight's visit count with a hand count and its floor positions with 20 measured test points:

Test	Result
Walk-bys counted as visits	19 of 20 (95%)
Mean floor-position error	0.42 m
Median / 90th percentile	0.35 m / 0.78 m

On the hosted server, one real Ring recording became a 77-point path in 7.8 seconds, and the Event History import pulled in 16 past events.

Two restaurants piloted it for a week each. Both owners said they would keep using it. Adam Kitchen liked seeing exactly where people bunched up at the ordering counter, and asked for clearer staffing advice instead of a dashboard to interpret. La Rancho Café valued one bird's-eye view instead of separate camera feeds, and asked for a plainer explanation of the privacy safeguards.

Privacy, by design

• Paths are anonymous floor points: no faces, no identity, and no link between visits, days or places.
• Foot-traffic analysis is its own permission, off by default.
• Recordings are deleted right after analysis, and cameras with Ring video encryption are counted but never analyzed.
• Bedrock only ever sees aggregate counts, never images or people.
• Nothing acts on its own. Alerts and actions are suggestions for the owner.

We mapped every one of Ring's Computer Vision Guidelines to code and tests in the repo.

Challenges we ran into

Our 13-entry friction log has the details. The four that cost the most:

• Ring's edge rejected Python's default user agent during the token exchange with a bare Cloudflare 1010, so account linking failed with no explanation until we sent an explicit User-Agent.
• A clip-download 403 pointed at the device, but the real cause was a missing app permission. That one cost about four days.
• Nothing says when a recording is ready. A motion webhook arrives before its clip can be downloaded, so we added bounded retry-until-ready.
• The doorbell's WHEP session Location didn't match the docs, so closing a live view failed until we accepted the real shape.

On our side, the hardest problem was honesty: a heatmap looks precise even when the underlying positions are estimates. So every estimate is labelled, every simulated visit says Simulated, and the accuracy numbers above are published with their limits.

Accomplishments that we're proud of

• Real hardware end to end. Three physical Ring cameras on a real linked account, not only the Developer Playground.
• Measured, not claimed: 19 of 20 visits counted, and positions within 0.42 m on average.
• Day-one value from Ring Event History, instead of waiting a week for data.
• Built for Ring Appstore review from the start: separate consent, recordings deleted after analysis, export and deletion receipts, and US-only.

What we learned

• Give people the map, not the footage. Owners didn't want more video. A single floor plan with the visits on it was the feature both pilots singled out.
• Build against real payloads. Several of our Ring bugs came from trusting the documented shape instead of the one the device actually sent.
• Saying what you don't know builds trust. Labelling estimates and simulated data made the real numbers more believable, not less.

What's next

• Self-calibration from the visitors themselves (Krahnstoever & Mendonça, ICCV 2005), so accuracy improves on its own over time.
• Staffing suggestions from busy-hour patterns, which the first pilot asked for.
• Ring Appstore certification. The reviewer notes and certification profile are already drafted.
• More cameras per site, and uncertainty that grows with distance from the camera.

Try it

1. Open https://pathlight.up.railway.app and sign in with the judge account in the testing instructions.
2. Home opens on Demo café. Tap Show people heatmap, change the time span, then switch to 3D.
3. Open Analytics and flip Live only / All data to see the real Ring visits on their own.
4. Read the Weekly insight, then open Activity and pick a Live visit to watch the Ring recording beside its path.

The full 9-step judge path is at the top of the README.

The Ring cameras you already own, finally showing you how your space is used.

Built With

• amazon-bedrock
• amazon-nova
• amazon-ses
• android
• capacitor
• docker
• fastapi
• github-actions
• onnx
• opencv
• python
• railway
• react
• ring
• sqlite
• three.js
• typescript
• webrtc
• yolo