Add support for reading OpenTag3D tags

[queengooborg]

This PR fixes #67 by adding support for reading OpenTag3D tags. This also paves the way for adding support for other tag formats, separating the OpenSpool pieces into their own namespace and de-duplicating some code. To ensure the maximum amount of compatibility, this adds support for reading both v1 and v2 tags.

Tag Reading

The updates will allow users who have either v1 or v2 OpenTag3D tags to scan their tag and have it parsed for the Bambu Lab printer to recognize.

Tag Writing

Tag writing support was not implemented for a few reasons:

1. Tag writing can be performed using tools like the make page on the OpenTag3D website.
2. OpenTag3D has more required fields than OpenSpool stores, so a redesign of the editing interface is needed.

Additional Testing Recommended

I have not been able to test the MQTT connection to the printer because I am currently in the process of a multi-day print. I strongly recommend testing this in full before merging!

Disclaimer: Use of AI

As much as I hate to admit it, this PR was almost entirely written by GitHub Copilot. I despise AI and would have definitely preferred to write the code myself, but even I will have to admit, it was much quicker having it write the code and me telling it what changes to make than it would have to write it myself...

[spuder]

This is great, thanks for submitting this PR. AI is fine. I'll just need to figure out a way to leverage AI to help review it.

When I originally wrote it, it took a lot of trial and error to avoid overrunning the available heap on the esp32. Optimizations like that are hard for AI to catch since they only really show up in the real world.

Has this been tested on real hardware yet?

[spuder]

🤖 Automated review disclosure: This comment was generated by Claude Code (Claude Sonnet 5), run by @spuder, using the /code-review skill. Please treat findings as suggestions to verify, not ground truth.

Review of firmware/bambu.h (OpenTag3D v2 decoding)

1. False-negative on valid 0°C chamber temp — bambu.h:109
decode_v2() treats a chamber-temperature byte of 0 as "missing," but per the OpenTag3D spec, 0 is a legitimate value meaning "no heated chamber needed" (e.g. for PLA). A spec-compliant tag written this way is rejected outright — decode() returns false, no MQTT payload is generated, and the LED turns red — even though decode_v1() correctly treats zero/optional temp fields as optional elsewhere.

2. "NFC Raw Data" sensor not updated on decode failure — bambu.h:490
For OpenTag3D tags specifically, result.display_payload (which feeds the "NFC Raw Data" text sensor) is only populated when opentag3d::decode() succeeds. The openspool/JSON branch always sets display_payload from the raw record before decode is attempted. So a corrupted, truncated, or unsupported-version OpenTag3D tag leaves the sensor showing stale data from the previous scan instead of reflecting the new (failed) read — misleading when debugging why a tag isn't recognized.

3. Lost duplicate-record warning — bambu.h:463
The new record-scanning loop silently keeps only records[0] when multiple records of the same type are present, dropping the previous code's log line ("Multiple JSON records found, using first one"). A tag mis-written with duplicate JSON/opentag3d records now fails silently instead of surfacing a diagnosable warning.

4. Duplicated MQTT payload scaffolding — bambu.h:369
The two generate_mqtt_payload overloads (for openspool::Tag and opentag3d::Tag) duplicate nearly identical JsonDocument/print-object scaffolding (sequence_id, command, ams_id, tray_id, setting_id, result serialization/empty-check/logging). Not a bug, but a maintainability risk — a future change to the MQTT envelope is easy to apply to only one path, letting the two tag sources silently diverge.

---

Findings 1 and 3 look like the most actionable correctness issues; 2 is a real but lower-severity observability bug; #4 is a cleanup suggestion rather than a bug.

[queengooborg]

And now we just need the AI to review what the review AI says! 😛

It has been partially reviewed on real hardware, but not the complete process. I did a visual inspection of the logs and the generated MQTT messages to see if they respond to the tags I scanned (specifically referencing the color), and they did.

Now that my print is done and I've taken my printer fully offline/in LAN mode, I can test it from start to finish and make sure it's all functional! (I'll also make those suggested tweaks, as well as dig in and try to clean up some of the AI slop...!)

[queengooborg]

Alright, just made the updates, and made a few other small tweaks as well! I'm not home at the moment so I haven't tested this on my OpenSpool hardware yet, but I've at least checked to make sure that it compiles.

My personal next steps are:

• Confirm everything works on real hardware
• Test the workflow from start to finish and make sure my printer updates properly
• Verify that a failed attempt to parse OpenSpool data will still parse OpenTag3D data
• Optimize and further clean up the AI-generated code