Entry control — barcode and NFC
Entry control is Lunda's most critical component — it's where things show up first when something is broken. A guest walks up, tries to enter, and either gets in or doesn't. One second of latency difference is the difference between a 3-metre queue and a 30-metre queue at 07:30 on a Saturday.
Two scanning modes
Lunda works with two identifier types:
- Barcode (QR + 1D) — on a paper ticket, a printed voucher, or a QR on a phone screen. The reader (Honeywell, Zebra, Datalogic) typically processes within 200–400 ms.
- NFC (card + chip) — physical pass card tapped to the reader. Much faster, typically 100–150 ms.
Both modes run simultaneously: the guest goes wherever is convenient. Online-purchased ticket → QR on the phone. Annual pass → NFC card. Buy both and both work.
Sub-300 ms target
Measured response time (scan → backend reply → gate open signal) averages 235 ms across our customers, 95th percentile 290 ms. This matters because:
- Under 200 ms: the guest doesn't perceive a wait, it feels natural.
- 200–500 ms: noticeable but tolerable.
- Over 500 ms: the guest stops, looks sideways, looks back — the next guest piles up.
The 300 ms target isn't tech vanity, it's an operations number: at 09:00 on a Saturday you need 6–8 entries / minute / gate. If it slows, a queue forms.
Turnstile integration
Lunda integrates with three turnstile vendors:
- Boon Edam (Dutch, premium) — Speedstile / Lifeline models, mostly at thermal baths.
- Gunnebo (Swedish) — SpeedStile / SmartStile, versatile entry control.
- A Hungarian vendor — custom mechanical arms, good value, smaller venues.
The Lunda backend speaks a standardised protocol (Modbus / RS-485 / HTTP REST depending on the vendor) to send the open signal. Thanks to our API abstraction, the backend code doesn't know which vendor's gate it's opening — everything is turnstile.open(gateId, direction).
Fail-open vs fail-secure
A critical decision at every venue: what happens if the backend doesn't respond?
- Fail-secure — block anything suspicious. Pass unverifiable → no entry. Stricter, safer, but produces longer queues during outages.
- Fail-open — if the backend doesn't respond within 1 second, the gate opens. Guest-friendly but exploitable (someone tailgates while the system is down).
Most baths choose fail-secure because the risk (unauthorised entry, accident, insurance dispute) is greater than the inconvenience. The security staff assigned to the gate handles the fail-secure window: if a guest complains, they let them in manually.
It's a toggle in the Lunda admin: fail-secure by default, but event-driven (e.g. fire alarm, evacuation) it can flip to fail-open.
Entry logging — legal requirement
We log every entry and exit: guest ID, pass/ticket ID, gate, timestamp, mode (barcode/NFC), result (success / fail). We do this because:
- For swimming pools the law requires it (life-safety and accident traceability — who's inside if there's an incident).
- We use it for pass-usage analytics (what time guests come, how long they stay).
- In disputes ("I wasn't there") it can be looked up.
Logs are retained for 7 years — standard in the Lunda DB. A quarterly archive job moves older records to cold storage.
Lesson
Entry control isn't a turnstile, it's a system: scanner + backend + open signal + log. Sub-300 ms target, fail-secure default, two scanning modes, statutory log — these are the mandatory baseline.