It uses the entity from the Bambu integration to then process the update.
Going back to the top question, does the IDEX integration have an entity reporting usage, and then is refenced correctly in the configuration.yaml file
@Bpik Good catch, this was a real bug and it’s fixed for the next release.
SpoolmanSync was building that list from the locations already written on your spools instead of reading Spoolman’s own locations list. That meant a new location only showed up once you had moved a spool into it, and locations still attached to archived spools never went away, which is why some deletions cleared and some didn’t. It now reads Spoolman’s location list directly, so the two will always agree.
I also added the holding pen you suggested. There’s an optional “location when unassigned” box under the location sync toggle. If you leave it empty, nothing changes. If you type something like “Holding Pen”, that’s where spools go when you unassign them instead of having their location cleared. Let me know if that’s what you had in mind.
@DenCo Thanks for the detailed log. SpoolmanSync identifies spools by their RFID serial, but it only saves a spool’s serial the first time filament usage is recorded for it, normally when a print completes while it’s assigned. So a spool that hasn’t printed yet always needs one manual assignment, and the log message you quoted fires even when nothing is wrong. That wording is fixed for the next release, along with two related bugs: serial matching now tolerates serials entered by hand in Spoolman (the old code required an exact format match), and the “Possible wrong spool” warning had some false positives with certain color and material values.
So the path forward: update when the next release is out, assign the spool, and let one print complete. The print saves the correct serial automatically and overwrites anything already in the tag field, so there’s no need to clear it first. After that, swapping that spool in and out should auto-match. If it still doesn’t, or the warning still appears, send me the full output of curl /api/v1/spool/ for that spool along with what the warning shows for “RFID reports” vs “Assigned spool”, and I’ll dig in from there.
@bixler6440 - First, to clear up the configuration.yaml question: with the add-on install you won’t find the SpoolmanSync config blocks in configuration.yaml itself. The add-on writes them to a package file at config/packages/spoolmansync.yaml, adds a short “packages:” line under “homeassistant:” in configuration.yaml if you don’t already have one, and puts the automations in automations.yaml. So the real check is whether config/packages/spoolmansync.yaml exists and whether automations.yaml has SpoolmanSync entries. If neither does, the Configure Automations step never ran, and that alone would explain everything.
One other detail before the checks: your screenshot shows four filaments with weights. Where is that card from (a Spoolman integration in Home Assistant, or something else)? And do you have an AMS 2 Pro attached, or truly no AMS? Four slots would fit an AMS 2 Pro, and the answer changes the diagnosis.
Now the checks, in order:
In Home Assistant, go to Settings > Automations. Do you see two “SpoolmanSync” automations for your printer (Update Spool and Tray Change)? If not, open the SpoolmanSync add-on, go to the Automations tab, and click Configure Automations.
In Developer Tools > States, does sensor.spoolmansync__filament_usage exist? If the automations exist but this sensor doesn’t, Home Assistant was never fully restarted after configuring. Restart it (Settings > System > Restart), then check again. This alone would explain your exact symptom: tray changes work, but weight never moves.
In HACS, make sure ha-bambulab is v2.2.22 or newer. That’s the first version with X2D support.
Your JAYO and Sunlu spools have no RFID chip, so SpoolmanSync can’t detect them automatically. You have to assign the loaded spool to a slot yourself on the SpoolmanSync dashboard. If no spool is assigned, no weight is ever deducted. If you have no AMS, assign it to the first “External Spool” slot, not “External Spool 2”: I found a quirk where an X2D without an AMS reports both slots as active all the time, and in that state usage only lands on the first slot when a print finishes.
Run a normal single-color print. If the weight still doesn’t move after all of the above, send me what sensor._print_weight showed during the print and whether “SPOOLMANSYNC PRINT END” appears in the HA system log. Those two will pin down what’s left.
To be clear about what to expect on this model right now, assuming no AMS: the entire print’s filament gets deducted from the spool on the first “External Spool” slot, once, when the print finishes. That means single-color prints from the first slot track accurately. Dual-color prints don’t: the whole print gets charged to the first spool and the second spool gets nothing. That’s down to what ha-bambulab currently reports for this printer, not something I can patch on my side. If that improves upstream I can build on it, and the ha-bambulab project would be the place to request it if the dual-color case matters to you.
@gibz104 Thank you so much for your very detailed response! I’ve attached a JPEG file that explain the checks I’ve performed and the answers to your questions. Everything is fine up to step 4 of your explanation. In step 5, I ran a normal single-color print: “SPOOLMANSYNC PRINT END” does not appear in the logs, and strangely, I cannot find any entity resembling sensor.print_weight. The only entity I can find is this one, translated into French and including the printer’s name and ID number: sensor.x2d_20…………..7_poids_de_limpression
Thank you, that’s exactly what I needed, and it found the problem. Your setup is correct, and don’t worry about the French entity names, SpoolmanSync discovers entities in a language-independent way and your screenshots show it worked.
Here’s what’s happening: at the end of a print, this printer’s status briefly drops to “offline” for a few seconds (a momentary disconnect, normal on this model) before settling on “idle”. That short blip does two things in the current automations. It wipes the usage counter, which is why your meter reads 0. And it makes the print-end step see that the status came from “offline”, which it skips as a safety guard against double-counting after power cycles. That skip is silent, which is why “SPOOLMANSYNC PRINT END” never appears in your log.
The fix is released in v1.6.7. To get it: update the SpoolmanSync add-on, open the Automations tab and re-run Configure Automations, restart Home Assistant when prompted, then run a single-color print. The weight should come off the spool assigned to the first “External Spool” slot when the print finishes, and “SPOOLMANSYNC PRINT END” should now appear in the HA log. If it still doesn’t deduct after that, tell me and I’ll keep digging.
@gibz104 Ok, it’s tracking now! I deleted my printer in SpoolmanSync and added it again, and now it’s logging usage. However, I have a question: since I have two trays, I assigned the filament to ExternalSpool_external_spool (spoolId: 1, trayId: “X2D_20…07_ExternalSpool_external_spool”) thinking it would deduct from that one, but it ended up deducting from ExternalSpool2_external_spool (spoolId: 2, trayId: “X2D_20…07_ExternalSpool2_external_spool”). What is the rule here, please?
Glad it’s tracking! The rule is the deduction follows the nozzle that printed. The catch is that the ha-bambulab integration names these backwards from what you’d expect: “External Spool” is the LEFT nozzle’s holder, and “External Spool 2” is the RIGHT nozzle’s holder, which is the primary one that single-color prints use. Your print ran on the right nozzle, so it deducted from the spool assigned to External Spool 2.
So assign the spool physically sitting on the right-side holder to External Spool 2, and the left-side one to External Spool. That’s the opposite of what I told you earlier, my mistake. Once they match, single-color prints deduct from the correct spool, and a print using both nozzles deducts each material from its own spool as the nozzles switch, the same way AMS color changes are tracked. Waste like purging counts against whichever spool was active at the time, which is true on every printer.
The backwards naming comes from the ha-bambulab integration, so it’s not something I can change in SpoolmanSync unless it changes upstream.
@gibz104 Oh, okay! Thanks a lot for the explanation. It’s working properly now! Thanks for your help!!!
I do have one last question: you mentioned that “a print using both nozzles deducts each material from its own spool.” Is that how it’s supposed to work for a two-color print without an AMS? Because I ran a test, and it deducted the total amount from just a single spool.
I just discovered SpoolmanSync yesterday, and am thrilled about how easy it was to get up and running on the first try. I’m still a bit new to this stuff, but I’m learning.
I’m working with a pair of Bambu printers, and from what I can tell, everything is working exactly as it should - weights/amounts are being updated after each print, and all is well.
I do have more of a “cosmetic” question for you, though -
The Spoolman location names for the AMS slots are quite long. [printername]_[serialnumber]AMS[serialnumber]_tray_X appears to be the formatting.
I’m wondering - might there be a way to rename these after they’ve been created and synced up? Sort of like an alias or nickname, so that when we’re looking at the locations in Spoolman, they’re a little more readable?
Something like [printername]_AMS_tray_X? (basically, hiding the serial numbers)
I tried renaming them myself, but that seemed to break the link and create new locations altogether.
Thank you again for putting this together, and I look forward to seeing how things continue to develop.
