wiki: ingest GEE-QR-ER80 QR access reader datasheet

The reader on hand is a GEE-QR-ER80 QR/DataMatrix/1D barcode access reader
(not an EM4100 prox-card reader as first guessed). Interfaces: Wiegand 26/34,
RS-232, RS-485, USB, TCP/IP; 4-15 VDC; Linux-supported. Variant on hand: -Q-W
(QR scanner, Wiegand/RS-232/485).

This is the QR-ticket scanner the design already needed: a host-side reader
whose scans become read-bus events consumed by the (already-built) exit flow
and QR-permit path. Prefer RS-232/485 over Wiegand (Wiegand can't carry a
variable-length QR string; autonomy is moot with the no-ACL Dingtian).

New source + entity pages; updated ticket-encoding, entry-exit-readers, index.
Open (blocks the adapter): the RS-232/485 frame + baud (ASCII CR/LF expected).

wiki/entities/gee-qr-er80.md

@@ -0,0 +1,59 @@
+---
+type: entity
+tags: [parking, hardware, readers, qr]
+sources: [gee-qr-er80]
+updated: 2026-06-16
+status: open
+---
+
+# GEE-QR-ER80 (QR 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
+[[permit]]** credentials. On hand: variant **`-Q-W`** (QR scanner; Wiegand/RS-232/RS-485).
+(See [[gee-qr-er80|datasheet summary]] / `raw/`.)
+
+## What it is (and isn't)
+
+- **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**.
+
+## How it fits our architecture — host-side reader
+
+It's a **host-side identity source** ([[entry-exit-readers]]): the host sees the scan, decides, and
+commands the relay — exactly the model the read-driven flows already use. A scan becomes a
+`DeviceReadEvent` on the internal `read` bus (`kind: "qr"`/`"ticket"`, value = the scanned string),
+consumed by the **exit flow** and the **QR-permit** path ([[parking-session]], [[permit]]) — both
+**already built**. So integration is a new **`ReaderDevice` adapter**, no business-logic change
+([[device-adapter-pattern]]).
+
+- **Interface choice:** prefer **RS-232/RS-485 (serial)** for the QR variant — Wiegand can't carry a
+  variable-length QR string well (it's built for fixed-width card IDs). The host reads scans over a
+  serial port (USB-serial on TX/RX, or the USB variant); no Wiegand-decode hardware needed. This
+  suits [[offline-first]] (local serial, no network) and sidesteps the [[dingtian-relay|Dingtian]]'s
+  lack of an onboard card list (we never wanted autonomy here anyway).
+- **LED/BEEP control lines** mean the host can drive scan feedback (accepted/rejected) — nice for an
+  unmanned lane.
+- **Linux-supported**, 4–15 VDC — fits the [[disk-os-hardening|appliance]].
+
+## Open questions (block the adapter)
+
+1. **RS-232/RS-485 protocol:** baud rate + frame format, and confirm a QR scan emits as an **ASCII
+   string** (expected) terminated by CR/LF vs. a framed/checksummed protocol. This is the one fact
+   the adapter needs and the datasheet omits. Resolve via vendor docs or by observing the port on a
+   scan.
+2. **Serial vs. USB-CDC vs. TCP/IP** for *this* unit: `-W` is Wiegand/RS-232/485. Decide the host
+   wiring (a USB-RS232/485 adapter on TX/RX, most likely).
+3. **Does Wiegand mode even carry QR?** Likely Wiegand is for the optional *card* modes only; confirm
+   so we don't design a Wiegand path for QR.
+
+## Next
+
+A `ReaderDevice` driver in `packages/devices` (serial transport) emitting `read` events. Add it to
+the [[device-registry]] under the `reader` category so the [[first-run-setup]] wizard can assign it
+per lane. Pending open-question #1 (the serial frame) before coding.