Arrival Desk

Inspiration

Small businesses often need a simple way to acknowledge a visitor's request without collecting an identity or pretending that motion is a reliable count. Arrival Desk explores a deliberately narrow handoff: a physical-style request event becomes an anonymous ticket that staff can claim and complete.

What it does

A deterministic in-memory engine accepts button presses, motion, and device health events. A button press creates a queued ticket. Staff commands claim or complete it; an explicit clock tick marks queued or claimed tickets overdue after five minutes. Wait and service durations are calculated on completion. Motion is intentionally recorded as ignored rather than treated as a visitor count.

How we built it

The original Python engine is preserved in the Local MVP with its standard-library HTTP server, tests, fixture, and local journal boundary. The Try it out page ports the same behavior into a dependency-free JavaScript Engine class. Both use explicit UNIX timestamps so a scenario can be replayed and compared without wall-clock drift. The page is a static file: its controls write state locally and never call a device or external service.

Challenges

The main design challenge was making a small state machine understandable without hiding its edge cases. Rejected commands, ignored motion, device health, overdue transitions, raw JSON, and the human-friendly ticket view are shown together. Keeping the browser port semantically aligned with the original Python behavior also required treating timestamp validation and unknown-ticket responses as observable behavior.

What we learned

A narrow event vocabulary can make the boundary between observation and action explicit. Separating snapshot from tick also prevents a read-only view from silently changing operational state. Deterministic fixtures make local review repeatable, but they do not substitute for an official integration environment.

Accomplishments

The deliverable includes a responsive offline UI, an accessible timeline, clear queue metrics, an event composer, raw state inspection, a preserved Python MVP, and parity checks covering the original fixture plus edge cases. The thumbnail and gallery are captures of the actual local UI, not device imagery.

Next steps

An authorized owner could validate the documented Ring webhook/device contract in a controlled test account, add authenticated staff roles, decide on a retention policy, and run a security/privacy review before considering production use. Those steps have not been performed here.

Verification limits

Verification here is local and synthetic: copied Python unit tests, local HTTP checks, Node parity cases, and browser checks against file:// and a local static server. No official Ring credential, device, simulator, production endpoint, upload, or remote action was used. The checks are targeted rather than exhaustive, and no uptime, scale, or accessibility certification is claimed.

Built With

Share this project:

Updates

Submission history