feat(devices): radar presence input + button-light output on the controller
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
This commit is contained in:
@@ -46,11 +46,28 @@ see [[dingtian-vs-mqtt]].
|
||||
|
||||
## Driver & config API
|
||||
|
||||
The `dingtian` driver ([[device-registry]]) implements three capabilities:
|
||||
`AccessControlDevice` (relay pulse/latch over UDP), `InputDevice` (read inputs + poll-based
|
||||
press/release events ~50 ms), and `PreconditionDevice` (below). Config fields include a separate
|
||||
**`httpPort`** — the device's web/config API is on a configurable HTTP port (default **80**),
|
||||
distinct from the UDP control port 60001.
|
||||
The `dingtian` driver ([[device-registry]]) implements:
|
||||
`AccessControlDevice` (relay pulse/latch over UDP), `AuxOutputDevice` (latch a NON-barrier output —
|
||||
see below), `InputDevice` (read inputs + poll-based press/release events ~50 ms), and
|
||||
`PreconditionDevice` (below). Config fields include a separate **`httpPort`** — the device's
|
||||
web/config API is on a configurable HTTP port (default **80**), distinct from the UDP control port
|
||||
60001.
|
||||
|
||||
### Spare relays + aux outputs (`setAux`)
|
||||
|
||||
A 4-input board typically has spare relays once the entry/exit barriers are wired. These drive
|
||||
**non-barrier indicators** — e.g. the entry button's 12 V lamp (see [[button-light-indicator]]).
|
||||
Business logic drives them through the device-agnostic `AuxOutputDevice.setAux(channel, on)` (a
|
||||
latch), **never** the barrier `pulseOpen`. The [[barrier-not-a-door]] rule doesn't apply to an aux
|
||||
output (it never gates a vehicle), so holding/blinking it is fine.
|
||||
|
||||
### Per-input active level (`presenceActiveLow` / `inputActiveLow`)
|
||||
|
||||
Inputs are normalised against ONE board-wide resting level (`inputRestingHigh`). When a sensor (e.g.
|
||||
a [[hikvision-radar|radar]]) idles **opposite** the button, list its terminal as active-LOW —
|
||||
sourced from each relay's `presenceActiveLow`, merged into the driver's `inputActiveLow` set — so
|
||||
that one input is read inverted while the button keeps the board default. (`inputActive()` is the
|
||||
pure helper; push-mode uses the device's own `ilu.active_level` instead.)
|
||||
|
||||
### Precondition: input_link_relay must be OFF
|
||||
|
||||
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
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]].
|
||||
Reference in New Issue
Block a user