[goeland86]

Summary

Decodes the TigerTag Maker/+ binary format (NTAG213, 144 bytes user memory) and wires it
into /tag/scan, reusing the same decoded/create: true contract #1112 (OpenPrintTag)
established. Same split as that PR: a format-specific codec (spoolman/tags/tigertag.py)
mapping onto the shared DecodedTag, with every write going through the already-validated,
already-transactional create_spool_from_decoded_tag path in spoolman/database/tag.py.

What's in this PR

• spoolman/tags/tigertag.py: decodes the fixed-width binary header (id_tigertag/
  id_product/id_material/id_aspect/id_type/id_diameter/id_brand, color RGBA, weight +
  measure unit, nozzle/bed/drying temperatures, timestamp, a 28-byte custom message).
• spoolman/tags/decode.py: a tigertag branch mapping TigerTagData onto the shared
  DecodedTag -- no changes needed in api/v1/tag.py, models.py, or database/tag.py,
  since those are already format-agnostic.
• TigerTag's id_material/id_brand are the format's own catalog IDs, not names --
  resolving them to real names needs an external DB lookup, which is deliberately a
  separate PR, feat(nfc): optional TigerTag external-DB add-on for name/density resolution #1325 (same reasoning as OpenPrintTag's gtin). material/name/
  vendor_name stay unset here rather than surfacing a bare catalog number.

Validated against the real spec, not guesses

Before opening this, I went through every category of problem raised on #1112's three
review rounds and checked whether it still needed addressing here, plus cross-checked this
codec against the official TigerTag spec (TigerTag-Project/TigerTag-RFID-Guide on
GitHub) the same way #1112 was checked against OpenPrintTag's own spec repo.

Inherited for free, since this branch is rebased on top of #1112's fixes: one
transaction for the whole auto-create (vendor/filament/spool/tag-link flush together,
commit once), range-checked density/weight/diameter before any write, tolerant
diameter/weight matching (plus color) when reusing an existing filament, the decoded tag
never being echoed back when create refuses it, non-ASCII payload_b64 handling, an
odd-length UID answering 400, and the TagDecodedInfo/instance_uuid field naming.

Structurally doesn't apply to this format: TigerTag is a fixed-width, big-endian
struct-packed binary layout, not a self-describing one like OpenPrintTag's CBOR. A
density/weight that's a list, a bignum, NaN, or Infinity can't arrive here -- every field
is a plain unsigned int of a fixed byte width, and there's no way to encode a different
Python type into any of them. No new dependency, no NDEF wrapping either.

Found and fixed by checking the real spec (not assumed from a guess at some point --
database/id_diameter.json, database/id_measure_unit.json, and the README's three fully
worked examples, cross-confirmed against the offsets its own Sample code/ parse_tigertag.py reference parser reads):

• Diameter IDs were invented (1/2, plus an "alt" 57 with no spec backing) instead of
  the real 56 (0x38, 1.75mm) / 221 (0xDD, 2.85mm) -- a real 2.85mm spool would've
  silently defaulted to 1.75mm.
• The weight field's unit byte was packed but never checked on decode. The spec's own
  Polymaker worked example reports its weight in kilograms, not grams -- trusting the raw
  value as always-grams would read 1000kg as 1000g. weight_grams is now None unless the
  tag says grams.
• bed_temp/bed_temp_max were read from the wrong offset (fixed); user_message was
  read from the wrong offset (fixed); emoji wasn't a real field at all (removed -- the
  offset it was read from falls inside the real Custom Message region).
• encode_ntag213 had no caller outside tests -- same situation as OpenPrintTag's
  encode_nfcv_memory, dropped from production there in response to review. Same fix here.

Color 2/3, tag index/count, HueForge TD, Measure Available, and the ECDSA signature pages
are real spec fields this PR still doesn't decode -- deliberately out of scope, same
discipline as OpenPrintTag's own PR1 (decode what's used, land more fields later).

Known limitation

Without the external-DB add-on (#1325, not part of this PR and mergeable independently of
it), a bare TigerTag tag has no product name -- create: true still makes a usable spool
(diameter/weight/color all come straight off the tag), just with an unnamed filament and no
vendor. Intentional, and covered by
test_create_true_on_an_unmatched_tigertag_creates_and_links_a_spool_without_names.

Test plan

• 647 integration tests pass (python tests_integration/run.py sqlite), 413 unit tests
  pass (pytest tests), ruff check/ruff format --check clean, uv lock --check clean
  (no dependency change).
• Three real-reference-payload tests built from the spec repo's own worked examples
  (tests/test_tigertag_codec.py), including the kilograms case.
• New tests_integration/tests/tag/test_scan_tigertag_hostile.py: the hostile cases that
  actually apply to a fixed-width format (over-range weight, a non-gram unit, a too-short
  payload, an unmapped magic number, the blank Init tag), each with before/after row-count
  checks, plus the positive-path case (an unmapped diameter id still creates, using the
  default).

🤖 Generated with Claude Code

[argos-ci]

The latest updates on your projects. Learn more about Argos notifications ↗︎

Build	Status	Details	Updated (UTC)
default (Inspect)	✅ No changes detected	-	Nov 10, 2026, 8:21 AM