mca/parking_solution
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 10 Wiki Activity

Remove UHPPOTE/ZKTeco; Dingtian is the only access driver

Browse Source 
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.
This commit is contained in:
Julian Çuni
2026-06-14 14:28:52 +02:00
parent 1b55e2034d
commit 355026dcf7
26 changed files with 106 additions and 711 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/concepts/device-discovery.md
+12 -6
View File
@@ -20,17 +20,23 @@ device carries an `id`, a `label`, a `config` blob to **auto-fill** the setup fo
(firmware, MAC, …). The [[device-registry]]'s `isDiscoverable()` guard lets the system treat it
as optional; the setup catalog returns a `discoverable` list of driver ids.
## UHPPOTE discovery
> **No current driver implements discovery.** The [[dingtian-relay]] board uses a fixed IP
> (entered/known at setup). The capability remains for future UDP-discoverable devices (cameras
> via ONVIF, etc.). The worked example below is the (removed) UHPPOTE driver — kept because the
> **broadcast gotchas are transferable** to any UDP discovery we add later.
The [[uhppote-controller]] supports discovery natively: a **UDP broadcast** (`get-devices` on
## UHPPOTE discovery (historical example)
The [[uhppote-controller]] supported discovery natively: a **UDP broadcast** (`get-devices` on
port `60000`) that **every controller on the LAN answers** with its serial, IP, netmask, gateway,
MAC, firmware version, and date. The official `uhppoted` lib exposes this as `getDevices(ctx)`;
the `uhppote` driver maps each result into a `DiscoveredDevice` (serial → id, IP → host).
**Verified on real hardware** (serial 225088491).
MAC, firmware version, and date. The `uhppoted` lib exposed this as `getDevices(ctx)`; the
(now-removed) `uhppote` driver mapped each result into a `DiscoveredDevice` (serial → id, IP →
host). **Was verified on real hardware** (serial 225088491).
### Broadcast gotchas (learned the hard way — see [[wsl-dev-networking]])
These cost real debugging time; the `uhppote` driver now handles all three:
These cost real debugging time; the (removed) `uhppote` driver handled all three, and any future
UDP-discovery driver will need to as well:
1. **Broadcast to the *subnet-directed* address, not the global `255.255.255.255`.** The
`uhppoted` lib only calls `setBroadcast(true)` when the target matches a **local interface's