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.
46 lines
2.0 KiB
Markdown
46 lines
2.0 KiB
Markdown
---
|
|
type: entity
|
|
tags: [parking, hardware, access-control, rejected, historical]
|
|
sources: [parking-system-architecture]
|
|
updated: 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 `zkteco` driver **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
|
|
`uhppoted` lib 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-py
|
|
- `pyzkaccess`: https://github.com/bdragon300/pyzkaccess
|
|
|
|
See [[access-controller-button-flow]] for the full blocker context.
|