Which variant does the kit run?

The base 2.4 GHz Wi-Fi build, which declares a receipt printer and a cash drawer. That is the variant the setup and troubleshooting pages assume.

Can I buy the camera or dual-band boards?

Not today. They exist as firmware variants with real endpoint behaviour, and they are documented here so integrators can see the range and its limits, but the shop sells the kit. Nothing on this page is a purchase commitment.

What happens if I flash the wrong variant?

Usually nothing visible, which is the danger. The node boots, serves its API and confirms itself healthy while quietly declaring the wrong set of endpoints — so a scanner is enumerated, decoded and discarded uncounted. That is why the upload path compares the variant before it opens a socket for the image.

Does a scanner work on the base build?

It binds, and its reads have nowhere to go, because that variant declares no scanner endpoint. Peripherals beyond a printer and drawer need a variant that declares them.

Is the RS-232 variant coming?

It is in development and there is no date. What exists today is an endpoint table, a mirror of it in the digital twin and a conformance assertion — no build of it has ever existed, and there is no scale binding for it either. It is listed here rather than hidden, and it is not something to plan against.

Hardware Variants: the Six Declared SKUs

Six firmware variants exist and they are not interchangeable. What each one declares, what a wrong image silently costs, and which of them are buildable at all.

Published 2026-09-09 · All documentation →

Six hardware variants are declared, and they are not interchangeable. The variant is a compile-time switch that decides which peripheral endpoints a node advertises — so an image built for the wrong one is silently destructive: the device is still enumerated and still decoded, and its reads are thrown away with nothing anywhere saying so. This page is what each one declares and what a wrong image costs.

Declared is not shipping

A variant existing in the firmware means an endpoint table exists, not that hardware exists, not that it is buildable, and not that it is for sale. The one thing sold today is the Proxy Node Kit, which runs the base 2.4 GHz Wi-Fi build. Everything else on this page is here so an integrator can see the shape of the range and read the honest state of each row.

The six

SKU	What it assumes	What it declares	What a wrong image costs
`wifi`	USB host, USB-C power. The front counter, and the base build	Receipt printer and cash drawer	On a hub board, the scanner and scale are enumerated and then discarded
`station-hub`	USB-C power, a USB hub, three ports. Bar and takeout	Printer, drawer, scanner, scale	On a `wifi` board nothing breaks — the extra endpoints never bind. This is the harmless direction
`poe-ethernet`	USB host, wired Ethernet with magnetics. The kitchen line	The same pair as `wifi`	Endpoint behaviour identical to `wifi`, so a swap between the two is invisible on the wire. It still stamps the wrong SKU into the image, which is what the cross-flash guard reads
`sense-camera`	A camera-equipped board with an OV3660 sensor and no USB host at all	A camera, and nothing else	On any other board the node declares a camera that is not wired. On this board a non-camera image declares nothing at all. Those two states need different fixes, which is why they read differently
`wifi-c5`	Different silicon: dual-band 2.4 and 5 GHz radio, and no USB host	Nothing — it declares no peripheral endpoints	It is the only variant that can be true on that chip. On the usual silicon it would declare no peripherals at all, so a printer physically bound to the node would have no endpoint to address
`serial`	RS-232 rather than USB. The host stand	A scale over a serial line	In development. No build of this variant has ever existed on any branch, and there is no scale binding for it either. Do not plan against it

Five of the six are buildable. Four of those five are compiled on every pull request; the wired-Ethernet variant is deliberately not one of them, because its endpoint behaviour is identical to the base build and compiling it answers nothing the base row has already answered. That is a judgement about coverage, and it is written down as a named allowance in the contract checks rather than left as a silence — an omission nothing can see needs a mechanism, not a resolution.

What the variant actually changes

One table, and everything downstream follows from it:

The node’s identity, status and config all report which variant they are.
The node’s own web page builds one card and one tab per declared endpoint. A peripheral the variant does not declare has no card, which looks exactly like a peripheral nobody plugged in.
The channel budget uses the variant to decide which peripheral loses a USB channel when the bus runs out.
The scan and weight paths return nothing on a variant that declares no such endpoint, and reads are dropped.

