mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 13:45:32 +02:00
[GH-ISSUE #479] [Bug]: Auto-configuration of AMS filament slot via filament assignment falls back to Generic instead of selected filament #298
Labels
No labels
A1
automated
automated
bug
bug
Closed due to inactivity
contrib
dependencies
dependencies
duplicate
enhancement
feedback
hold
invalid
Notes
P1S
pull-request
security
security
ThumbsUp
user-report
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/bambuddy#298
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @pichler583-cell on GitHub (Feb 21, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/479
Originally assigned to: @maziggy on GitHub.
Bug Description
The automatic configuration of an AMS slot does not work correctly when assigning a filament via the filament assignment workflow.
When selecting and assigning a specific filament to an AMS slot, the system always falls back to Generic instead of applying the selected filament profile.
However, if the same slot is configured manually using the “Configure” button afterward, the correct filament and profile are applied successfully.
Expected Behavior
The selected filament and its assigned profile should automatically be applied to the AMS slot.
Steps to Reproduce
Printer Model
P2S
Bambuddy Version
0.2.1b2
Printer Firmware Version
01.01.01.00
Installation Method
Manual (git clone)
Operating System
Docker
Relevant Logs / Support Package
Screenshots
bambuddy-support-20260221-115252.zip
Additional Context
No response
Checklist
@maziggy commented on GitHub (Feb 21, 2026):
Thanks for reporting this! I looked through the support package logs but unfortunately the debug logging captured MQTT status polling and cloud API calls — there's no actual spool assignment attempt recorded during that time window. The bug likely occurred before debug logging was enabled.
From the code, I can see why this might happen:
When you assign a spool to an AMS slot via the inventory assignment, the system uses the spool's stored slicer_filament field to determine which filament preset to send to the printer. If that field is empty (which is common for manually created spools), it falls back to a generic filament ID like GFL99 (Generic PLA), GFG99 (Generic PETG), etc.
The manual "Configure" button works because you're explicitly selecting the filament profile in the dropdown, and the frontend sends that specific preset directly.
Could you help me confirm this?
If the spool's filament preset field is indeed empty, that would explain the behavior — and I can look into improving the assignment flow to better resolve the correct preset.
Separate note: The logs also show all 7 cloud filament preset lookups (P37d2b68, P1464538, etc.) returning HTTP 400 from the Bambu Cloud API. This doesn't affect slot configuration directly, but it means Bambuddy can't resolve preset names for display. Are you logged into your Bambu Cloud account in Bambuddy's settings or imported your custom slicer profiles under profiles -> local profiles?
@pichler583-cell commented on GitHub (Feb 21, 2026):
The profiles are connected (see screenshot), and the ABS profile is properly linked. I also tested this with different filaments — including an original Bambu ABS filament with the official Bambu ABS preset assigned.
Even in that case, assigning the spool via the inventory assignment still results in Generic being applied to the AMS slot.
So the slicer_filament field should not be empty in these cases.
I’ve now reproduced the issue again with debug logging enabled beforehand.
In the new support package, I manually assigned two filaments:
One Bambu filament
One Sunlu filament
Both should already have had proper presets assigned before the test.
I hope this time the ams_set_filament_setting MQTT command is captured properly in the logs.
Regarding the HTTP 400 errors for the cloud preset lookups:
I am logged into my Bambu Cloud account, and I created the filaments after the cloud connection was already active. So the login state should be valid.
Let me know if you need anything specific extracted from the logs.
bambuddy-support-20260221-123009.zip
@maziggy commented on GitHub (Feb 21, 2026):
Inventory says color gray and slot config shows blue. Why is that?
@pichler583-cell commented on GitHub (Feb 21, 2026):
Sorry — attaching two additional screenshots for clarification:
One showing the Blue ABS profile correctly linked
One showing the Sunlu profile assigned
Both profiles are properly set on the spool, but when assigning via inventory, the AMS slot still falls back to Generic.
Let me know if you need anything else.
@maziggy commented on GitHub (Feb 21, 2026):
Now you begin again to mix different topics!
You reported the issue for non Bambu Lab spools and now you are talking about Bambu Lab spools. That's very confusing!
For the Bambu Lab spool please do the following (there's no need to manually configure anything for BL spools!):
After that the AMS slot should re-read the RFID tag and the slot is auto-configured.
That's for Bambu Lab spools.
@pichler583-cell commented on GitHub (Feb 21, 2026):
I only used the Bambu spool to rule out any issue with my custom profile.
So this was specifically to exclude the possibility that the problem is related to a self-created preset. Even with the official Bambu preset assigned, the AMS slot still falls back to Generic when using the inventory assignment.
@maziggy commented on GitHub (Feb 21, 2026):
Why do you assign a bambu lab spool to the inventory? That doesn't makes sense at all.
@pichler583-cell commented on GitHub (Feb 21, 2026):
It’s not about the Bambu spool.
No matter which filament profile I assign to a spool in the inventory, it is not applied when assigning the spool to the AMS slot.
@maziggy commented on GitHub (Feb 21, 2026):
Oh Boy....please. This is the third ticket you crushed. You provide inconsistent debug informations. How shall that work? I alreayd wasted much time for issues, because you provided incorrect details. Sorry, but that's not acceptable.