julian
23919164ee
The device pushes button events to the backend via its Input Link URL feature;
the backend decides. No polling — the chosen entry architecture.
packages/devices:
- dingtian driver: configureInputPush() writes the device's input_link_url
config (per-input server/port/path, en=1, active-LOW, plain HTTP) so each
input HTTP-GETs the backend on press/release. Extracted #readConfig/#writeConfig
(with the required command:setconfig injection + post-write reset tolerance).
apps/server:
- routes/devices.ts: public GET/POST
/api/devices/dingtian/:deviceId/input/:n/{on,off} — translates a device push
into an internal device event. Not behind cookie/CSRF (machine call from the
device); trust comes from the signed event log, not this request.
- device-events.ts: internal EventEmitter bus so the entry flow subscribes to
input events without coupling to HTTP. Wired into the server.
Verified on hardware: configured the device, then real presses on all 4 inputs
pushed to the backend (input N on+off, source = device IP). No polling.
wiki: device-input-flow concept (path + trust model for the flat/no-VLAN
network); dingtian-relay updated; index + log.
2.7 KiB
2.7 KiB
type, tags, sources, updated
| type | tags | sources | updated | ||||
|---|---|---|---|---|---|---|---|
| concept |
|
2026-06-15 |
Device Input Flow (button → backend → relay)
How a physical button press drives the entry lane. The backend is the source of truth: the device only reports the press; the host decides and commands the relay. This is the host-in-the- loop flow the dingtian-relay makes possible (and the uhppote-controller could not).
The path (no polling)
car arrives → driver presses button (input I_N, dry contact to GND)
→ device HTTP-pushes GET …/api/devices/dingtian/<deviceId>/input/<N>/on
→ backend: emit internal device event (device-events bus)
→ backend entry flow: create + sign an entry event, print the ticket
→ backend: pulseOpen(N) over UDP → barrier opens
→ (on release) device pushes …/input/<N>/off
- Push, not poll. The device's
input_link_urlfeature is configured (by the driver'sconfigureInputPush()) to call the backend on each input edge — see dingtian-relay. The driver's poll path remains only as a dev/fallback aid. - Per-input path carries the input number in the URL (
…/input/3/on), so routing needs no body parsing. Both edges (on/off) are sent. - Internal event bus (
device-events.ts, a NodeEventEmitter) decouples the HTTP/transport layer from business logic — drivers/pushes emit; the entry flow subscribes. Keeps the app device-adapter-pattern.
Trust model (important — flat network, no VLAN)
The relay-control direction (host → device) is unauthenticated UDP, and the site is a flat network with no VLAN (network-isolation is not yet enforceable here). So we do not trust the device or the network. Instead:
- Every barrier open is a host decision, recorded as a signed event BEFORE the relay fires (append-only-event-chain). If anyone opens the relay out-of-band (which the flat network allows), there is no matching signed event → a detectable anomaly. The anti-fraud guarantee is the signed log, not device/network auth.
- The inbound push endpoint is intentionally not behind the SPA's cookie/CSRF auth (it's a machine call from the device). A shared-secret / Basic-auth on the push is available as defence-in-depth (the device supports it) — worth adding, but it is not the security boundary.
- This sharpens under the autonomous-direction roadmap: with no operator, tamper detection via the signed log matters more than perimeter auth.
Status
Input push verified on hardware (all 4 inputs, real presses reaching the backend). The entry
flow itself (signed event + ticket print + pulseOpen) is the next build — see dingtian-relay.