The simulator
Test receipt printing without a printer.
Test receipt jobs, status handling and paper-out failures against a local network service. The simulator requires evaluation workspace access; there is no public download. It covers the core HTTP and raw :9100 print paths. Rejected scans, /bootlog, /network, /compose and API-key gating still need real hardware.
Why it exists
Printers are the worst test dependency in POS software.
You can't run a thermal printer in CI. So printing gets tested by hand, on one office printer, on the happy path — and the failure modes ship to production.
The failure paths are the product
Paper out mid-ticket, cover open, drawer stuck, printer offline. Customers hit these daily; test suites almost never do.
Existing emulators stop at bytes
A renderer helps check receipt layout. To test status handling, choose a tool that also answers DLE EOT queries and can inject paper-out, cover-open and network faults.
A twin, not a mock
Because the twin speaks the real wire protocols on a real socket, the code you test is the code you ship — HTTP client, :9100 stream, status polling — for the core surface it implements.
What it does
A bad day at the restaurant, on demand.
Start the twin, drive it like a node, then break things from the REPL and watch your software cope — or not.
Drive it
$ pnpm sim Proxy Nodes simulator — digital twin (local-first, no broker) device : pn-sim-01 (station-hub) http : http://localhost:8080 (POST /print, GET /status, GET /events) :9100 : raw ESC/POS on tcp/9100 mdns : _proxynodes._tcp as proxynodes-pn-sim-01.local peers : beacon on udp/9110 (GET /peers) $ pnpm discover # find it like a real node $ pnpm print # receipt renders in the console $ pnpm watch # live telemetry over SSE $ pnpm conformance # full protocol conformance suite
Break it
sim> paper out # POS should surface a real error sim> cover open sim> offline # what does your retry logic do? sim> drawer # drawer state flips in /status sim> weight 1.25 # virtual scale sim> scan 012345 # virtual barcode scanner
And prove it
All 146 conformance specs run identically against the twin and a physical node. Protocol checks are unconditional; physical-effect checks skip with a printed reason when hardware isn't attached — never a silent pass. If your integration passes against the twin, the same command verifies it against the real device on your bench: pnpm conformance 192.168.1.42.
Availability
Plan your integration.
Read the API docs now, or ask about access to the development tools. The 146 conformance specs target the twin and real hardware; skipped physical checks are reported separately.