Thanks, Tom, this is EXTREMELY helpful! I appreciate you doing this testing and providing all these logs from your 2 AMS setup.
I’m busy the next few days but will try to push a fix later this week or this weekend and will post back here when I have a fix sorted out. Thanks again!!
I’ve just pushed updates that address both issues you reported.
Problem: When you cancelled a print and then manually unloaded the filament, the accumulated usage wasn’t being logged.
Root cause: The automation was checking if the printer stage was in ['printing', 'prepare', 'pause'] before logging usage on a tray change. When you cancelled and the stage went to 'idle', then unloaded the spool, it skipped logging because it thought you were just doing an idle spool swap.
Fix: Removed the stage check entirely. If there’s accumulated weight on the utility meter when a tray change occurs, that weight represents real filament consumption and should be logged - regardless of what the current printer stage is. The usage is now captured either at the moment you cancel (via PRINT END trigger) or when you unload the spool (via TRAY CHANGE trigger).
Problem: Only AMS1 trays (1-4) were being tracked. Prints from AMS2, AMS3, or AMS4 would incorrectly report usage from AMS1 trays.
Root cause: The config generator was hardcoding ams_1 in multiple places and completely ignoring any additional AMS units discovered during printer setup.
Fix: Complete rewrite of the automation generator to support up to 4 AMS units. Now uses a composite ID encoding scheme:
0 = external spool11-14 = AMS1 trays 1-421-24 = AMS2 trays 1-431-34 = AMS3 trays 1-441-44 = AMS4 trays 1-4The generator now iterates through all discovered AMS units and uses the actual entity IDs from your Home Assistant, so it will correctly handle any entity naming suffixes too.
The embedded Home Assistant instance now uses ha-bambulab v2.2.20-beta2, which includes a fix for empty tray detection. This should no longer be an issue.
Let me know if you run into any other issues. Thanks again for the thorough testing!
Hi, I’ve Installed the external version, setup in the interface went fine, HA and Spoolman connect without problems, and the printer shows up in the settings.
The issue is I can’t create any automations, I just get the error “No Bambu Lab printers found. Please ensure ha-bambulab is configured.”
SpoolmanSync is authorized in HA, the bambulab-ha extension works fine (printer is available and can be controlled), no errors from docker logs, no errors through the activity logs.
The only thing I changed in the compose file is a bind for the port, as the 3000 was already used by another container. Shouldn’t be an issue as everything works fine with the bind.
I’m on the latest (9bf7d0e) pull of the repo and ha-bambulab v2.2.20-beta2.
If you need any additional log, let me know.
Is there any chance you’re running Home Assistant in a language other than English?
I just resolved a similar issue (No Printers Found on Dashboard · Issue #3 · gibz104/SpoolmanSync · GitHub) where the ha-bambulab integration translates entity IDs based on your HA language setting, causing SpoolmanSync to not find the printer.
If you are using a non-English language:
Thanks, that worked (I’ve should have checked the github issues first).
Unfortunately, the filament usage isn’t tracked. I tried with two spools, three different prints. The automation runs when it should, but it doesn’t return any weight. You can find the two traces for Update Spool here: SpoolmanSync Traces - Pastebin.com
I think it’s reading the weight value after utility_meter is set to 0.
Let me know if you need anything else.
EDIT: found it, it was the localization again. Fixed it manually. I’ve just seen that you already fixed in source. Man, I really need to start reading issues fully.
All good! It was just a timing issue – I was troubleshooting both at the same time! 
Thanks for trying the app out! Let me know if you come across any other issues.
Quick update after testing:
Working Great
Issues FoundEmpty Tray Detection (Runtime)
What I did:
Feature Request (Optional)Activity Log of SpoolmanSync: Show all tray changes
Currently only logs when SpoolmanSync takes action. Would be helpful to see ALL detected tray change events (even without auto-assignment) directly in SpoolmanSync instead of checking Portainer/HA logs. But it’s only nice-to-have.
Still testing: Aborted prints workflow. “Unfortunately” I didn’t have to abort a print in the last view days.
Thanks again.
Awesome project!
Thanks for the detailed feedback!
Feature Request Implemented
I’ve updated SpoolmanSync to now log ALL tray change events in the Logs tab - including empty tray detections even when no action is taken. There’s also a new “Tray Changes” filter to easily see just these events. This should make debugging much easier.
Empty Tray Detection Issue
I wasn’t able to reproduce this on my end - when I remove a spool, SpoolmanSync correctly detects it as empty. This suggests the issue is likely on the Home Assistant side where ha-bambulab isn’t updating the tray entity to “Empty” during runtime.
To confirm: next time this happens, can you check HA → Developer Tools → States and search for the tray entity (e.g., sensor.xxx_ams_1_tray_4)? If the name attribute still shows the old filament name instead of “Empty”, then ha-bambulab isn’t clearing the tray data properly.
Let me know what you find and we can go from there!
Cool that you picked up the idea! I didnt have the time to develop it any further. I will test it tomorrow
Thanks Marco – I appreciate your feedback!
Is a NFC tag read thing an idea? I have loads of unused nfc tags. And the Bambu spools have NFC tags right?
Bambu Integration broken after update?
After pulling the latest version, Home Assistant fails to load the Bambu Lab integration:
Error:
2026-02-07 13:53:43.805 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry 00M09A391700764 for bambu_lab
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 762, in __async_setup_with_context
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/bambu_lab/__init__.py", line 433, in async_setup_entry
await cards.async_register()
File "/config/custom_components/bambu_lab/frontend/__init__.py", line 40, in async_register
if self.lovelace_mode == "storage":
^^^^^^^^^^^^^^^^^^
File "/config/custom_components/bambu_lab/frontend/__init__.py", line 26, in lovelace_mode
return self.hass.data["lovelace"].mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'LovelaceData' object has no attribute 'mode'
AttributeError: 'LovelaceData' object has no attribute 'mode'
File: /config/custom_components/bambu_lab/frontend/__init__.py, line 26
I tried to remove and add the printer again. But it doesn’t fix the problem.
Rolled back to:
Used SHA256 digests to rollback to last known working version:
sha256:6725c623a4228d174ec43f671e25e0e9e61e865a8ed7988c5d420cc83b8ba83csha256:3e2959af87c88480f6431623bc5b8fbd8bd45db8b2e8b611f87d5bcc12b460c6Printer connection works again.
This is a known compatibility issue between Home Assistant 2026.2 and older versions of ha-bambulab.
What happened: HA 2026.2 changed its Lovelace API, breaking ha-bambulab versions prior to v2.2.20. The fix was released in ha-bambulab v2.2.20 on Feb 5.
Relevant issues:
SpoolmanSync’s latest image (pushed Feb 6) includes ha-bambulab v2.2.20 with the fix. Simply pull the latest image:
docker compose pull
docker compose up -d
To confirm you’re on an older version causing this issue, check your ha-bambulab version:
After updating SpoolmanSync, the bundled ha-bambulab will be v2.2.20+ which is compatible with HA 2026.2.
NFC tag support isn’t planned for the immediate future, but it’s something I’d consider adding down the road.
Regarding Bambu Lab’s built-in spool tags: Unfortunately, these aren’t usable with a phone. While Bambu calls them “RFID,” they’re actually MiFare 13.56MHz tags that are both encrypted and digitally signed with RSA. Standard smartphone NFC readers can’t decrypt them—you’d need specialized hardware like a Proxmark3 or Flipper Zero. Even then, the data is signed with Bambu’s private key, so you can clone an existing tag but can’t create or modify custom ones. More details here: GitHub - Bambu-Research-Group/RFID-Tag-Guide: Instructions on how to read out the bambulab nfc tags
What NFC support could look like: Similar to the existing QR code workflow, but with blank NFC stickers. You’d write a Spoolman spool ID or URL to a cheap NFC sticker, attach it to your spool, then scan it with your phone on SpoolmanSync’s Scan page. This would work for any filament brand, not just Bambu. It’s essentially the same concept as QR codes but with the convenience of NFC tap-to-scan.
If there’s enough interest, I’ll bump this up the priority list!
Hi 
,
First of all, thanks a lot for your work. This looks really promising.
I’m still running into a small issue where your frontend doesn’t detect the AMS.
From the logs:
Prefix "schiller" found no AMS, using device-based fallback...
Device fallback: 43 total entities, 0 AMS units
I’m using a Bambu A1 with the AMS Lite, where entities are named like prefix_ams_tray_1, i.e. the first tray index is named: sensor.schiller_ams_tray_1.
Latest image does not contain ha-bambulab v2.2.20 fix
I’ve verified the SHA256 digests - I am pulling the correct latest images from GitHub:
Images pulled:
ghcr.io/gibz104/spoolmansync-homeassistant@sha256:fae61b8354d30616ed32ffae8b551b44e77504b9c911ae6af32b9cd4f46ebfd0ghcr.io/gibz104/spoolmansync@sha256:d03595d0e7d4025bfe264a801f8ea7047e8ef1a4ba96fce953529ae2da961c5eThese match the latest tags published on GitHub Container Registry 15 hours ago.
I logged into HA and checked the ha-bambulab version.
It is still version 2.2.19
I think the Feb 6 image published to GitHub does not contain ha-bambulab v2.2.20.
Could you please have a look at this?
Thanks for reporting this! You’re right - the A1’s AMS Lite uses _ams_tray_1 without a number, while X1C/P1 use _ams_1_tray_1. The detection patterns weren’t handling this.
I just pushed a fix. Pull the latest image and your AMS should be detected:
docker compose pull
docker compose --profile embedded up -d # or external
Let me know if it works!
Interesting - I pulled those exact SHA256 digests on a fresh VM and they’re showing HA 2026.2.1 with ha-bambulab 2.2.20. The Dockerfile pulls from releases/latest/download/bambu_lab.zip, so it grabs whatever version was latest at build time.
That said, I just pushed some updates so a new build has run. Try pulling the fresh images and make sure no cached layers are interfering:
# Stop containers
docker compose --profile embedded down
# Remove old images to force fresh pull
docker rmi ghcr.io/gibz104/spoolmansync:latest
docker rmi ghcr.io/gibz104/spoolmansync-homeassistant:latest
# Pull and start fresh
docker compose -f docker-compose.prebuilt.yml --profile embedded pull
docker compose -f docker-compose.prebuilt.yml --profile embedded up -d
I’m planning to push the first official release soon, which will add stable version tags. That should make updates smoother for existing users going forward.
Thanks for the quick fix, the AMS lite assignments work as well now!
Issue resolved
After completely recreating the volumes, everything works perfectly now!
Root cause:
I didn’t delete the mounted volume. So the old homeassistant-data volume on my NAS contained ha-bambulab v2.2.19 in custom_components/bambu_lab/. Even though I pulled the fresh images with v2.2.20, Docker’s volume behavior meant the old integration files persisted and were never replaced.
Docker does not update existing files on volume during the update
This is why you saw v2.2.20 on a fresh VM, I had the correct SHA256 digests but still had v2.2.19 inside the container (old volume files)
Would be awesome