[GH-ISSUE #918] [Feature]: Ability to manually assign Bambu spools to filament in manager

BreizhHardware commented

2026-05-06 12:31:29 +02:00

Owner

Originally created by @ViridityCorn on GitHub (Apr 8, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/918

Originally assigned to: @maziggy on GitHub.

Problem or Use Case

I beleive, there is currently a confusing disparity in how Bambuddy handles inventory assignment depending on the brand of filament used.

Third-Party Consistency: For non-Bambu spools, I can manually assign an AMS slot to a specific entry in my Filament Manager. This works perfectly and maintains my data integrity.
RFID "Lock-in": When a Bambu spool is used, the RFID tag forces an automatic identification that "locks" the slot. I lose the ability to manually map that slot to a specific, pre-existing entry in my Filament Manager.
The "Ghost" Duplicate Issue: Because I log my spools when they arrive, I often already have a record for a spool (with accurate weights and notes). When I put that spool in the AMS, Bambuddy frequently fails to recognize it as the existing record and automatically creates a duplicate entry. This new entry lacks my manual weight data and historical notes, making my inventory management redundant and messy.
Unpredictable Behavior: Occasionally, the system correctly identifies an existing spool, but more often it creates a duplicate. There is currently no way for me to "force" the correct association.

Proposed Solution

While automatic RFID recognition is a great "quality of life" feature, I don't think it should not supersede user-defined data.

Manual Overwrite for RFID Slots
Add an "Assign from Inventory" button to RFID-identified slots. Even if the AMS knows the spool is "Bambu Red PLA," I should be able to manually tell the software: "Yes, and specifically, this is 'Spool 105' from my manager."
Manual Reconciliation/Merging
If the software automatically creates a new spool entry via RFID, provide a "Merge with Existing Spool" option. This would allow me to combine the newly detected RFID UID with my existing record, preserved weight data, and notes.
"Match on RFID" Prompt
If multiple spools of the same type exist in the inventory (e.g., three open spools of Bambu Green), the system should prompt the user: "Multiple matches found in Filament Manager. Which spool is currently in Slot X?"

Alternatives Considered

Currently, I have been forced to manually merge the information of my existing spool in the manager into the automatically created one. I find this a bit tedious and cumbersome.

Feature Category

UI/UX

Priority

Would improve my workflow

Mockups or Examples

No response

Contribution

I would be willing to help implement this feature

Checklist

I have searched existing issues to ensure this feature hasn't already been requested

Originally created by @ViridityCorn on GitHub (Apr 8, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/918 Originally assigned to: @maziggy on GitHub. ### Problem or Use Case I beleive, there is currently a confusing disparity in how Bambuddy handles inventory assignment depending on the brand of filament used. - Third-Party Consistency: For non-Bambu spools, I can manually assign an AMS slot to a specific entry in my Filament Manager. This works perfectly and maintains my data integrity. - RFID "Lock-in": When a Bambu spool is used, the RFID tag forces an automatic identification that "locks" the slot. I lose the ability to manually map that slot to a specific, pre-existing entry in my Filament Manager. - The "Ghost" Duplicate Issue: Because I log my spools when they arrive, I often already have a record for a spool (with accurate weights and notes). When I put that spool in the AMS, Bambuddy frequently fails to recognize it as the existing record and automatically creates a duplicate entry. This new entry lacks my manual weight data and historical notes, making my inventory management redundant and messy. - Unpredictable Behavior: Occasionally, the system correctly identifies an existing spool, but more often it creates a duplicate. There is currently no way for me to "force" the correct association. ### Proposed Solution While automatic RFID recognition is a great "quality of life" feature, I don't think it should not supersede user-defined data. 1. Manual Overwrite for RFID Slots Add an "Assign from Inventory" button to RFID-identified slots. Even if the AMS knows the spool is "Bambu Red PLA," I should be able to manually tell the software: "Yes, and specifically, this is 'Spool 105' from my manager." 2. Manual Reconciliation/Merging If the software automatically creates a new spool entry via RFID, provide a "Merge with Existing Spool" option. This would allow me to combine the newly detected RFID UID with my existing record, preserved weight data, and notes. 3. "Match on RFID" Prompt If multiple spools of the same type exist in the inventory (e.g., three open spools of Bambu Green), the system should prompt the user: "Multiple matches found in Filament Manager. Which spool is currently in Slot X?" ### Alternatives Considered Currently, I have been forced to manually merge the information of my existing spool in the manager into the automatically created one. I find this a bit tedious and cumbersome. ### Feature Category UI/UX ### Priority Would improve my workflow ### Mockups or Examples _No response_ ### Contribution - [x] I would be willing to help implement this feature ### Checklist - [x] I have searched existing issues to ensure this feature hasn't already been requested

BreizhHardware

2026-05-06 12:31:29 +02:00

closed this issue
added the
enhancement
label

BreizhHardware commented

2026-05-06 12:31:30 +02:00

Author

Owner

@ViridityCorn commented on GitHub (Apr 8, 2026):

I can see the find_matching_untagged_spool function in "backend/app/services/spool_tag_matcher.py" actually should assign the Bambu spool on the AMS to one in the filament manager. I'll explore further to figure out, why it did not work in my case.

@ViridityCorn commented on GitHub (Apr 8, 2026): I can see the `find_matching_untagged_spool` function in "backend/app/services/spool_tag_matcher.py" actually should assign the Bambu spool on the AMS to one in the filament manager. I'll explore further to figure out, why it did not work in my case.

BreizhHardware commented

2026-05-06 12:31:30 +02:00

Author

Owner

@Arn0uDz commented on GitHub (Apr 8, 2026):

I can confirm the ghost duplicate issue.

I bought 20 spools and added them as a way to keep inventory. Upon placing them in the AMS they get added again instead of using one of the manually added. Had this issue with every filament I placed in the AMS.

@Arn0uDz commented on GitHub (Apr 8, 2026): I can confirm the ghost duplicate issue. I bought 20 spools and added them as a way to keep inventory. Upon placing them in the AMS they get added again instead of using one of the manually added. Had this issue with every filament I placed in the AMS.

BreizhHardware commented

2026-05-06 12:31:31 +02:00

Author

Owner

@maziggy commented on GitHub (Apr 9, 2026):

I can confirm the ghost duplicate issue.

It's not an issue, it's a feature :) The current implementtion is to to auto-detect new spools on first usage and add them automatically to the inventory.

Not sure, if we want to change this behaviour.

Before we think about to change this, I'd like to gauge community interest. If you'd find this feature useful, please give this issue a thumbs up (👍) reaction so we can prioritize accordingly.

@maziggy commented on GitHub (Apr 9, 2026): >I can confirm the ghost duplicate issue. It's not an issue, it's a feature :) The current implementtion is to to auto-detect new spools on first usage and add them automatically to the inventory. Not sure, if we want to change this behaviour. Before we think about to change this, I'd like to gauge community interest. If you'd find this feature useful, please give this issue a thumbs up (👍) reaction so we can prioritize accordingly.

BreizhHardware commented

2026-05-06 12:31:31 +02:00

Author

Owner

@Arn0uDz commented on GitHub (Apr 9, 2026):

I can confirm the ghost duplicate issue.

It's not an issue, it's a feature :) The current implementtion is to to auto-detect new spools on first usage and add them automatically to the inventory.

