The phone as scanner: a good compromise, not the end state

The Android scanner works well. Point it at a barcode, tap an NFC tag, and the event fires. For on-demand scanning — at a shop shelf, or doing an occasional inventory sweep — it's entirely adequate.

The limitation shows up in fixed installations. Mounting a phone at a doorway or storage point so it can act as a persistent reader means that phone is occupied. Battery management becomes a consideration. So does the physical reality of holding a phone in place, keeping the screen on, and keeping the app in the foreground. It works, but it's a workaround built on hardware designed for something else.

Dedicated readers remove that friction. They're built for one job, they run continuously, and they don't have a home screen or a notification tray competing for their attention.

Unit one: dual-channel NFC reader

The first unit is an NFC reader with two independent antenna channels.

Each channel is independently configurable — one channel might be set to log an inventory entry while the other triggers a price tracking event. Or one handles item check-in and the other check-out. The physical separation means you can place two distinct interaction points on the same unit: a shelf edge where items are stored has a different read zone from the point where items are picked.

The dual-channel design isn't about scanning faster. It's about scanning differently. A single-channel reader at a storage unit entrance tells you something left or arrived — but not which action the scan represents. Two channels, two intents, no ambiguity.

Visual confirmation is built into the unit. Each scan produces an immediate indicator on the device itself: which channel fired, whether the event was acknowledged by the broker, and whether the system returned a recognised item record. The feedback loop closes at the point of interaction rather than requiring a phone or desktop to be in view.

This matters most for the person who isn't managing the system. Not everyone in a household needs to understand what an MQTT broker is. They need to know that tapping the tag did something, and that something was the right thing. A red indicator means try again. A green indicator means logged.

Unit two: camera reader

The second unit is a dedicated camera device with onboard barcode and QR decoding.

The decoder runs entirely on the unit. No companion app, no tethering — it publishes scan events to the MQTT broker directly, in exactly the same format as the Android scanner. To the rest of the system, it's indistinguishable from a phone-based reader. To the person using it, it's a fixed point in a room that reads codes without any setup step.

The practical use case is storage areas where barcoded products move in and out regularly. Mount the unit at pantry height, position the field of view over the ingress zone, and any item passing the camera is read automatically. No tap, no pointing — items enter the read zone and the event fires.

This is also the right form factor for locations where phones don't belong: a workshop where hands are dirty, a larder where a phone would be out of place, a utility room where nobody wants to think about technology at all. The camera unit is just a box on the wall that knows when something went past.

What's shared between them

Both units identify themselves to the broker with a stable reader ID. A unit mounted in a specific location stays associated with that location across power cycles and reconnects. The heartbeat protocol is the same as the phone scanner — the desktop client knows which readers are live and which have dropped off.

Channel configuration is managed from the desktop. You assign an action to a reader channel the same way you'd configure any other channel — the hardware doesn't need to know what it's attached to, only that it read something and published it.

The units are in active development. We'll document the build specifics — firmware, hardware references, enclosure designs — as they stabilise.