julian
355026dcf7
Neither UHPPOTE nor ZKTeco is used — the Dingtian relay controller was chosen and verified. Remove their code and re-scope the wiki. Code: - delete access-uhppote.ts, uhppoted.d.ts, access.ts (zkteco/esp32-relay stubs), and the three uhppote-*.mjs hardware test scripts. - remove the `uhppoted` npm dependency from @parking/devices and @parking/server. - unregister uhppote/zkteco/esp32-relay from the driver registry; drop their exports. Catalog access drivers = dingtian only. Build green (5/5). - refresh now-stale example comments (registry/interfaces/setup/api) to use current examples; keep the two "UHPPOTE blocker" references that explain why the precondition capability exists. Wiki (kept pages, re-scoped): - uhppote-controller, zkteco-controller -> rejected/historical with callouts; uhppote-vs-esp32 -> historical (detection-vs-prevention lens still useful). - re-point all "current device" framing (standing-decisions, bom, overview, open-questions, device-registry, device-discovery, index) to dingtian-relay. - transferable concepts (network-isolation, event-log-ingestion, barrier-not-a- door, threat-model) untouched. Raw source immutable. Links lint clean.
2.2 KiB
2.2 KiB
type, tags, sources, updated
| type | tags | sources | updated | |||||
|---|---|---|---|---|---|---|---|---|
| concept |
|
|
2026-06-14 |
UHPPOTE vs. Custom ESP32 — Detection vs. Prevention
Historical comparison. Neither is the current device — the uhppote-controller was rejected (entry-flow blocker → dingtian-relay chosen) and the esp32-custom-controller is deferred. Kept because the detection-vs-prevention framing on the trust-boundary fork is a durable lens that applies to any access device.
A head-to-head on the trust-boundary fork: the off-the-shelf uhppote-controller versus the esp32-custom-controller. (Synthesized from parking-system-architecture §6–7.)
| uhppote-controller | esp32-custom-controller | |
|---|---|---|
| Trust boundary | The network | The device |
| Security posture | Tamper-evident (detection) | Tamper-proof (prevention) |
| Command auth | None — uhppote-udp-protocol is open UDP | challenge-response-auth (asymmetric sigs) |
| Key mitigation | network-isolation (mandatory) + event-log-ingestion | atecc608 holds non-extractable key; controller stores only a public key |
| Firmware | Manufacturer-only; not customizable | You own it (tiny + auditable) |
| Cost / effort | Cheap, off-the-shelf, available now | Build + firmware reliability, EMC/surge, field maintenance |
| Replay/forgery on the wire | Possible — contained only by isolation | Defeated by fresh per-command nonce |
| Safety | Barrier operator owns it (barrier-not-a-door) | Same + explicit fail-state-safety |
Bottom line
- The UHPPOTE was the detection-grade option: good enough as a detection/audit layer when only the host can reach it (isolation) and every event lands in the append-only-event-chain — but it was rejected for the entry lane (the button blocker).
- The ESP32 is the prevention-grade option when you need a control path that holds even against an attacker on the wire. Deferred.
- Both still rely on host-side integrity (append-only-event-chain) and external reconciliation as the ultimate anti-fraud control.