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.
65 lines
3.4 KiB
Markdown
65 lines
3.4 KiB
Markdown
---
|
||
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 integrates — HTTP-GET push, server replies the verdict (confirmed via SDK)
|
||
|
||
The protocol is settled by the **[[qrcode-sdk|QRCode SDK v1.6.5]]** (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.x` host (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|appliance]].
|
||
|
||
## 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 `output` field), 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.
|