Files

T

julian 2915d141aa 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

2026-06-24 11:45:22 +02:00

3.3 KiB

Raw Blame History

type, tags, sources, updated, status

type

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 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 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, 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.

3.3 KiB Raw Blame History