The seam for a separate label app to own LAYOUTS while this daemon stays the
single owner of the hardware. Takes a base64 PNG at media pixel size plus
sku/releaseId, and runs the identical guarded sequence: read, UHF WRITE, verify,
SET RFID OFF, geometry, print. A failed encode still spends no label.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
We encode and verify the chip ourselves before PRINT, so the print job carries no
RFID data. With the firmware's own encoding armed it treats that as a failed
encode and VOIDs the label -- 'VOID VOID VOID' overprinted across the bottom
third, on top of the info line and the QR. Seen on the bench.
SET RFID OFF between our verify and the print stops it. Proven live that it is
free: UHF READ and UHF WRITE both keep working with the firmware pass off, and
the module read the next blank straight after the print. So it is never
re-armed -- no SET RFID 1, no &DEFAULT, no &CALIBRATE, all of which have wedged
the module today.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every print-encode today failed its read-back with 'before: null' while a
standalone /read-tag a second earlier read the chip every time, at the same
media position. Bisected to the pre-read sequence itself: after the
SIZE/GAP/TEAR/DIRECTION/CLS burst, UHF READ and QUERY return no bytes at all
until a power-cycle. SET RIBBON OFF + FORMFEED provably do not do this.
UHF WRITE commits immediately and needs no geometry, and printing works after
geometry (print-test proved it), so read/write/verify now happen first on the
untouched module and the print setup follows. Nothing feeds between, so the
label at the antenna is the one printed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adding set_rfid(tag_type=1) ahead of the read-back seemed like cheap insurance
and was the opposite. On this firmware a SET RFID sent while the UHF module is
already active left it answering NOTHING -- READ and QUERY returned no bytes at
all under every tag type, while model()/status() kept working -- and that state
survived every software command tried. It presents exactly like a media
alignment fault ("before: null", chip apparently never in the window) on a
roll whose inlay fills the label. The printer arms RFID itself at power-up.
Leave it. set_rfid()'s default is corrected to 1 (0 is OFF) for any caller that
does use it deliberately.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Four devices, two daemons, one front door. This service drives the Urovo D812R+
and the Dymo LabelWriter over raw USB; the Node rfid-daemon on 7790 drives the
Chafon H102 gun and the Dymo M25 scale, and is what the PriceGod extension is
pointed at. Both were binding 7790.
The port was not the whole problem. /status, /read-tag, /write-tag and /recover
exist on BOTH services and mean different things — the gun in your hand versus
the antenna inside the printer. Merging them into one flat namespace would let a
"read-tag" land on whichever daemon answered, which is how you get a tag written
by the wrong device. So this keeps its own names and the Node side proxies
/printer/* here, leaving the extension with a single endpoint on 7790.
They stay separate processes on purpose: this side needs libusb for a real
bidirectional pipe (UHF READ replies as raw bytes on the bulk-IN endpoint, which
is why CUPS 'lp -o raw' cannot drive it) and the other needs node-serialport and
node-hid. Merging would mean porting one language's device stack to the other
for no gain.
--port still wins, UROVO_PORT overrides the default, and neither the launchd
plist nor start-daemon.command pins a port, so install.sh needed no change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two bugs found on the bench, both from wrong assumptions about the LW450:
1. Orientation. I assumed the 57mm head meant the label feeds landscape. It
doesn't -- the Dymo takes the SAME 24mm narrow-edge-first stock as the Urovo,
so the landscape design needs the identical 90-degree rotation. Rendering
656 dots onto a ~288-dot label also silently clipped the price and QR off the
right-hand edge. Now rotates by default, overridable per request via "rotate",
and the daemon rejects an image wider than the head instead of clipping it.
2. Half-length labels. print_image() sent ESC i (300x600 Barcode/Graphics mode),
where the head stays 300 dpi across but each raster line becomes 1/600" in the
travel direction -- so a 650-line label printed at 27.5mm instead of 55mm, with
the across-head dimension correct. Default is now ESC h (300x300), matching our
square 300 dpi bitmap. graphics_mode=True remains available and now stretches
the image 2x vertically so physical size stays correct.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Answers "can we direct print to the Dymo via CUPS, or is it the cmd-P dance?":
neither. The LW450 (0922:0020) is a bidirectional USB printer-class device just
like the Urovo, so its raster protocol goes straight to the bulk endpoint -- no
DYMO driver, no CUPS queue, no print dialog. Command set taken from DYMO's own
LabelWriter 450 Series Technical Reference Manual and documented in dymo.py.
Verified on the bench: revision 1750111r53, status 0x03 Ready, 283 raster lines
at 82 bytes/line accepted.
Also corrects an assumption inherited from daemon.cs: UHF WRITE commits
immediately and does NOT wait for PRINT. Confirmed by writing a chip and reading
it back with no PRINT sent. Two consequences:
- the Urovo can program a chip without printing or consuming a label, which is
what makes the Urovo-encodes/Dymo-prints split work at all;
- an encode can be verified BEFORE printing, so a failed write never costs a
label. /print-encode and /encode both do this now.
New routes: /devices (all three devices at a glance), /encode (chip only),
/print-paper (Dymo), /tag-and-print (Mode A in one call).
label.py is now resolution-aware (203 dpi Urovo / 300 dpi Dymo via profile(dpmm=))
and orientation-aware: the Urovo's 24mm web feeds narrow-edge-first so the design
rotates 90 degrees, while the Dymo's 57mm head is wider than the label so the same
design feeds landscape unrotated.
Also fixes tag read parsing: with dataFormat 'H' the printer replies in ASCII hex
TEXT, not raw bytes -- the old code hex-encoded it a second time. flush_in() now
drains fully, since a late reply to one command was being attributed to the next
and silently corrupting reads.
KNOWN ISSUE: the Node rfid-daemon (Chafon + scale + inventory) also binds :7790.
Both cannot run at once and this service does not implement its routes. Unresolved.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ASSESSMENT.md §7 assumed the RFID encode was locked inside the Windows-only
GTSPL_SDK.dll and would need a USBPcap sniff or the GTSPL Java jar to recover.
It didn't. The DLL is a managed .NET assembly, and its IL shows every RFID call
is a one-line String.Concat -> ASCII -> WritePrinter. Recovered from ldstr order
plus argument order, and confirmed by a second independent decompile:
UHF WRITE H,2,12,E,"<24 hex>" UHF READ/QUERY ...
UHF GEN2 EPC|TID|USER|ACCESS|KILL <action>,"<pw>"
SET RFID <tagType>,<rw_pos>,<void>,<try>,<err>,<speed>,<retry> (dots, not mm)
&DEFAULT,i &CALIBRATE,A,R PRINT <set>, <copy>
So the whole recipe is plain ASCII over the printer's bulk endpoint and ports to
macOS with no vendor binaries at all.
- mac/urovo.py USB transport + full GTSPL command set, status decoding, the
ribbon-latch recovery, SKU<->EPC packing ported from daemon.cs.
- mac/label.py PIL bitmap renderer -> TSPL BITMAP. Media-profile driven, so both
shop stocks work (small 51x19 and large 55x24 on the 24mm web),
with a safe-area inset so the design can't clip at the edges.
- mac/daemon.py :7790 HTTP service, same routes/JSON/CORS as daemon.cs, plus a
/preview route that renders a label as PNG without printing one.
Verified on the bench from macOS: printer identifies (MODEL:UROVO-D812R), the
latched 0x08 "out of ribbon" clears with SET RIBBON OFF + FORMFEED, and labels
print correctly oriented and dark on the 24x55 stock.
NOT yet verified: the RFID encode itself. It is wired and the printer accepts the
command, but the loaded thermal stock has no inlays so nothing has been written to
a chip. Needs a PET RFID label at the antenna. The SKU<->EPC byte layout also
remains unconfirmed against existing Chafon-written tags.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