That last point is the whole failure mode. The driver still binds the device. The classifier still identifies it. The decode still runs. The result has nowhere to go.

When the bus runs out

A hub variant declares more peripherals than the controller has channels for — nine things competing for eight. That is not an oversight, it is a budget, and it is resolved by a stated priority rather than by whichever device enumerated first.

Flowchart of USB channel allocation: what spends a channel, why an external hub is never announced and has to be reconciled, which peripheral is evicted when the bus runs out, which one is never the operator's to unplug, and how a refused peripheral is re-offered when the bus gains room. — Which peripheral loses when the bus runs out, and why a refused one is re-offered rather than forgotten. A peripheral refused for want of a channel is a distinct state in the status response from one that was never plugged in — the fix is different, so the answer is different.

The camera variant, and its one hard limit

A camera-equipped board joins the fleet like any other node, advertises a camera peripheral, and serves JPEG frames and a stream over the same LAN API.

No image leaves the node

Nothing reads a number out of a picture, calls a vision model, or uploads a frame — and that is deliberate rather than unfinished. A frame at the wrong orientation yields a plausible wrong number: on our bench a reading of 99.120 came back as 88.150. A wrong answer that looks right is the one failure mode this product is built to refuse, so there is no vision and no character recognition here, and none is promised.

Two details that catch people out on that board: the sensor is an OV3660, not the part its listing implies; and the orientation is a pair of fields read as one statement, so setting a rotation without also stating the mirror clears the mirror silently. Send both.

The dual-band variant, and what "auto" does not mean

5 GHz is real on that silicon, and auto does not mean "prefers 5 GHz". Selection is by signal, and on our measurements it chose 2.4 GHz in nineteen joins out of twenty. The shipped default is still auto. Nothing on this site will tell you the node picks the 5 GHz band, because on the evidence it usually does not.

That variant also has no USB host at all — the chip has none — so it declares no peripheral endpoints. It is a network node, not a peripheral node.

Wired Ethernet, and the part that has not shipped

The Ethernet link is proven: a wired interface came up at 100 Mbit full duplex on its first boot, a cabled node stayed out of setup mode entirely, the .local name resolved over the wire alone, and failover measured 2.9 seconds cable-out to radio and 2.0 seconds back.

Power over Ethernet is a different claim and it is in development. Nothing here has ever been powered over the cable. Where you see "Ethernet" on this site it means the link; if you need power over the same cable, that part is still being built.

Which one is in your hand

Ask the node — its identity response names its variant, and so does its own web page. The variant string is also what the firmware cross-flash guard reads, which is why an upload built for another variant is refused rather than accepted: an image for the wrong SKU boots, serves HTTP, confirms itself, and is wrong, and rollback cannot help because the image is healthy. If you genuinely mean to change a node’s variant, the upload takes an explicit override header — see the error vocabulary for the refusal you will hit without it.

Frequently asked questions

Which variant does the kit run?: The base 2.4 GHz Wi-Fi build, which declares a receipt printer and a cash drawer. That is the variant the setup and troubleshooting pages assume.
Can I buy the camera or dual-band boards?: Not today. They exist as firmware variants with real endpoint behaviour, and they are documented here so integrators can see the range and its limits, but the shop sells the kit. Nothing on this page is a purchase commitment.
What happens if I flash the wrong variant?: Usually nothing visible, which is the danger. The node boots, serves its API and confirms itself healthy while quietly declaring the wrong set of endpoints — so a scanner is enumerated, decoded and discarded uncounted. That is why the upload path compares the variant before it opens a socket for the image.
Does a scanner work on the base build?: It binds, and its reads have nowhere to go, because that variant declares no scanner endpoint. Peripherals beyond a printer and drawer need a variant that declares them.
Is the RS-232 variant coming?: It is in development and there is no date. What exists today is an endpoint table, a mirror of it in the digital twin and a conformance assertion — no build of it has ever existed, and there is no scale binding for it either. It is listed here rather than hidden, and it is not something to plan against.