Skvass Gate Access - remote gym access automation

Opening a door is easy. The hard part is knowing, at the exact moment someone is standing in front of a scanner, whether that person has a valid membership, a live booking, a single-use access right, or no right to enter at all.

This project had to close that loop for a squash gym without depending on front-desk staff. The booking and membership system lived in a third-party API. The scanners spoke their own WebSocket protocol. The gate was physical hardware on-site. I was building from another country, with no direct access to the devices when something behaved strangely.

That changes the engineering shape. You do not just build endpoints. You build the ability to see, reason about and recover a physical system from a terminal somewhere else.

The Raspberry Pi at the venue became the bridge between software truth and physical reality. It runs the Python service, serves the admin UI, keeps the local SQLite state, accepts scanner WebSocket connections, and decides whether to open the gate.

The result is not a scheduling integration and not a gate controller. It is the glue in the middle, where operational truth becomes hardware behaviour.

The first version of any access system can push users. The useful version knows when not to. The biometric scanners hold device-side state — face templates, palm prints, enrolment IDs — so normal sync cannot casually delete and recreate everyone just because the booking platform changed one field.

The production path became deliberately frugal. A booking-platform sync inserts new clients, updates changed records, preserves field-derived values, soft-disables missing users, and marks only affected clients pending for the scanners. The scanner sync then hashes the canonical payload and sends only new, changed or newly inactive users. Inactive users are disabled, not deleted.

There is still a manual force-all button. It exists for device reset and recovery, not as the normal operating mode. That distinction matters in hardware systems. Routine work should be quiet; recovery tools should be explicit.

The booking platform identifies members by software identifiers: client IDs, booking IDs, membership IDs. Numbers issued at signup, mutated by every renewal and cancellation. The biometric scanners at the door identify members by something else entirely — a face print, a palm print, an enrolment ID stored on the device. Two identity systems looking at the same person from opposite sides: one ledger of bookings, one ledger of bodies.

The job of this gate is not to read a face. It is to make those two ledgers agree on the same person, every time, without anyone at the gym fixing it by hand.

Binding happens at enrolment. A member registers online and the booking platform issues them a client ID. Some time later they visit the gym, present a face or a palm to a scanner, and the device captures a biometric template against an enrolment ID. The bridge has to bind those two events: this client_id is this enrolment, the same human being. After that, the two sides evolve independently. A member extends their membership online — their face has not changed, but their access rights have. A member re-enrols their face after some change in appearance — their bookings have not changed, but their template has. Both kinds of change have to flow to the gate without breaking the binding.

The architecture follows from that:

• A canonical mapping from booking identifier ↔ scanner enrolment ID, owned by the bridge — neither external system is authoritative on its own.
• Field-level binding for contact data — email, phone, ID number — pushed to the scanners so they have enough context to operate without continuously reading back to the booking platform.
• Sync that touches only the records that have actually changed, so device biometric state is not blown away on every refresh.
• Force-all recovery as a separate, explicit tool — used after a mapping has drifted, never as the normal path.

The result is a member walking up to a scanner. Face matches. The bridge resolves face → enrolment ID → client ID → "valid membership today". Gate opens. The two identity systems were aligned three steps before the member ever got there.

AI was not a chatbot bolted onto the product. It was used as an engineering accelerator around documentation, protocol analysis, remote debugging and implementation. The system itself still makes deterministic access decisions. AI helped build the system that makes those decisions reliably.

This is the shape of a useful AI-assisted build: not a demo, not a prompt trick, but a working physical system where the software has to survive third-party APIs, undocumented device behaviour, remote deployment and hardware faults.

The bet is simple: with AI as an engineering partner, one person can own the full booking-to-gate loop and still keep enough discipline in the system to repair it when reality disagrees.