Go to file
type-two d4b16c075b One-command install + launchd agent for deploying to another Mac
Answers "do we have to start the server in terminal?" -- no. install.sh installs
deps and registers a launchd agent with RunAtLoad + KeepAlive, so the daemon
starts at login and comes back if it dies. Verified by killing the process: back
up and serving within seconds under a new pid. Deploying to the M3 Air is then:

    git clone ssh://git@100.71.119.27:222/monster/yourovo.git
    cd yourovo/mac && ./install.sh

Also revises the A/B/C recommendation. Grepping the extension shows it calls only
six endpoints: /status, /write-tag, /read-tag (all served here) plus /weight,
/scale/start, /scale/stop (the DYMO M10 postal scale, Node-only). So the gap to a
single service is the scale and nothing else -- which makes option B (Node on
:7791 with this one proxying) the wrong trade: one URL but two processes, two
dependency stacks and two things to keep alive, against a stated goal of one
button on a second machine.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-22 16:49:21 +10:00
mac One-command install + launchd agent for deploying to another Mac 2026-07-22 16:49:21 +10:00
.gitignore macOS: raw-TSPL Urovo daemon — no vendor SDK needed 2026-07-22 16:07:12 +10:00
ASSESSMENT.md Fix the EPC scheme; verify encode independently with the Chafon 2026-07-22 16:45:07 +10:00
build.cmd Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
chafcheck.cs Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
daemon.cs Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
GTSPL_SDK_C.dll Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
GTSPL_SDK.dll Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
hidapi.dll Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
PROGRESS.md Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
README.md Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
start-daemon.cmd Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
UHFPrimeReader.dll Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
zlib.net.dll Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00

pricegod-urovo-daemon

The Windows counterpart to the Mac rfid-daemon. Instead of a Chafon gun writing a loose chip while a Dymo prints a separate sticker, this drives the Urovo D812R+ (RFID) to print the label AND encode the UHF chip in one pass on the composite (paper+chip) rolls.

It listens on http://localhost:7790/ with CORS *, so it's a drop-in for the PriceGod extension's existing daemon.js client — same port, same JSON shape.

Run it

Double-click start-daemon.cmd (leave the window open while you work). That's it — no Node, no .NET SDK, no gitea clone. It's a self-contained .exe.

To rebuild after editing daemon.cs: double-click build.cmd.

What's inside

  • daemon.cs — the service (C#, .NET Framework 4.x).
  • pricegod-urovo-daemon.exe — the compiled daemon.
  • GTSPL_SDK.dll, GTSPL_SDK_C.dll, zlib.net.dll — the Gainscha/Urovo print SDK (must sit beside the .exe). Copied from the vendor Windows SDK.

The print/encode sequence is a straight port of the proven gtcheck.cs rfidgo path: SET RIBBON OFF → continuous geometry (GAP 0, RFID rolls blind the optical gap sensor) → writeUHF → draw text + QR → printlabel → read-back verify.

Routes

method path body returns
GET /status {ok, ready, status, statusText, printer}
POST /print-encode {sku, releaseId, artist?, title?, price?, condition?, w?, h?, gap?} {ok, sku, releaseId, epc, verified, status}
POST /write-tag alias of /print-encode (the daemon.js name) same
GET /read-tag {ok, epc, sku, releaseId, recognized}
POST /calibrate RFID auto-calibration
POST /recover ribbon-off + one feed to clear a fault

Quick test (PowerShell):

Invoke-RestMethod http://localhost:7790/status

SKU ↔ EPC scheme (⚠ verify)

The 96-bit EPC (12 bytes) is packed as: 6 bytes 14-digit timestamp SKU · 4 bytes release_id · 2 bytes 0xEC01 marker. This lives in the Epc class in daemon.cs and is the only thing that needs to change if it must match a different (Mac/Chafon) layout — nothing else depends on the byte order. Confirm by reading an existing tag: put a Chafon-written record at the antenna and GET /read-tag.

Notes / open items

  • Default label geometry is 65×37 mm, continuous (GAP 0). Adjust to your actual RFID roll via the w/h/gap fields, or change the DEF_* constants.
  • The label layout (text lines + QR) is functional, not yet pixel-matched to the 51×19 Dymo design in the extension's labels.js.
  • The Chafon gun is still needed for reading a loose tag off a shelf — the Urovo can only read/write a tag physically inside the printer.