Not sure, if we want to change this behaviour.

Before we think about to change this, I'd like to gauge community interest. If you'd find this feature useful, please give this issue a thumbs up (👍) reaction so we can prioritize accordingly.

What is the use case of adding filament in bulk then, if you always end up with duplicates?

@Arn0uDz commented on GitHub (Apr 9, 2026): > > I can confirm the ghost duplicate issue. > > It's not an issue, it's a feature :) The current implementtion is to to auto-detect new spools on first usage and add them automatically to the inventory. > > Not sure, if we want to change this behaviour. > > Before we think about to change this, I'd like to gauge community interest. If you'd find this feature useful, please give this issue a thumbs up (👍) reaction so we can prioritize accordingly. What is the use case of adding filament in bulk then, if you always end up with duplicates?

BreizhHardware commented

2026-05-06 12:31:31 +02:00

Author

Owner

@Keybored02 commented on GitHub (Apr 9, 2026):

I don't agree with the proposal as it is formulated.

Bulk addition (mostly meant for non-BL spools) should not impact single spool flows. This means that any extra step between popping a new spool into the AMS and having it show up and tracked should be foolproof. This solution adds significant complexity and creates a lot of edge cases.

The "ghost duplicate" framing is not correct. A duplicate only appears if the UID doesn't match an existing record. If you logged spools before scanning them into the AMS, there's no UID to match against yet. BB can't know that "Spool #105 I manually entered last Tuesday" is the same physical object as the spool now sitting in Slot 3. This is by design, and should not change.
Reconciliation is doable, but your proposal is a really specific feature that fits no other workflows we've seen so far.

