mca/parking_solution
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 10 Wiki Activity

qr-reader: gee-qr-reader driver — assign in wizard, resolve lane by serial

Browse Source 
The QR reader is a push device and the setup wizard assigns random-UUID ids, so
'id = serial' can't be set via the UI. Add a dedicated gee-qr-reader driver
(reader category) with a single 'serial' config field; the admin assigns it
normally and enters the device's serial (its cjihao).

The QR endpoint now resolves the lane by matching lane_devices.config.serial to
the scan's cjihao (instead of row id == cjihao), so no DB hand-editing. An
unassigned serial resolves to no lane -> status:0, gracefully.

Verified via inject through the real /api/setup/assign: assign {serial:
H05M2AFA} -> .jsp scan with a matching permit QR -> status:1 (accept) + open;
re-scan -> permit exit; unknown card -> status:0; unassigned serial -> status:0.
This commit is contained in:
Julian Çuni
2026-06-16 12:36:58 +02:00
parent 04135b27cf
commit 68d61f2d99
7 changed files with 85 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/entities/gee-qr-er80.md
+19 -5
View File
@@ -90,10 +90,24 @@ from 10.0.10.7 (referer: http://www.fondvision.com — the OEM is Fondvision)
- The reader **beeped on the vendor reply with `status:0`** — so it acts on the reply; `0` =
invalid/1-beep as documented. A matching permit/session will return `status:1` → 2-beep accept.
## Assignment (as-built 2026-06-16)
A dedicated **`gee-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) and enters the serial. The QR
endpoint resolves the lane 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 here.
- Verified via inject: assign `gee-qr-reader` {serial:"H05M2AFA"} on a lane w/ an access device →
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 lane, graceful).
- Note `tcpip-reader` is the WRONG model for this device (host-connects-out, a stub) — use
`gee-qr-reader`.
## Open / next
- **Assign the reader** as `lane_devices.id = "H05M2AFA"`, category `reader`, on the same lane as an
access device, so the endpoint resolves the lane. (The setup wizard doesn't yet capture a reader's
serial as its id — manual row or a wizard tweak; see [[first-run-setup]].)
- Re-test against the real app endpoint (now `.jsp`-aware): scan → expect the GET to hit
`/qa/mcardsea.jsp` and a `status:1` 2-beep when the credential matches a permit/open session.
- Re-test on hardware against the real app (now `.jsp`-aware + serial-resolved): scan → expect a
`status:1` 2-beep when the QR matches a permit/open session.
- `output` is replied as `0` (Access). Confirm on hardware whether the reader needs `1`/`2` (WG26/34)
to drive its access line, vs. `0`.