julian
4319fb86dc
- dingtian-relay: relay+input controller (4ch on hand). Inputs are decoupled from relays (configurable via input_link_relay) — solves the access-controller-button-flow blocker the UHPPOTE couldn't. Full protocol from the SDK (UDP string control :60001, `00` status parse, input_link_url push, multicast discovery). Driver + hardware test still to build. - dingtian-vs-mqtt: use direct HTTP/UDP now; MQTT skipped (broker = extra infra + failure mode + overkill at one-host/few-devices scale) but kept for later multi-lane scale. - autonomous-direction: record the roadmap to fully unmanned (no booth) and how it reshapes the threat model (operator-fraud -> unattended-machine threats), makes host-in-the-loop entry mandatory, and raises fail-state stakes. - threat-model: note the unmanned shift. index + log. gitignore the vendor SDK (dingtian/, 71MB of binaries/examples) — reference only, protocol captured in the wiki.
47 lines
2.3 KiB
Markdown
47 lines
2.3 KiB
Markdown
---
|
|
type: decision
|
|
tags: [parking, decision, devices, transport]
|
|
sources: []
|
|
updated: 2026-06-15
|
|
status: settled
|
|
---
|
|
|
|
# Transport for the Relay Controller: HTTP/UDP now, MQTT parked
|
|
|
|
**Decision (2026-06-15): use direct HTTP + UDP for the [[dingtian-relay]] controller now. MQTT is
|
|
deliberately skipped, but kept on the radar** for when the system scales.
|
|
|
|
## Options the device supports
|
|
|
|
The Dingtian relay board speaks several protocols: Dingtian string (UDP/TCP), Dingtian binary
|
|
(UDP, optional multicast/password), **HTTP CGI**, **HTTP input-link push** (`input_link_url`),
|
|
**Modbus** (RTU/TCP/ASCII), and **MQTT**.
|
|
|
|
## Why not MQTT (yet)
|
|
|
|
- **A broker is new infrastructure** on a deliberately **single-purpose hardened appliance**
|
|
([[disk-os-hardening]]) — another service to install, secure, supervise, and keep alive.
|
|
- **Extra failure mode on the critical path.** Today host→UDP→relay. MQTT inserts a broker on both
|
|
control and event paths; if it stalls, the lane stalls — and there are 3 processes to debug, not 2.
|
|
- **Doesn't fit [[offline-first]] for this scale.** MQTT earns its keep with *many* devices/consumers
|
|
and intermittent links. Here it's **one host + a few devices on one isolated LAN, metres apart** —
|
|
request/response control + a single input event, no fleet.
|
|
- **The device's MQTT input publish is periodic** ("default every 30 s"), so it's not even a clean
|
|
on-press event without relying on unverified on-change behaviour.
|
|
|
|
## Why HTTP/UDP fits
|
|
|
|
- **Relay control:** direct **UDP string protocol** (port 60001) — `11`=relay1 on, `21`=off,
|
|
`T1`=toggle, `11*`=jog/pulse. No deps, no broker.
|
|
- **Input/button events:** the device's **`input_link_url`** can **HTTP POST to the host backend
|
|
when an input fires** — real push, device calls our existing Fastify server directly, no broker.
|
|
(Polling `00` status over UDP every ~50 ms is the self-contained fallback.)
|
|
- Fewest moving parts; matches the local same-origin model already in use.
|
|
|
|
## When to revisit MQTT
|
|
|
|
If the system grows to **many lanes / many controllers**, or multiple subsystems (LPR, payment,
|
|
signage) all need to share events, a broker becomes a worthwhile central event bus. That aligns
|
|
with the [[autonomous-direction|unmanned]] roadmap at multi-lane scale — re-evaluate then. Until
|
|
then, direct HTTP/UDP wins on simplicity and reliability.
|