julian
2915d141aa
Model the entry button (I1) and a Hikvision radar (I2) as named children of the access controller, and drive the button's 12V lamp on a spare relay. - Radar = the existing relays[].presenceInput one-car-one-ticket gate, now labelled presenceKind: loop|radar. A radar may idle opposite the button, so add a per-input active-level override: relays[].presenceActiveLow -> driver inputActiveLow set, inverting just that terminal (pure helper inputActive()). The Dingtian has one board-wide resting level otherwise. - AuxOutputDevice.setAux(channel,on) capability on the device interface (Dingtian latch) so business logic drives a NON-barrier lamp through the interface. Barriers still only pulseOpen — barrier-not-a-door preserved. - ButtonLightController: subscribes to the radar input edge + the camera lane status and drives a 3-state lamp — radar+car=solid, radar-only=blink (~1Hz), else off. Fails OFF on host loss/error; de-duped. A radar detection never opens a barrier on its own (advisory; threat model). - SetupWizard: presence kind + active-low + a button-light relay picker; sq+en i18n. Tests: button-light.test.ts (truth table + blink + fail-OFF + de-dupe), access-dingtian.test.ts (active-level inversion). Workspace build+lint+test green (158 server tests). Wiki: hikvision-radar, button-light-indicator + updates. Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V
64 lines
3.3 KiB
Markdown
64 lines
3.3 KiB
Markdown
---
|
|
type: entity
|
|
tags: [parking, device, sensor, radar, entry, presence]
|
|
sources: []
|
|
updated: 2026-06-24
|
|
status: settled
|
|
---
|
|
|
|
# Hikvision Radar (vehicle-presence sensor)
|
|
|
|
A radar mounted at an entry barrier that **closes a dry-contact relay when it detects something in
|
|
its vicinity** (a vehicle approaching the barrier). Wired to a **[[dingtian-relay|Dingtian]] input
|
|
terminal**, it acts as the vehicle-**presence** signal for the entry flow — functionally the same
|
|
role as an induction loop, just a different sensor.
|
|
|
|
## Where it sits in the model
|
|
|
|
The radar is a **child of the access controller config**, not a standalone device. On the entry
|
|
relay's spec (`config.relays[]`):
|
|
- `presenceInput` = the 1-based input terminal the radar's contact is wired to (e.g. **I2**).
|
|
- `presenceKind: "radar"` = a label (vs. `"loop"`) for the UI + telemetry; the **gate behaviour is
|
|
identical** either way.
|
|
- `presenceActiveLow` = set when the radar idles HIGH and pulls LOW on detection (see below).
|
|
|
|
The booth's wiring (first install): **button on I1, radar on I2**, both on the same 4-input Dingtian.
|
|
|
|
## Its job: the one-car-one-ticket gate (advisory, never opens a barrier)
|
|
|
|
The radar feeds the **[[entry-double-press|one car = one ticket]]** gate exactly as a loop does: the
|
|
entry button prints a ticket **only while the radar shows a vehicle present**, and **no second
|
|
ticket** issues until the radar **clears** (the car drove in) and a new car re-occupies the zone.
|
|
|
|
> The radar is **advisory**. A detection NEVER opens a barrier on its own — it only *gates* the
|
|
> button press. Entry still requires the physical press (and the capacity gate). This is the
|
|
> [[threat-model]] rule: a sensor reading is never the sole reason a barrier opens. (Distinct from
|
|
> the [[lane-presence-and-anpr-entry|ANPR bridge]], which admits *subscribers* through the gated
|
|
> subscription flow — also never a transient open.)
|
|
|
|
## The active-level gotcha (why `presenceActiveLow` exists)
|
|
|
|
The Dingtian normalises **all** inputs against one board-wide resting level (`inputRestingHigh`).
|
|
The booth's **button** (NO contact to GND) idles HIGH and pulls LOW on press. A **radar's dry
|
|
contact may idle the opposite way** — and if it does, the controller would read "vehicle present"
|
|
exactly when the zone is *clear*, inverting the gate (and the [[button-light-indicator|button
|
|
lamp]]).
|
|
|
|
Fix: mark the radar's terminal **active-LOW** (`presenceActiveLow: true` on the relay spec). The
|
|
driver then reads just that input inverted (active when LOW), leaving the button on the board
|
|
default. Implemented as a per-input override in `access-dingtian.ts` (`inputActive()` +
|
|
`inputActiveLow` set, derived from each relay's `presenceActiveLow`). Push-mode (the
|
|
`/input/:n/:edge` HTTP path) relies instead on the device's own `ilu.active_level`; the override is
|
|
the **poll-mode** equivalent.
|
|
|
|
## Also drives the button light
|
|
|
|
The same radar present/clear signal, combined with the camera's lane status, drives the entry
|
|
button's 12 V lamp on a spare relay — see [[button-light-indicator]].
|
|
|
|
## Status
|
|
|
|
Modelled 2026-06-24 (button I1 + radar I2 on the first booth's Dingtian). Gate behaviour reuses the
|
|
existing presence path; only the label + active-level override were added. Related:
|
|
[[dingtian-relay]], [[entry-double-press]], [[lpr-camera]], [[entry-exit-points]].
|