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.0 KiB
2.0 KiB
type, tags, sources, updated
| type | tags | sources | updated | ||||||
|---|---|---|---|---|---|---|---|---|---|
| entity |
|
|
2026-06-15 |
ZKTeco Controller (rejected — historical)
❌ NOT USED. Was considered as the access controller; the dingtian-relay board was chosen instead (decoupled inputs, already verified). The
zktecodriver stub has been removed from the codebase. Kept for the record of the comparison below.
A network access controller (C3 / inBio families), originally the documented "UHPPOTE now → ZKTeco later" upgrade in the bom.
Why it was a contender (vs. UHPPOTE)
ZKTeco is better positioned than the uhppote-controller for host-in-the-loop entry (the access-controller-button-flow blocker) — but it was never verified on our hardware, and the Dingtian solved the problem first with less effort:
- Its auxiliary inputs have programmable linkage (ZKBioSecurity software / PULL SDK) and
are not hardwired to "open door" — so a button on an aux input can raise a host event
without auto-opening, enabling
button → host → print ticket → host opens. - The PULL SDK streams real-time events (
GetRTLog) and has an explicit open command (ControlDeviceOutput). - Caveat: a button on the door's exit-switch input still auto-opens (same as UHPPOTE) — only the aux-input path avoids it.
Driver status
- ZKTeco speaks its own PULL SDK / TCP protocol — not the UHPPOTE UDP protocol, so the
uhppotedlib does not work with it. - No verified MIT/Apache/BSD Node library found. Mature open implementations are Python
(
zkaccess-c3-py,pyzkaccess). Adopting ZKTeco means writing a new driver for the registry (device-adapter-pattern) — real protocol work.
Reference
- ZKTeco SDK / PULL SDK: https://www.zkteco.com/en/SDK
zkaccess-c3-py: https://github.com/vwout/zkaccess-c3-pypyzkaccess: https://github.com/bdragon300/pyzkaccess
See access-controller-button-flow for the full blocker context.