julian
bf37106c5c
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).
3.2 KiB
type, tags, sources, updated, status
| type | tags | sources | updated | status | |||||
|---|---|---|---|---|---|---|---|---|---|
| entity |
|
|
2026-06-16 | 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
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 / 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
-EMin the original label was a mis-id; the real model is GEE-QR-ER80. OptionalD/Cvariants 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
-Wvariant 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'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.
Open questions (block the adapter)
- 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.
- Serial vs. USB-CDC vs. TCP/IP for this unit:
-Wis Wiegand/RS-232/485. Decide the host wiring (a USB-RS232/485 adapter on TX/RX, most likely). - 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.