fix(reader): correct the QR reader's identity — Dingtian DT-008, not "GEE"
An early wrong assumption named the QR/RFID access reader "GEE" / "GEE/Fondvision" / "GEE-QR-ER80" (and summarized a raw GEE PDF as its datasheet). There is no GEE device — it's the Dingtian DT-008 (dingtian-tech.com/en_us/qr_code_reader.html), the same vendor as the relay board, which is why it integrates the identical HTTP-GET-push way. Code: - Driver symbol geeQrReaderDriver → dingtianQrReaderDriver; label → "Dingtian DT-008 QR/RFID reader (HTTP push)"; comments/description rewritten to the real DT-008 facts (Wiegand 26/34, TCP/IP, USB, RS485 — not RS-232; QR/barcode + ID/IC/NFC — not DataMatrix/1D). - Persisted driverId "gee-qr-reader" → "dingtian-qr-reader" (the registry lookup key + the row created on assign in qr-reader.ts). - Migration 0015 rewrites existing devices.driver_id rows so configured readers keep resolving (applied to the dev DB — 2 rows; the booth applies it on boot). Behaviour is unchanged: naming + the persisted id only. Wiki + memory: - Renamed entities/gee-qr-er80.md → dingtian-dt008-reader.md and sources/gee-qr-er80.md → dingtian-dt008.md; rewrote both to the real DT-008 product-page specs while KEEPING all the verified-on-hardware protocol facts (cjihao serial, .jsp path, Connection: close). Fixed every cross-reference + "GEE" mention in 6 other pages. Memory gee-reader-serial-binding → dingtian-reader-serial-binding. The only surviving "GEE" mentions are deliberate naming-correction notes, the raw PDF filename, and the append-only log history. Full workspace build/lint/test green; dev DB readers verified resolving to the registered dingtian-qr-reader driver. Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V
This commit is contained in:
@@ -1,27 +1,34 @@
|
||||
---
|
||||
type: entity
|
||||
tags: [parking, hardware, readers, qr]
|
||||
sources: [gee-qr-er80]
|
||||
updated: 2026-06-16
|
||||
tags: [parking, hardware, readers, qr, dingtian]
|
||||
sources: [dingtian-dt008]
|
||||
updated: 2026-06-28
|
||||
status: open
|
||||
---
|
||||
|
||||
# GEE-QR-ER80 (QR access reader)
|
||||
# Dingtian DT-008 (QR/RFID access reader)
|
||||
|
||||
The project's **QR-code reader** (GEE NFC LIMITED). A static optical scanner for **QR /
|
||||
DataMatrix / 1D barcode**, optional ID/IC card. This is the **[[ticket-encoding|QR ticket]]
|
||||
scanner** the design called for — read at the pay station and exit lane — and a path for **QR
|
||||
[[subscription]]** credentials. On hand: variant **`-Q-W`** (QR scanner; Wiegand/RS-232/RS-485).
|
||||
(See [[gee-qr-er80|datasheet summary]] / `raw/`.)
|
||||
The project's **QR / barcode / RFID reader** — Dingtian **DT-008**, the **same vendor as the
|
||||
[[dingtian-relay|relay board]]** (which is why it integrates the same HTTP-push way). A static
|
||||
optical + card scanner for **QR / barcode (simple)** and **ID/IC/NFC cards**. This is the
|
||||
**[[ticket-encoding|QR ticket]]** scanner (read at the pay station / exit lane) and a path for **QR
|
||||
or RFID [[subscription]]** credentials. Product page: dingtian-tech.com/en_us/qr_code_reader.html.
|
||||
(See [[dingtian-dt008|spec summary]] / `raw/`.)
|
||||
|
||||
## What it is (and isn't)
|
||||
> **Naming correction (2026-06-28).** Through most of this project this reader was wrongly called
|
||||
> **"GEE" / "GEE/Fondvision" / "GEE-QR-ER80"** — a bad early assumption. There is no GEE device; it
|
||||
> is the **Dingtian DT-008**. The driver id was renamed `gee-qr-reader` → `dingtian-qr-reader`
|
||||
> (migration 0015 rewrites existing rows). All *protocol/behaviour* facts below were observed on the
|
||||
> real hardware and remain correct — only the device identity was wrong.
|
||||
|
||||
- **Optical, not RFID-prox.** Earlier we *assumed* "ER80-EM" = a 125 kHz EM4100 card reader — the
|
||||
datasheet corrects that: it's a **QR/barcode scanner**. The `-EM` in the original label was a
|
||||
mis-id; the real model is **GEE-QR-ER80**. Optional `D`/`C` variants add ID/IC card, but the unit
|
||||
on hand is **QR-only** (`-Q`).
|
||||
- **Multi-interface** (Wiegand 26/34, RS-232, RS-485, USB, TCP/IP); the `-W` variant exposes
|
||||
**Wiegand + RS-232/RS-485**.
|
||||
## What it is
|
||||
|
||||
- **QR/barcode + card.** Reads **QR / simple barcode** AND **ID/IC/NFC cards** (~0.2 s, 0–10 cm).
|
||||
(An earlier note guessed "ER80-EM = 125 kHz EM4100 prox" — that was part of the same mis-id.)
|
||||
- **Interfaces: Wiegand 26/34, TCP/IP, USB, RS485.** (NOT RS-232 — that was a fictional-datasheet
|
||||
claim.) For our integration it talks **HTTP over TCP/IP**; Wiegand is the reader's *output line*
|
||||
on a valid read, not the host transport.
|
||||
- **Power** 9–16 V DC, 800 mA; **86×86×42 mm**; −30…70 °C. Fits the [[disk-os-hardening|appliance]].
|
||||
|
||||
## How it integrates — HTTP-GET push, server replies the verdict (confirmed via SDK)
|
||||
|
||||
@@ -48,7 +55,7 @@ barrier. ([[device-input-flow]] is the analogous push pattern; this one also ret
|
||||
- Pushes over plain **HTTP** to our `10.0.10.x` host (on the device subnet); no serial wiring, no
|
||||
Wiegand-decode hardware. Suits the host-in-the-loop model; autonomy is moot anyway
|
||||
([[dingtian-relay]] has no onboard ACL).
|
||||
- **Linux-supported**, 4–15 VDC, default IP `192.168.1.99` — fits the [[disk-os-hardening|appliance]].
|
||||
- Default IP `192.168.1.99` (set its server IP/port to this host in the vendor tool).
|
||||
|
||||
## Resolved (2026-06-16)
|
||||
|
||||
@@ -93,18 +100,18 @@ from 10.0.10.7 (referer: http://www.fondvision.com — the OEM is Fondvision)
|
||||
|
||||
## Assignment (as-built 2026-06-16)
|
||||
|
||||
A dedicated **`gee-qr-reader`** driver ([[device-registry]], reader category) models the push reader:
|
||||
A dedicated **`dingtian-qr-reader`** driver ([[device-registry]], reader category) models the push reader:
|
||||
its one config field is **`serial`** (the `cjihao` the device reports). The admin assigns it in the
|
||||
[[first-run-setup|setup wizard]] like any device (normal UUID row id), enters the serial, and binds
|
||||
it to a controller relay. The QR endpoint resolves the reader by **matching `config.serial` to the
|
||||
scan's `cjihao`** — not by row id — so no DB hand-editing. Set the reader's server IP/port to this
|
||||
host in the **vendor tool**; assign + enter its serial + bind it here.
|
||||
|
||||
- Verified via inject: assign `gee-qr-reader` {serial:"H05M2AFA"} bound to an access relay →
|
||||
- Verified via inject: assign `dingtian-qr-reader` {serial:"H05M2AFA"} bound to an access relay →
|
||||
a `.jsp` scan with that serial + a matching permit QR → `status:1` (2-beep accept) + open; re-scan
|
||||
→ permit exit; unknown card → `status:0`; unassigned serial → `status:0` (no relay, graceful).
|
||||
- Note `tcpip-reader` is the WRONG model for this device (host-connects-out, a stub) — use
|
||||
`gee-qr-reader`.
|
||||
`dingtian-qr-reader`.
|
||||
|
||||
## Open / next
|
||||
|
||||
@@ -237,7 +237,7 @@ LPR/ANPR plate identity** (the plate binding below):
|
||||
(a chosen value could be guessable or collide). The UI sends a blank QR credential; the server
|
||||
mints the value and returns it (so the UI can print it). **An RF credential, by contrast, carries
|
||||
the physical card id, so it is operator-entered.**
|
||||
- **Reader output = TCP/IP full string** (decided 2026-06-18, the [[gee-qr-er80|host-in-the-loop
|
||||
- **Reader output = TCP/IP full string** (decided 2026-06-18, the [[dingtian-dt008-reader|host-in-the-loop
|
||||
QR reader]] path): the reader delivers the whole decoded string, so the code length is free
|
||||
(unguessable token). *If a site ever wires the reader as **Wiegand 26/34** instead, a scanned
|
||||
QR truncates to a 24-/32-bit number — the generated code would then have to be a numeric id in
|
||||
@@ -255,7 +255,7 @@ LPR/ANPR plate identity** (the plate binding below):
|
||||
- **RF tag / chip / card — selectable later, NOT live yet.** An RFID/proximity credential, read
|
||||
**host-side** (reader → host → `pulseOpen`). **LIVE since 2026-06-18** — the operator selects RFID
|
||||
and **reads the card off a physical reader** (see "Enrolling a card" below) rather than typing the
|
||||
number. The GEE readers are combo QR + RFID (ID/IC/NFC), so the same device captures both. A
|
||||
number. The Dingtian DT-008 readers are combo QR + RFID (ID/IC/NFC), so the same device captures both. A
|
||||
Wiegand-out reader keeps a future autonomous path open ([[entry-exit-readers]]); the
|
||||
[[dingtian-relay]] has no onboard card list.
|
||||
- **Plate (LPR/ANPR) — matching is BUILT, the live SOURCE is the one missing wire.** When plate-bound
|
||||
@@ -296,7 +296,7 @@ traffic, so capture must **borrow one reader briefly without blocking the other*
|
||||
A subscription is a one-to-many aggregate: it may hold **several credentials at once** — e.g. a QR
|
||||
**and** an RFID card (and later NFC). Each is its own `subscription_credentials` row; any of them
|
||||
resolves the same subscription at the barrier. (NFC works today as an `rf` credential on the combo
|
||||
GEE reader; a distinct `nfc` `kind` is a small future labelling-only addition.)
|
||||
Dingtian DT-008 reader; a distinct `nfc` `kind` is a small future labelling-only addition.)
|
||||
|
||||
Crucially, **entry and exit are NOT bound to the same credential.** Originally the session was keyed
|
||||
by the exact credential value read, so you had to leave with whatever you arrived with — an
|
||||
|
||||
Reference in New Issue
Block a user