Bulk addition for BL spools should also go trough Spoolbuddy or an alternative NFC path (WIP), as that is the preferred way to keep 1:1 matches.

Note that at the current time BB does not substitute a farm inventory tracking. It's am implementation for smaller scales, to track capillary usage. If your consumption is measured in spools, instead of grams, it might be worth considering other options or suggest farm-centric flows that can be shared by a larger userbase.

@Keybored02 commented on GitHub (Apr 9, 2026): I don't agree with the proposal as it is formulated. Bulk addition (mostly meant for non-BL spools) should not impact single spool flows. This means that any extra step between popping a new spool into the AMS and having it show up and tracked should be foolproof. This solution adds significant complexity and creates a lot of edge cases. The "ghost duplicate" framing is not correct. A duplicate only appears if the UID doesn't match an existing record. If you logged spools before scanning them into the AMS, there's no UID to match against yet. BB can't know that "Spool #105 I manually entered last Tuesday" is the same physical object as the spool now sitting in Slot 3. This is by design, and should not change. Reconciliation is doable, but your proposal is a really specific feature that fits no other workflows we've seen so far. Bulk addition for BL spools should also go trough Spoolbuddy or an alternative NFC path (WIP), as that is the preferred way to keep 1:1 matches. Note that at the current time BB does not substitute a farm inventory tracking. It's am implementation for smaller scales, to track capillary usage. If your consumption is measured in spools, instead of grams, it might be worth considering other options or suggest farm-centric flows that can be shared by a larger userbase.

BreizhHardware commented

2026-05-06 12:31:31 +02:00

Author

Owner

@maziggy commented on GitHub (Apr 9, 2026):

I fully agree.

@maziggy commented on GitHub (Apr 9, 2026): I fully agree.

BreizhHardware commented

2026-05-06 12:31:31 +02:00

Author

Owner

@maziggy commented on GitHub (Apr 25, 2026):

find_matching_untagged_spool — that turned out to be exactly the right function, and there were two real bugs in it.

(1) Quick-Add inventory rows (which is what bulk-logging 20 spools uses) leave subtype empty, but the matcher required an exact subtype match against tray_sub_brands — so every AMS read created a duplicate.
(2) The brand wasn't being filtered at all, so a same-color third-party spool could silently inherit a Bambu UUID.

Available/Fixed in branch dev and available with the next release or daily build.

