Dingtian relay driver — resolves the ticket-first entry blocker
The Dingtian board's inputs are independent of its relays (configurable), so a button on an input can report to the host WITHOUT auto-firing a relay — solving the access-controller-button-flow blocker the UHPPOTE/ZKTeco couldn't. packages/devices: - access-dingtian.ts: `dingtian` access driver implementing AccessControlDevice (relay pulse/latch via UDP string protocol :60001), InputDevice (read inputs + poll-based press/release events, active-LOW), and the new PreconditionDevice. - PreconditionDevice capability on the interface: a device can report config it requires for parking and optionally fix it. Dingtian checks input_link_relay via the HTTP config API and can disable it. - httpPort config field — the web/config API port is separate from UDP control (this unit uses 8080, not the default 80). - Register dingtian; export driver objects from the package. Verified on real hardware (DT-R004 @ 10.0.10.172): status read, relay pulse, input events; disabled input_link_relay via the driver, then confirmed pressing inputs fires NO relay (0000) — host-in-the-loop entry works. Config-write gotcha recorded: config_set.cgi requires "command":"setconfig" injected after "status" (GET omits it) or the POST silently no-ops. apps/server/scripts/dingtian-test.mjs: status / watch / pulse hardware test. wiki: dingtian-relay verified; button-flow marked RESOLVED; index + log.
This commit is contained in:
@@ -1,17 +1,22 @@
|
||||
---
|
||||
type: decision
|
||||
tags: [parking, hardware, access-control, blocker, open]
|
||||
tags: [parking, hardware, access-control, resolved]
|
||||
sources: [parking-system-architecture]
|
||||
updated: 2026-06-15
|
||||
status: open
|
||||
status: settled
|
||||
---
|
||||
|
||||
# Blocker: Push-Button → Auto-Open Defeats the Ticket-First Entry Flow
|
||||
# Push-Button → Auto-Open: the Ticket-First Entry Blocker (RESOLVED)
|
||||
|
||||
> **Procurement-blocking finding (2026-06-15), from on-hardware testing.** The UHPPOTE and
|
||||
> ZKTeco access controllers **on hand** cannot, as wired/configured, deliver the required entry
|
||||
> flow. This blocks the entry lane and needs a hardware/wiring resolution before that lane ships.
|
||||
> Work paused here to focus on the business side. See [[entry-exit-readers]], [[trust-boundary]].
|
||||
> **✅ RESOLVED (2026-06-15) by the [[dingtian-relay]] controller.** Its inputs are decoupled from
|
||||
> its relays (`input_link_relay` configurable off — done & verified on hardware), so a button on an
|
||||
> input reports to the host **without** firing a relay. Host-in-the-loop entry
|
||||
> (`button → host → ticket → host opens relay`) now works. The original blocker (below) stands as
|
||||
> the record of why the UHPPOTE/ZKTeco units couldn't do it.
|
||||
>
|
||||
> **Original procurement-blocking finding (2026-06-15), from on-hardware testing:** the UHPPOTE and
|
||||
> ZKTeco controllers on hand could not, as wired/configured, deliver the required entry flow.
|
||||
> See [[entry-exit-readers]], [[trust-boundary]].
|
||||
|
||||
## The required flow
|
||||
|
||||
|
||||
Reference in New Issue
Block a user