OpenSpool: putting the filament's own settings on an NFC tag

The problem the reader solves

The pitch in the README is direct: adhere NFC stickers on all your filament, build an ESP32 OpenSpool reader and place it next to your printer, and touching the filament to the reader automatically updates your Bambu Printer filament settings, almost as smoothly as if you were using Bambu filament with an AMS.

That last comparison is the useful one. The Bambu AMS is a multi-spool feeder that identifies each filament and tells the printer what it is, which is why an AMS user never has to think about nozzle temperature when swapping filament. OpenSpool is an open approach to the same problem for people who are not using that proprietary system, or who do not want the AMS hardware.

The scope is filament identity and its parameters. A spool carries filament type, colour, brand and a minimum and maximum temperature, and a reader that can report those lets the printer or the slicer pick the right profile without the user remembering it.

The implementation language is C++, and the repository contains the firmware, the hardware design and the documentation together, with a firmware directory, a hardware directory, an extras directory and a docs directory, plus a release.sh script and a CHANGELOG.md. The project site is openspool.io, and the README carries the tagline your filament wants to be free, which is a fair summary of the intent.

The audience is 3D printing hobbyists with a printer that can be automated, and the project describes itself as open source with a Discord server and a subreddit around it.

The OpenSpool record format

The protocol section states the goal plainly: OpenSpool aims to use the simplest possible protocol for RFID tags. All you need is an NTAG 215/216.

The record stored on the tag is an NDEF record with the type application/json, and the payload is the whole data model:

{
    "protocol": "openspool",
    "version": "1.0",
    "type": "PLA",
    "color_hex": "FFAABB",
    "brand": "Generic",
    "min_temp": "220",
    "max_temp": "240"
}

Everything in it is a plain field, and the version field is there so a reader can tell what it is looking at. The temperature fields are strings, which is a small choice worth noting if you write a writer: a reader that parses these has to handle them as text, and any tooling you build around the format will inherit that.

Using JSON on a tag rather than a binary record is the decision that makes the format inspectable. Any phone with NFC reader capability can read the raw record, and anyone can write a compatible tag with a phone app and a template, without a special tool. That matters for a protocol whose purpose is to be open.

The reader is equally simple in its ambition. The component list names a PN532 small NFC reader module and an NTAG 215/216 tag with more than 500 bytes of capacity, which is far more than the payload above needs. The design is not trying to be clever with the tag; it is trying to be cheap and legible.

Other tag formats, and where they stand

OpenSpool is not the only tag format in 3D printing, and the protocol table is a status board for the alternatives.

OpenSpool itself is the only row marked complete for both read and write, on NTAG 215/216. TigerTag is in progress for both directions, on NTAG 213. The Bambu row is in progress for read and explicitly not supported for write, on MiFare Classic 1k, which follows from the fact that Bambu's own tags are proprietary and locked. Creality is marked planned on MiFare Classic 1k. PrusaRFID is marked with question marks across the board, which reads as an undocumented situation rather than a commitment. Elegoo and Anycubic are marked as being researched, with the tag type unknown.

The most interesting of these is OpenTag3D, an open standard that many 3D printer filament companies are said to be uniting around. The README notes that it was planned to be finalized in early to mid 2025, and that OpenSpool will support OpenTag formatted tags as soon as it is finalized, with a link to the standard's own site.

That is a candid statement of a dependency, and it also tells you something about where the project sees itself. OpenSpool is a working answer now, with an intention to become compatible with a broader standard later. If you are choosing a tag format to standardise on, the compatibility question matters more than the current maturity.

The web preview link in the README is a small piece of evidence for the open approach: the same fields are exposed as query parameters, so you can see what a tag would contain without reading hardware.

Printer integration, and the one that works today

Currently OpenSpool works with Bambu printers over MQTT, and other integrations are planned, with pull requests welcome.

The integration table lists what is coming. OctoPrint is in progress. Prusa Connect, SpoolMan and Klipper with Moonraker are planned. Anker is listed without a status.

So today the reader talks to one vendor's ecosystem, and the reason is visible in the requirements. Bambu X1C printers running firmware 1.08.05.00 or newer must have LAN Mode and Developer Mode enabled for the OpenSpool reader to work, with a link to the Bambu blog post about firmware 1.08.05.00 and authorization control. All other Bambu printers, and X1C printers on firmware older than 1.08.05.xx, do not need Developer Mode enabled.

That is a significant operational condition rather than a footnote. Enabling Developer Mode on an X1C changes how the printer treats local network clients, and the README links to the vendor's own discussion of that change. Anyone adopting OpenSpool with a recent X1C is turning on a developer mode on their printer, and should read what that vendor says before doing it.

