starred/bambuddy

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 05:35:30 +02:00

[GH-ISSUE #1057] [Feature]: Filament tracking for multiple rolls of the same spool #749

New issue

Closed

opened 2026-05-06 12:32:34 +02:00 by BreizhHardware · 4 comments

BreizhHardware commented

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

Owner

Originally created by @abbasegbeyemi on GitHub (Apr 20, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1057

Originally assigned to: @netscout2001 on GitHub.

Problem or Use Case

The current filament inventory combined with spoolbuddy is a game changer. Currently, we have two ways of registering spools. As a single spool, which creates a new record, and if we link a tag with spoolbuddy for external spools, or the spool is added from the AMS for bambu spools, we get a record with remaining weight.

The second way we can register spools is to do a 'Quick Add' in the filament registration, and when you increment the quantity, it creates multiple records of the same spool. The problem with this workflow is that when registering multiple third party spools, you don't really want to have multiple identical records of the same filament.

I recon when most people do a quick add, they want to register stock of multiple rolls of the same filament, in order to track when a particular material/colour is running low.

Proposed Solution

If we could have field in the filament spool model where we can set/increment the number of rolls of a particular spool, that would be great. The quick add form that takes quantity can record then number of spools against the same filament record. The workflow could also be that when a new third party spool is registered, the quantity added could be multiplied by the number of copies, and usage could decrease the total combined weight of all the spools. I think this is how SpoolEase handles it.

Alternatives Considered

The alternative solution I considered is using the notes section to track the number of spools, but it becomes a bit unwieldy when you have many different kinds of filament with multiple spools.

Feature Category

Spool Inventory

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 @abbasegbeyemi on GitHub (Apr 20, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1057 Originally assigned to: @netscout2001 on GitHub. ### Problem or Use Case The current filament inventory combined with spoolbuddy is a game changer. Currently, we have two ways of registering spools. As a single spool, which creates a new record, and if we link a tag with spoolbuddy for external spools, or the spool is added from the AMS for bambu spools, we get a record with remaining weight. The second way we can register spools is to do a 'Quick Add' in the filament registration, and when you increment the quantity, it creates multiple records of the same spool. The problem with this workflow is that when registering multiple third party spools, you don't really want to have multiple identical records of the same filament. I recon when most people do a quick add, they want to register stock of multiple rolls of the same filament, in order to track when a particular material/colour is running low. ### Proposed Solution If we could have field in the filament spool model where we can set/increment the number of rolls of a particular spool, that would be great. The quick add form that takes quantity can record then number of spools against the same filament record. The workflow could also be that when a new third party spool is registered, the quantity added could be multiplied by the number of copies, and usage could decrease the total combined weight of all the spools. I think this is how SpoolEase handles it. ### Alternatives Considered The alternative solution I considered is using the notes section to track the number of spools, but it becomes a bit unwieldy when you have many different kinds of filament with multiple spools. ### Feature Category Spool Inventory ### 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:32:34 +02:00

closed this issue
added the
wontfix

enhancement
labels

BreizhHardware commented

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

Author

Owner

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

@netscout2001 Is that something you can also consider?

@maziggy commented on GitHub (Apr 20, 2026): @netscout2001 Is that something you can also consider?

BreizhHardware commented

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

Author

Owner

@netscout2001 commented on GitHub (Apr 22, 2026):

Hi @abbasegbeyemi,

The current workflow is actually the same as how Spoolman works or other. You add a certain number of spools. These are used, and the weight is reduced. That’s also the standard workflow.
Doing what you’re describing within a single data set would unnecessarily complicate things and, in my opinion, wouldn’t be practical for the workflow.

@netscout2001 commented on GitHub (Apr 22, 2026): Hi @abbasegbeyemi, The current workflow is actually the same as how Spoolman works or other. You add a certain number of spools. These are used, and the weight is reduced. That’s also the standard workflow. Doing what you’re describing within a single data set would unnecessarily complicate things and, in my opinion, wouldn’t be practical for the workflow.

BreizhHardware commented

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

Author

Owner

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

Hi @netscout2001 ,

Sorry I haven't used Spoolman before so I am not sure how the workflow there is. I don't think it will complicate things that much. I am coming at this mainly from a Spoolbuddy perspective. I am happy to hear if you have a different workflow for Spoolbuddy, but the idea is that you have your spool tagged, and when you want to load a spool using Spoolbuddy, it is measured and tagged in to be loaded onto the AMS.

The current filament stock workflow assumes a single tag per spool regardless of filament, which means you will be using a different NFC tag per spool even though they are the exact same spool. In a way that works for workflows where you want to load up the same filament to multiple printers, and you want to track their weights separately.

But for people who wait for a spool to finish before loading up the next spool of the same weight just reusing the same tag, there is no way to currently track how many copies of the same spool they have.

Maybe the format of tracking total weight might complicate things, I haven't looked through the codebase yet, but you have to agree that having Spoolbuddy + Bambuddy as the all in one filament tracking system would benefit from being able to track spool duplicates without having to register each spool with a different NFC tag.

More than happy to brainstorm a sensible solution with you. I am enamoured with this project.

@abbasegbeyemi commented on GitHub (Apr 25, 2026): Hi @netscout2001 , Sorry I haven't used Spoolman before so I am not sure how the workflow there is. I don't think it will complicate things that much. I am coming at this mainly from a Spoolbuddy perspective. I am happy to hear if you have a different workflow for Spoolbuddy, but the idea is that you have your spool tagged, and when you want to load a spool using Spoolbuddy, it is measured and tagged in to be loaded onto the AMS. The current filament stock workflow assumes a single tag per spool regardless of filament, which means you will be using a different NFC tag per spool even though they are the exact same spool. In a way that works for workflows where you want to load up the same filament to multiple printers, and you want to track their weights separately. But for people who wait for a spool to finish before loading up the next spool of the same weight just reusing the same tag, there is no way to currently track how many copies of the same spool they have. Maybe the format of tracking total weight might complicate things, I haven't looked through the codebase yet, but you have to agree that having Spoolbuddy + Bambuddy as the all in one filament tracking system would benefit from being able to track spool duplicates without having to register each spool with a different NFC tag. More than happy to brainstorm a sensible solution with you. I am enamoured with this project.

BreizhHardware commented

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

Author

Owner

@Keybored02 commented on GitHub (May 1, 2026):

The current filament stock workflow assumes a single tag per spool regardless of filament, which means you will be using a different NFC tag per spool even though they are the exact same spool.

They are definitely not the same spool. Each spool has to be uniquely identified, be it via ID or NFC. You can reuse tags once one spool is depleted and removed form inventory (or untagged). If two physical spools share the same tag and get swapped out between prints, there's no way to know which one is currently loaded, so the weight attribution becomes unreliable.

would benefit from being able to track spool duplicates without having to register each spool with a different NFC tag.

Tracking by unique ID already is in the logic. Not sure how'd you want to track identical spools in the real world without any uniquely identifying system.

I do not see the need for a bulk rework, as here it's purely a tagging/identification issues that stems from your specific use case.

@Keybored02 commented on GitHub (May 1, 2026): > The current filament stock workflow assumes a single tag per spool regardless of filament, which means you will be using a different NFC tag per spool even though they are the exact same spool. They are definitely not the same spool. Each spool has to be uniquely identified, be it via ID or NFC. You can reuse tags once one spool is depleted and removed form inventory (or untagged). If two physical spools share the same tag and get swapped out between prints, there's no way to know which one is currently loaded, so the weight attribution becomes unreliable. > would benefit from being able to track spool duplicates without having to register each spool with a different NFC tag. Tracking by unique ID already is in the logic. Not sure how'd you want to track identical spools in the real world without any uniquely identifying system. I do not see the need for a bulk rework, as here it's purely a tagging/identification issues that stems from your specific use case.

BreizhHardware referenced this issue

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

[PR #749] [CLOSED] Add more Home Assistant notification options #1107