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