Files

T

julian 4319fb86dc wiki: Dingtian relay decision, HTTP-over-MQTT, unmanned direction

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

2026-06-14 13:27:01 +02:00

2.3 KiB

Raw Blame History

type, tags, sources, updated, status

type

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 roadmap at multi-lane scale — re-evaluate then. Until then, direct HTTP/UDP wins on simplicity and reliability.

2.3 KiB Raw Blame History