The MQTT route also implies a network assumption: the reader is a device on the same network as the printer, publishing filament information as a client, and the printer applies it. The reader therefore needs the printer's credentials, and the printer's MQTT endpoint needs to be reachable, which is what LAN Mode is for.

Building the reader

The hardware is an ESP32 board, an NFC reader module, a tag and a small amount of glue, and the README recommends a custom PCB.

The component list names the OpenSpool Mini PCB v3.1 with its Gerber files in the repository, a 3D printed enclosure available on MakerWorld, a Wemos D1 Mini s3 as the ESP32 board, a PN532 small NFC reader module, an NTAG 215/216 tag, a WS2812B LED, 2.54mm straight and right-angle headers, jumper wire, a 1206 10k SMD resistor and a BSS138 MOSFET. It recommends assembling with the custom PCB, and says you can send the Gerber files to a fabricator such as OSH Park.

There is a second path for people who do not want to fabricate a board. OpenSpool can be assembled without the custom PCB, and in place of the MOSFET and resistor you use a 3.3v to 5v Logic Level Converter, which is the part that makes the 5V PN532 safe to talk to a 3.3V ESP32.

One component warning is worth repeating. If you cannot find a Wemos D1 Mini s3, the s2 is pin compatible, but it has less memory and may experience occasional disconnects from the printer. That is a specific and practical note, and it is the kind of detail that only appears in a project that has actually had users assemble the board.

The MIT licensed documentation also points out that if you would rather not source the parts, a kit is sold on Tindie, and that the OpenSpool schematics will always be free. The separate licence files in the repository, one each for software, hardware, documentation and dependencies, reflect that separation.

Reading a tag with a phone

Because the record is plain JSON in an NDEF payload, a phone can read it and a web page can render it, and the README shows both halves.

The page image is captioned with the simple claim that spool information can be seen using your phone. And the web preview is a URL that carries the same fields as the tag payload:

https://openspool.io/tag_info?color_hex=FFAABB&type=PLA&brand=Generic&min_temp=220&max_temp=240&protocol=openspool&version=1.0

That is a small design decision with a large convenience attached. The fields on the tag and the fields in the preview are the same, so the preview doubles as a reference for the format and as a way to check what you are about to write. A user who has just bought blank tags can compose a record, see how it will look, and only then commit it to the tag.

It also means the format is legible without the OpenSpool hardware at all, which matters for a project whose stated goal is to be the open option. A user who decides later to buy a Bambu AMS, or to use a different reader implementation, still has the data in a format anyone can read.

The repository root reinforces the open posture. Alongside the four separate licence files there is a LICENSE.txt, a NOTES.md, a TODO.md, a CNAME for the documentation site and a .yamlfmt configuration, which suggests a project that keeps its working notes in the repository rather than in a chat.

Where OpenSpool is the wrong tool

The limits are visible in the tables, and they are about ecosystem rather than about technology.

The first is that the printer integration is essentially Bambu only. If you print on a Prusa, a Creality or a machine running OctoPrint or Klipper, the reader hardware will identify your filament and the automation will stop there. OctoPrint and Klipper are in progress or planned, and Klipper in particular has a large user base that writes macros, so the gap between reading a tag and having a slicer pick the profile is the whole value of the project.

The second is the Bambu firmware condition. On an X1C with firmware 1.08.05.00 or newer you have to enable Developer Mode, which is a change to how your printer trusts local network clients. If your threat model does not allow that, or if your printer is managed by someone else, this project is not usable on that machine.

The third is the hardware commitment. Even the no-PCB path needs a soldering iron, a level shifter and a reader module. This is a maker project, not a consumer product, and the Tindie kit exists because the assembly is not trivial.

The fourth is that the protocol is young. The OpenSpool record has a version field set to 1.0, the OpenTag3D standard was planned to be finalised in early to mid 2025 and the integration statuses are mostly in progress. The project's own release history is short and recent, with 1.21.2 on 2025-08-30, 1.21.1 on 2025-08-29 and 1.20.0 on 2025-04-08, and the last push to the repository was on 2026-09-29.

None of that makes the project a bad bet for a Bambu owner with a shelf of filament and a soldering iron. It makes it a bet on one ecosystem, with a protocol that is still settling, which is worth saying out loud before you buy ten tags.

Editorial conclusion

Adopt OpenSpool if you print with a Bambu printer, keep several filaments with different temperature ranges, and are tired of setting the profile by hand, since the reader does that automatically on approach. Do not adopt it if your printer is not yet on the integration list, because only Bambu works today and the others are marked in progress or planned, and expect to assemble hardware yourself unless you buy a kit. Before you build a reader, check the protocol table for your tag and your printer, and read the licence files in the repository, since software, hardware, documentation and dependencies are licensed separately and the hardware schematics are promised to stay free.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. spuder/OpenSpool on GitHub