GateLog

Inspiration

I live in a housing society. Our management committee rarely knows who came through the gate, when, or whether it was left open. The guard keeps a paper register, if anyone keeps one at all. Ring cameras already see all of it - but as a stream of alerts on one person's phone, not as a record a committee can read.

What it does

GateLog turns Ring device events into a daily gate report:

• The verdict first. The page opens with the answer. If a gate ever stays open longer than 10 minutes, it is flagged right at the top - an extra safety net. On a normal day that line stays empty. (The demo day includes one such case, 25 minutes, to show it.)
• The day in six numbers: visitors, vehicles, incidents, night events and more.
• Hour by hour chart: busy morning and evening, night hours greyed, the time the gate stood open.
• Flagged items first, then visitors (a person seen and the bell rung within two minutes counts as one visitor), then every event, oldest first.
• Works on the guard's phone at the gate, follows the phone's dark mode for the night shift, and prints on one A4 page for the committee meeting.

GateLog only reads events. It never opens or locks anything - the Ring API has no lock endpoint, and a log should not be able to open a gate.

How we built it

• Next.js 16 + React 19 + Tailwind 4, run with Bun. Server-side only Ring calls (the Ring API blocks browsers via CORS).
• Ring API client with three modes: live (Playground token), record (saves every real response as a fixture), replay (runs offline from those fixtures). So the demo is repeatable while still built on real Ring responses.
• Calls the real API: GET /v1/devices and GET /v1/history/devices/{id}/events, with paging.
• Signed webhook POST /api/ring/webhook: checks X-Signature (HMAC-SHA256 of the raw body) and refuses unsigned messages in production. Handles motion_detected (motion / human / vehicle / other), button_press, and contact-sensor faulted / cleared (the gate sensor).
• Idempotent store: sending the same day twice still gives the same 46 events, not 92.
• Report engine that derives incidents (gate open too long), visitors (person + ring), night activity and hourly buckets.
• 74 automated tests (bun test), 0 failing.
• The demo video is generated from a script with video-kit, a small open-source tool built during this hackathon.

Challenges we ran into

• The sandbox cannot produce gate traffic: the Playground Device only has on_demand (live-view) history. So we replay a scripted gate day through the same signed webhook a real Ring app would use, and the page clearly labels it "Demo data".
• The sandbox ignores the event_types filter - every filter returned the same 14 rows. We guard against it.
• History rows don't carry the motion sub-type, and there is no time-range filter, so a daily report has to page backwards and track which call each row came from.
• The official sample's webhook does not verify the signature. We followed the API docs instead. All of this is in our friction log.

Accomplishments that we're proud of

• A full loop: Ring event -> signed webhook -> store -> report on screen, tested.
• A live run against the real Ring sandbox, with its real responses saved as fixtures.
• A report that a non-technical committee member can read in ten seconds.

What we learned

How Ring's history and webhook APIs actually behave versus the docs - and that the most useful thing a camera can give a small community is not another alert but a summary.

What's next for GateLog

• Register a full Ring app (OAuth, real webhooks) and run it at a real gate.
• Multi-gate and multi-camera societies.
• A weekly summary sent to the committee, and a guard handover note at shift change.

Built With

• bun
• ffmpeg
• hmac
• nextjs
• playwright
• react
• ring-api
• tailwindcss
• typescript
• webhooks