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.1 KiB
type, tags, sources, updated, status
| type | tags | sources | updated | status | |||||
|---|---|---|---|---|---|---|---|---|---|
| concept |
|
2026-06-15 | open |
Ticket Encoding & Scanning
How a transient parking-session's ticket id is printed, carried by the customer, and read back at the pay station and exit. This is the physical backbone of the transient flow — the thing that links entry → pay → exit when there's no plate.
The ticket id is the session key
At entry the system mints a vehicle_entry event with a ticket id (identity) and prints a
ticket the customer keeps. That same id is read back later to find the session. Properties the id
must have:
- Opaque + unguessable — a random id (not a sequential count an attacker could iterate to claim someone else's cheaper session). Sequential physical stock numbering is a separate reconciliation aid (reconciliation pre-numbered stock), not the scan key.
- Single logical session — scanning it at the pay station finds the open session; after payment it's the proof-of-paid the exit checks.
Encoding: QR (preferred) — printed by the booth dispenser
- The rongta-printer prints the ticket id as a 2D barcode (QR) plus human-readable text and entry time. QR over 1D barcode: denser, tolerant of crumpling/partial reads, easy for a cheap camera/imager to read.
- Scan points (both host-side reads — entry-exit-readers):
- Pay station — customer scans the ticket → host finds the session → shows fee → takes
payment (tariff, pay-on-foot) → appends
payment. - Exit lane — customer scans the (now paid) ticket → host validates paid + within
gracePeriodExit→vehicle_exit→pulseOpen.
- Pay station — customer scans the ticket → host finds the session → shows fee → takes
payment (tariff, pay-on-foot) → appends
- The scanner is a device behind an adapter (device-adapter-pattern): a new
ReaderDevicekind (QR/barcode imager) — likely the sameIdentitySource = "ticket"/"qr"path. Keeps the app device-agnostic; hardware model is procurement (bom, open-questions).- On hand: the gee-qr-er80 QR access reader (
-Q-W: QR scanner, Wiegand/RS-232/RS-485, Linux-supported) — the concrete scanner for this path. A serialReaderDeviceadapter feeds thereadbus; pending the reader's RS-232 frame/baud (see gee-qr-er80 open questions).
- On hand: the gee-qr-er80 QR access reader (
Ticketless alternative (plate as the ticket)
Where the opencv-anpr-service/LPR captures the plate, the plate can be the session key instead of a printed ticket — drive in, plate read, drive to pay station and enter plate (or it's looked up), pay, exit by plate. No paper. The two can coexist per lane (entry-exit-readers "both share a relay"); a printed QR ticket is the fallback when a plate isn't captured or is low-confidence (recognition is advisory — opencv-anpr-service).
Open
- QR symbology/error-correction level + what else prints (site name, tariff summary, help number).
- Scanner hardware (imager model; same unit at pay station and exit?).
- Lost/damaged ticket → the lost-ticket path (parking-session, tariff admin-arbitrary amount).