Print QR-code labels to identify installed equipment (Brother QL-820NWBc over the network)

[guycorbaz]

What

Print adhesive labels carrying a QR code, so a piece of hardware in a rack or on a shelf can be
identified physically and linked back to its record in opencmdb.

Scanning a label opens that device's page in opencmdb. Alongside the QR code, the label prints a
few human-readable fields so it stays useful without a phone.

First (and only) supported printer: Brother QL-820NWBc, connected over the network.

Why

The reconciliation engine knows what a device is; nothing connects that knowledge to the object
you are holding. In a rack, "which of these three identical boxes is 192.0.2.41" is answered by
unplugging things. A label closes that loop in the one direction the product cannot otherwise
reach: from the physical world back into the CMDB.

Scope

In:

• Labels for devices only.
• QR content: a URL to the device's page (e.g. https://<base_url>/device/<id>).
• Human-readable text beside the QR — hostname, primary IP, short id. Exact fields TBD.
• One printer model: Brother QL-820NWBc, over the network.
• Batch printing: select N devices, print the sheet in one job.

Out, for now:

• Labels for subnets / VLANs / racks. Revisit once IPAM exists (Epic 14) — the same mechanism
  should extend, but there is no point designing for it before the objects exist.
• Any second printer model, USB or Bluetooth connections, and label design customisation by the
  operator.

Horizon

Post-v1.0, Growth backlog. This adds no FR to the PRD and no epic to the 23 planned for v1.0.
Recorded now so the constraints below are not rediscovered later.

What needs deciding before this is buildable

1. The QR URL needs a configured base URL. opencmdb currently has no notion of "the address at
   which I am reachable". A label is permanent; a wrong base URL is printed on physical objects and
   cannot be recalled. This is a prerequisite, not a detail.

2. Label identity vs. engine identity — the real risk. A label is a permanent, physical
   assertion. The identity engine may later merge two device records or split one, and the id on a
   printed label would then point at a record that no longer means what it meant when printed. At
   minimum the target id must be stable across merges, or the device page must resolve a retired id
   to its successor rather than 404. This deserves a decision before anything is printed, not after.

3. The printing path. The QL-820NWBc is an Ethernet/Wi-Fi network printer using DK roll media.
   Two candidate approaches, to be settled against Brother's raster command reference for the QL
   series rather than by assumption:

   • render the label to a bitmap and send Brother raster commands directly over TCP (no system
     print stack, which suits a single self-hosted binary);
   • or delegate to CUPS/IPP and require the operator to have the printer configured on the host.

   The first keeps the deployment story ("one binary, one container") intact; the second is less
   code and more moving parts. Media size and orientation come from the loaded DK roll and must be
   configurable or detected — printing a 62 mm layout onto a 29 mm roll silently produces garbage.

4. Where the code lives. Printing is outbound network I/O, so it belongs in opencmdb-bin
   (D47/D55). opencmdb-core must not learn about printers, bitmaps or sockets.

5. Testing without hardware. There must be a way to exercise this in CI with no printer on the
   network — a fixture capturing the byte stream sent for a known device, in the spirit of the
   corpus in fixtures/. A feature that can only be tested by printing will not be tested.