julian
4418594af0
The controller new/edit modal hardcoded both its outputs and its inputs, so an
operator could neither add a generic event-driven relay nor a free-standing input
(e.g. a second radar at the exit). This unifies both into symmetric, first-class
lists. Behaviour for existing booths is unchanged (back-compat, no DB migration).
Outputs — one event→action relays[] list:
- A relay is "when EVENT X happens, do its action": entry/exit/both pulse a
barrier; a new `radarAlert` event drives a non-barrier alert lamp (blink while
its trigger input is active, SOLID once the camera confirms a car).
- Dropped the separate config.buttonLight block — the lamp is just a relays[] row
with direction:"radarAlert" (triggerInput + blink cadence). `alertRelaysOf()`
replaces `buttonLightOf()`; ButtonLightController keeps its proven 3-state
machine (serialized UDP, fail-OFF, hot-reload), now keyed per controllerId:relay
so several alert lamps on one controller run independently. Every barrier
resolver skips radarAlert rows (no auto-open; barrier-not-a-door intact).
Inputs — one first-class config.inputs[] list (the twin of relays[]):
- Each row is { input, role, relay?, kind?, activeLow?, cooldownSec? } with a
"+ Add input" button. role ∈ button | presence | alertTrigger; button/presence
name the relay they serve. An exit radar is just another presence row.
- Keystone `inputsOf(row)`: returns config.inputs[] or SYNTHESIZES it from the
legacy relays[].button/presenceInput/... fields, so relayForButton /
relayForPresence resolve identically from either shape — zero-downtime, no
migration. entry-flow.ts is unchanged (resolves through the same functions).
- Fixed a latent bug this exposed: the alert lamp's camera lock was hardcoded to
the ENTRY camera. Added relays[].lockLane ("entry"|"exit", default entry); the
lamp now locks on its own lane's camera, so an exit radar's lamp tracks the exit
camera. button-light tracks both #entryBusy/#exitBusy.
- Driver: extracted activeLowFrom(config) — merges inputs[] activeLow, legacy
relays[].presenceActiveLow, and the inputActiveLow escape hatch.
UI: the relay dropdown gained a "Radar alert" option (reveals trigger/lock/blink
inputs); InputEditor is rewritten to a generic list (role select folds loop/radar);
i18n sq+en kept at type-parity.
Tests: new device-resolve.test.ts (inputs[] resolution + legacy fallback identical
+ exit-radar resolves to the exit relay); button-light gains a two-independent-
alert-relays case and an exit-lamp lockLane case; access-dingtian gains
activeLowFrom cases. Full workspace build/lint/test green (i18n parity included).
Wiki + memory updated (button-light-indicator, entry-double-press, dingtian-relay).
Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V
101 lines
6.3 KiB
Markdown
101 lines
6.3 KiB
Markdown
---
|
||
type: concept
|
||
tags: [parking, entry, anti-fraud, safety, devices]
|
||
sources: []
|
||
updated: 2026-06-19
|
||
status: open
|
||
---
|
||
|
||
# One car = one ticket (entry anti-double-press)
|
||
|
||
A transient [[parking-session|entry]] is a button press → print a ticket → sign a `vehicle_entry`
|
||
→ open the barrier. **Nothing stopped a driver pressing the button repeatedly** and minting a fresh
|
||
ticket each time — a real flaw found 2026-06-19. The damage is threefold:
|
||
|
||
- **Ticket spam.** One car walks away with a fistful of tickets.
|
||
- **Occupancy corruption.** Each press signs a `vehicle_entry`, so [[capacity-occupancy|occupancy]]
|
||
(a fold over open sessions) counts one car as many — the lot reads "full" with empty spaces.
|
||
- **Ticket-shopping at exit.** With several open sessions for the same car, the driver pays the
|
||
cheapest and exits on it; the rest linger. A direct [[threat-model|booth/customer]] abuse.
|
||
|
||
The old `#inFlight` guard only blocked *overlapping* presses (it released in `finally`), so
|
||
press → print → press again issued a second ticket immediately. That is not enough.
|
||
|
||
## The fix is PER-RELAY CONFIG, chosen by available barrier feedback
|
||
|
||
The guard lives on the entry relay's spec (`config.relays[]` — see [[entry-exit-points]]), because
|
||
whether real one-car-one-ticket is *possible* depends on the hardware at that lane. Two modes:
|
||
|
||
### PRESENCE mode (preferred — when a vehicle-presence sensor is wired)
|
||
Inputs are a first-class `config.inputs[]` list (the twin of `relays[]`): each row is a terminal +
|
||
a **role** (`button` / `presence` / `alertTrigger`) + the `relay` it serves. A **presence** row =
|
||
the 1-based input terminal of a **vehicle-presence sensor** serving an entry/both relay on the same
|
||
[[dingtian-relay|controller]] (the Dingtian's inputs are decoupled from its relays). The sensor may
|
||
be an **induction loop** OR a **[[hikvision-radar|radar]]** (`inputs[].kind: "loop"|"radar"` — a
|
||
label; the gate behaviour is identical). A radar wired to idle opposite the button needs
|
||
`inputs[].activeLow: true` so its edge reads correctly. **Multiple radars (entry + exit) are just
|
||
multiple presence rows** — adding an exit radar is adding a row. (Pre-2026-06-28 configs wired this
|
||
on `relays[].presenceInput/presenceKind/presenceActiveLow`; the resolvers still read those as
|
||
back-compat, synthesizing inputs[] from them.) The rule makes one-car-one-ticket **physical**:
|
||
|
||
- A press prints **only while a car is present** on the loop.
|
||
- After a ticket prints, the relay is **disarmed** — no second ticket — **until the loop CLEARS**
|
||
(the car drove through = it entered) **and a new car re-occupies** it.
|
||
|
||
So mashing the button while sitting on the loop does nothing; a *new* car must physically arrive
|
||
before another ticket can issue. The flow observes the loop's input edges (both directions) to track
|
||
`present` + `armed` per relay. This is how real lanes behave.
|
||
|
||
### COOLDOWN mode (fallback — no barrier feedback)
|
||
When no loop is wired, `relays[].entryCooldownSec` suppresses repeat presses on that relay for N
|
||
seconds after a ticket (default unset = no guard; a sensible value is ~10–12 s — long enough for the
|
||
car to pull through, short enough not to block the next legitimate car). It is a **timer, a
|
||
mitigation, not a guarantee** — a determined abuser can wait it out. Use it only where presence
|
||
feedback isn't available; prefer wiring a loop.
|
||
|
||
The two can coexist (presence first, cooldown as a backstop), but presence is authoritative when set.
|
||
|
||
## A suppressed press is a NO-OP, not an anomaly
|
||
|
||
A blocked/repeat press is recorded as **unsigned [[device-events|telemetry]]** (a `device_events`
|
||
`kind:"input"` row with `entrySuppressed:true` + the reason), **not** a signed ledger anomaly. It
|
||
isn't fraud — it's the system correctly refusing to double-issue — so it stays out of the immutable
|
||
chain and off the red activity-log feed. (Operator's call, 2026-06-19.) The press is still auditable
|
||
in telemetry if ever needed.
|
||
|
||
## Invariants preserved
|
||
|
||
- **Fail-closed entry is untouched.** A suppressed press simply does nothing; the printer-down HOLD
|
||
path ([[append-only-event-chain]]) and the [[fail-state-safety]] rules are unchanged.
|
||
- **The barrier is still intent-only.** No timed close; presence is only a *gate on ticketing*, not
|
||
a barrier-close trigger ([[barrier-not-a-door]]).
|
||
- **State is in-memory + rebuildable.** The per-relay `armed/present` map is runtime state on the
|
||
host (single-writer); it is derived from live input edges, never the source of truth. A restart
|
||
starts armed (the first press after a restart works), which is the safe default.
|
||
|
||
## As-built (2026-06-19; inputs[] 2026-06-28)
|
||
|
||
- Inputs live in `config.inputs[] = [{ input, role, relay?, kind?, activeLow?, cooldownSec? }]`
|
||
(`device-resolve.ts`). `inputsOf(row)` returns them, **or synthesizes** the list from the legacy
|
||
`relays[].button/presenceInput/...` fields when a controller predates inputs[] (one back-compat
|
||
shim; the UI no longer writes the legacy fields). `relayForButton`/`relayForPresence` resolve
|
||
through `inputsOf`, carry `presenceInput`/`entryCooldownSec` onto the `ResolvedRelay`, and only ever
|
||
gate entry/both relays. An exit radar = a `presence` row on the exit relay.
|
||
- `EntryFlow` (`entry-flow.ts`) keeps a `#guard` map keyed `controllerId:relay`: `#onPresenceEdge`
|
||
tracks the loop, `#suppressReason` decides presence/cooldown, `#recordSuppressedPress` writes the
|
||
telemetry. The guard disarms + stamps the cooldown on **print success** (not on open).
|
||
- [[first-run-setup|SetupWizard]] relay editor: entry/both relays expose a **Presence loop
|
||
(terminal)** field and, when no loop is set, a **Cooldown after ticket (s)** field (localized
|
||
sq+en — see [[i18n]]).
|
||
|
||
## Open
|
||
|
||
- **No automated test yet** (the standing harness gap) — verify on hardware: with a loop, a held
|
||
button issues one ticket; after the car clears the loop a new car gets a fresh one. Without a loop,
|
||
a cooldown blocks the repeat and the suppressed press lands in telemetry.
|
||
- **Exit side:** the symmetric concern (re-reading a ticket at exit) is already handled differently —
|
||
exit validates against an open session, so a second read finds the session closed (no double-exit).
|
||
No presence gate needed there today.
|
||
- **Loop as a safety/anti-tailgate signal** is a larger future use of the same input (free-exit
|
||
detection is noted in [[bom]]); this change uses it only to gate ticketing.
|