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