UC-001: Regular Member Access¶
Actor: Member Priority: Must Status: Implemented (protocol + firmware allow-list evaluation)
Summary¶
A regular hackerspace member unlocks the door at any time using their personal NFC card.
Preconditions¶
- Member has an active membership
- Member has been issued a DESFire EV2/EV3 NFC card
- Card UID is registered in the backend and included in the allow-list
- ESP32 has a valid, signed allow-list containing the member's entry
Main Flow¶
- Member holds NFC card against the outdoor terminal
- Terminal reads the card UID (with DESFire authentication in production)
- ESP32 receives the UID from the card reader
- ESP32 looks up the UID in the cached allow-list
- Entry has access type UNRESTRICTED — access granted
- ESP32 sends unlock command to NUKI Smart Lock via BLE
- Green LED lights up, buzzer gives short confirmation beep
- Door unlocks for 5 seconds, then auto-relocks
Alternative Flows¶
A1: Member initiates space shutdown¶
- Member is the last person leaving and presses the shutdown button inside (see UC-008)
- 120-second countdown starts, then NUKI locks the door
- Shutdown event logged
Note: The door also locks automatically 5 seconds after each unlock (auto-relock). This is normal operation and does not mean the space is closed.
A2: Stale allow-list¶
- At step 4, the allow-list has expired (valid_until passed, no recent sync)
- Since entry is UNRESTRICTED, access is still granted (permanent keyholders are trusted even with stale data)
Error Flows¶
E1: Card not in allow-list¶
- At step 4, UID is not found
- Red LED, denial buzzer pattern
- Access denied, event logged for next sync
E2: NUKI unreachable¶
- At step 6, BLE connection to NUKI fails
- Red LED flashes, error buzzer
- ESP32 retries BLE connection (up to 3 attempts)
- If still failing, access denied with error feedback
Postconditions¶
- Door is unlocked for 5 seconds
- Access event is queued for reporting at next backend sync
Access Rule¶
- Access type: UNRESTRICTED
- Time slots: None (24/7)
- Notifications: None (default)
- Grace period: N/A
Notes¶
- This is the most common use case, expected to cover ~80% of all door interactions.
- Members can always initiate space shutdown, regardless of any time restrictions.
- Scanning a card is a "space startup" — the keyholder takes responsibility for the space being open.