After upgrading: bulk-log via Quick Add (material + color is enough), drop a Bambu spool into the AMS, and it should attach to your existing record. The broader override/merge UI isn't going forward — once the auto-match works, the duplicate problem that motivated those proposals goes away. If you still see duplicates after upgrading, please reopen with the row contents (material/subtype/brand/rgba) and the AMS tray data so we can dig further.

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (Apr 25, 2026): find_matching_untagged_spool — that turned out to be exactly the right function, and there were two real bugs in it. (1) Quick-Add inventory rows (which is what bulk-logging 20 spools uses) leave subtype empty, but the matcher required an exact subtype match against tray_sub_brands — so every AMS read created a duplicate. (2) The brand wasn't being filtered at all, so a same-color third-party spool could silently inherit a Bambu UUID. Available/Fixed in branch dev and available with the next release or daily build. After upgrading: bulk-log via Quick Add (material + color is enough), drop a Bambu spool into the AMS, and it should attach to your existing record. The broader override/merge UI isn't going forward — once the auto-match works, the duplicate problem that motivated those proposals goes away. If you still see duplicates after upgrading, please reopen with the row contents (material/subtype/brand/rgba) and the AMS tray data so we can dig further. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!

BreizhHardware commented

2026-05-06 12:31:31 +02:00

Author

Owner

@maziggy commented on GitHub (Apr 25, 2026):

find_matching_untagged_spool — that turned out to be exactly the right function, and there were two real bugs in it.

(1) Quick-Add inventory rows (which is what bulk-logging 20 spools uses) leave subtype empty, but the matcher required an exact subtype match against tray_sub_brands — so every AMS read created a duplicate.
(2) The brand wasn't being filtered at all, so a same-color third-party spool could silently inherit a Bambu UUID.

Available/Fixed in branch dev and available with the next release or daily build.

After upgrading: bulk-log via Quick Add (material + color is enough), drop a Bambu spool into the AMS, and it should attach to your existing record. The broader override/merge UI isn't going forward — once the auto-match works, the duplicate problem that motivated those proposals goes away. If you still see duplicates after upgrading, please reopen with the row contents (material/subtype/brand/rgba) and the AMS tray data so we can dig further.

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (Apr 25, 2026): find_matching_untagged_spool — that turned out to be exactly the right function, and there were two real bugs in it. (1) Quick-Add inventory rows (which is what bulk-logging 20 spools uses) leave subtype empty, but the matcher required an exact subtype match against tray_sub_brands — so every AMS read created a duplicate. (2) The brand wasn't being filtered at all, so a same-color third-party spool could silently inherit a Bambu UUID. Available/Fixed in branch dev and available with the next release or daily build. After upgrading: bulk-log via Quick Add (material + color is enough), drop a Bambu spool into the AMS, and it should attach to your existing record. The broader override/merge UI isn't going forward — once the auto-match works, the duplicate problem that motivated those proposals goes away. If you still see duplicates after upgrading, please reopen with the row contents (material/subtype/brand/rgba) and the AMS tray data so we can dig further. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!

BreizhHardware commented

2026-05-06 12:31:32 +02:00

Author

Owner

@maziggy commented on GitHub (Apr 25, 2026):

Also added to the Wiki:

info "Auto-tracking new Bambu spools"

When a Bambu Lab spool is detected in the AMS and no inventory row already has its tray UUID, Bambuddy first looks for an existing untagged spool (matching material, color, and brand of "Bambu" / "Bambu Lab" / unspecified) and attaches the RFID to it — so a spool you logged ahead of time via Quick Add reuses your existing record (with your weight, notes, and cost data) rather than producing a duplicate. If no match is found, a new inventory row is created from the AMS data.

@maziggy commented on GitHub (Apr 25, 2026): Also added to the Wiki: info "Auto-tracking new Bambu spools" When a Bambu Lab spool is detected in the AMS and no inventory row already has its tray UUID, Bambuddy first looks for an existing **untagged** spool (matching material, color, and brand of "Bambu" / "Bambu Lab" / unspecified) and attaches the RFID to it — so a spool you logged ahead of time via Quick Add reuses your existing record (with your weight, notes, and cost data) rather than producing a duplicate. If no match is found, a new inventory row is created from the AMS data.

BreizhHardware referenced this issue

2026-05-06 12:34:56 +02:00

[PR #633] [MERGED] feat(metrics): add bambuddy_build_info metric #1083