feat: expose brand-specific identifiers in OpenPrintTag Response#6
Closed
gienne wants to merge 3 commits into
Closed
feat: expose brand-specific identifiers in OpenPrintTag Response#6gienne wants to merge 3 commits into
gienne wants to merge 3 commits into
Conversation
WriteDataWithURL was calling writeNTAGPages(card, 4, ...) for all non-MIFARE cards, including ISO 15693 (NFC-V) tags such as the NXP ICode SLIX2 used on Prusa filament spools. Two bugs for ISO 15693: 1. Wrong start block: NTAG user memory begins at page 4; ISO 15693 NDEF begins at block 1 (block 0 holds the Capability Container). 2. Padding to card.Size (320 bytes) caused writes to blocks 80-83, which are out of range for ICode SLIX2 (80 blocks, 0-79). Fix: detect NFC-V protocol and write CC to block 0 then NDEF TLV from block 1, mirroring the correct logic already present in WriteMultipleRecords. Tested on ACR1552U with blank NXP ICode SLIX2 tags and with Prusa-branded filament spool tags (write + readback verified).
Add BrandSpecificInstanceID, BrandSpecificPackageID and BrandSpecificMaterialID
to the Response struct so they are included in the JSON output of the card read
API endpoint.
These fields are already decoded from the CBOR payload (MainSection keys 5-7)
but were not propagated to the API response, making them invisible to consumers
of the /v1/readers/{n}/card endpoint.
Use cases:
- BrandSpecificInstanceID: per-spool serial/lot number (e.g. Prusa instance ref)
useful for traceability and inventory management systems
- BrandSpecificPackageID: product/SKU reference for the package
- BrandSpecificMaterialID: material reference identifier
JSON keys follow the existing camelCase convention used by the other UUID
fields (instanceUuid, packageUuid, etc.).
gienne
force-pushed
the
feat/response-brand-specific-ids
branch
from
fc1fd32 to
cbcef1e
Compare
Author
|
Wrong content |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
BrandSpecificInstanceID,BrandSpecificPackageIDandBrandSpecificMaterialIDare decoded from the CBOR payload (MainSection keys 5-7) but not included in the JSON response of the card read endpoint, making them invisible to API consumers.Fix
Add the three fields to the
Responsestruct and populate them inToResponse().JSON keys follow the existing camelCase convention (
instanceUuid,packageUuid, etc.).Use cases
brandSpecificInstanceId: per-spool serial/lot number (e.g. Prusa instance reference) useful for traceability and inventory systemsbrandSpecificPackageId: product/SKU reference for the packagebrandSpecificMaterialId: material reference identifier