parking_solution/wiki/concepts/entry-exit-points.md

---
type: concept
tags: [parking, architecture, devices, setup]
sources: []
updated: 2026-06-16
---

# Entry / Exit Points (pool-of-spaces model)

A parking lot is **one pool of spaces** with a flexible set of **entry points** and **exit
points** — any number of each, in any combination (1 in + 1 out, 1 in + 2 out, 2 in + 1 out, …).
There is **no "lane"** concept anywhere in the system (dropped 2026-06-16 — see below).

## Direction lives on the relay, not the controller

An access controller (e.g. a [[dingtian-relay]] board) has **several relays** — each relay opens
one barrier. Direction is a property of **each relay**, declared in the controller's config:

```jsonc
// access `devices` row — one Dingtian board
config: {
  host: "192.168.1.100",
  relays: [
    { relay: 1, direction: "entry", button: 1 },  // entry barrier; entry button on input 1
    { relay: 2, direction: "exit" }               // exit barrier; opened by a reader, no button
  ]
}
```

- `direction`: `entry` | `exit` | `both` (`both` = one barrier/relay serving in and out).
- `button`: the **input terminal** the transient **entry button** is wired to. Only entry/both
  relays have one. Absent = no button at that barrier (subscriber/reader-driven only).

The four real layouts all fall out of this:

| Layout | Controllers | Relays |
| --- | --- | --- |
| 1 barrier, both directions | 1 | `{relay:1, both, button:1}` |
| 2 barriers, 1 board | 1 | `{relay:1, entry, button:1}`, `{relay:2, exit}` |
| 2 barriers far apart | 2 | board A `{relay:1, entry}`, board B `{relay:1, exit}` |
| 1 entry + 2 exit | 3 | A entry; B, C each exit |

## Readers / cameras BIND to a relay

A reader or camera points at the barrier it physically sits at, via its config:

```jsonc
config: { ...readerConfig, controllerId: "<access devices.id>", relay: 2 }
```

Its **direction is inherited** from that relay. So an exit read opens **exactly that relay** —
no ambiguity even with multiple exit barriers ("the relay at that reader", decided 2026-06-16).
Binding is optional: an unbound device falls back to a `config.direction` + the first relay
site-wide of that direction (keeps the single-barrier case trivial). LPR is a snapshot sink —
an ANPR service ([[opencv-anpr-service]]) POSTs the plate as a `plate` read to the reader
endpoint, flowing through the same dispatcher.

## Resolution (one module: `apps/server/src/device-resolve.ts`)

- **Button press** → `relayForButton(controllerId, terminal)` → the entry relay whose `button`
  matches → entry flow → `pulseOpen(relay)`.
- **Reader/permit/LPR read** → `relayForDevice(reader)` → the bound relay → `pulseOpen(relay)`;
  direction inherited.
- **Snapshots** → `devicesByDirection("camera", dir)` → every camera serving that direction.

A directional barrier that contradicts the car's open-session state (an exit barrier scanned by a
car not inside, or an entry barrier by a car already in) is a wrong-barrier / [[anti-passback]]
refusal. A `both` relay defers to session state.

## The flows

| Flow | Trigger | Opens |
| --- | --- | --- |
| Transient entry | entry **button** press | the entry relay (button-mapped) → ticket prints |
| Transient exit | voucher scan at exit reader | the exit relay (reader-bound), if paid+grace |
| Subscriber entry | QR/RFID/plate at entry reader | the entry relay (reader-bound), if permit valid |
| Subscriber exit | QR/RFID/plate at exit reader | the exit relay (reader-bound), if permit valid |

Every open also fires a [[camera snapshot|append-only-event-chain]] (async, never blocks the open).

## Why no lane

"Lane" was a leftover from a rows-of-gates mental model. It added nothing here:

- **Occupancy** is a site-wide fold over the ledger (entries − exits); it never grouped by lane.
- **Device grouping** is now done by the reader→relay binding, far more precisely than a lane key.
- **Anti-fraud** doesn't use it — the signed chain, the "open must match a signed event" check,
  and [[reconciliation]] all work on *what happened*, not *which gate*. The relay's direction
  already catches an exit firing an entry barrier, better than a lane number would.

Dropping it removed `lane` from `ledger_events`, `device_events`, `sessions`, and the device
table (renamed `lane_devices` → `devices`). Because `lane` was part of the **signed canonical
form**, this is a versioned change: the canonical array no longer includes lane, and the signer
keyId bumped `sw-hmac-v1` → `sw-hmac-v2`. v1 events won't verify under v2 — intentional, gated by
each event's stored `keyId` (done pre-deployment, on throwaway data, so zero real cost). See
[[append-only-event-chain]].

## Camera snapshots (evidence, not a gate)

Captured **after** the barrier opens, **never awaited** — a camera failure can't delay or block an
open (the signed ledger is the decision). Stored as a **BLOB in the `snapshots` table** (single
backed-up DB, nothing scattered on disk), in its own table so hot telemetry scans don't drag image
bytes and images prune independently. Linked to the signed `vehicle_entry/exit` by `identity`.
Served read-only via `GET /api/snapshots/:id`. **Retention is unresolved** — see [[open-questions]].

## Related

[[entry-exit-readers]] · [[device-events]] · [[parking-session]] · [[anti-passback]] ·
[[append-only-event-chain]] · [[barrier-not-a-door]] · [[opencv-anpr-service]] ·
[[dingtian-relay]] · [[first-run-setup]]