julian
f67c1ead87
The QRCode SDK v1.6.5 settles the reader protocol (supersedes the earlier
serial guess). On each scan the reader HTTP-GETs the host
(/qa/mcardsea.php?cardid&mjihao&cjihao&status&time); the host replies JSON
{data:[{...,status,output}],code:0}. Reply status 1=valid(beep 2x)/0=invalid
(beep 1x); output 0=Access/1=WG26/2=WG34; time syncs the clock. The GET's status
low digit is the direction (1=in/0=out).
Key: the beep/accept is decided by the SERVER REPLY, not locally -- the 'no
beep' during bring-up was a plain-text reply, not a scan failure. Host-in-the-
loop and synchronous. 'Server language' only selects the URL path; transport is
plain HTTP.
New source page qrcode-sdk; updated gee-qr-er80 (protocol resolved), index.
3.4 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 integrates — HTTP-GET push, server replies the verdict (confirmed via SDK)
The protocol is settled by the qrcode-sdk (not serial as first guessed).
The reader is configured (Windows tool QRCode_v1_6_5.exe) with a server IP/port and a "server
language" (only picks the URL path, e.g. /qa/mcardsea.php). On each scan it HTTP-GETs the host:
GET /qa/mcardsea.php?cardid=<QR>&mjihao=<devId>&cjihao=<devSN>&status=<2 chars>&time=<utc>
cardid = scanned data; status low digit = direction (1=in / 0=out). The host replies JSON
{data:[{cardid,cjihao,mjihao,status,time,output}],code:0} where reply status 1=valid (beep
2×) / 0=invalid (beep 1×), output 0=Access/1=WG26/2=WG34, time syncs the clock.
This is host-in-the-loop and SYNCHRONOUS: the GET is the access query and our reply is the
decision — it drives the reader's beep + output. So unlike a fire-and-forget reader, the endpoint
must decide (valid/invalid, direction from status) and reply, then also emit a DeviceReadEvent
on the read bus for the entry/exit/permit flows (parking-session, permit) to open the
barrier. (device-input-flow is the analogous push pattern; this one also returns a verdict.)
This explains the "no beep": feedback comes from the server's JSON reply, not locally. A non-JSON / missing reply ⇒ no beep even though the scan worked. So "no beep" ≠ "didn't scan."
- Pushes over plain HTTP to our
10.0.10.xhost (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.
Resolved (2026-06-16)
- Protocol = HTTP GET poll + JSON verdict (above). The earlier "serial/Wiegand, find the baud"
open questions are moot — it's HTTP. Wiegand is the reader's output line on a valid read
(the reply
outputfield), not the host transport.
Next
A backend route (like routes/devices.ts for the Dingtian push) that parses the GET, decides
(reuse the permit/exit lookup), replies the JSON verdict, and emits on the read bus. The
device-registry reader entry can model it for first-run-setup (server IP/port are set in
the vendor tool; the app side is the endpoint). Build-ready — protocol fully known.