viewit/KX-Bridge-Release
12
18
Fork 11
Code Issues 6 Pull Requests Actions Packages Projects Releases 80 Wiki Activity

ACE 2 Pro Unit Profile Assignment Failure: AttributeError on multiColorBox/report #100

New Issue
Open
opened 2026-07-23 21:31:16 +02:00 by Blaim · 9 comments
Blaim commented 2026-07-23 21:31:16 +02:00
Copy Link

Description

This might be a bit niche or very specific work flow but
After connecting a new ACE Unit, the bridge does not automatically pull the correct Vendor and Filament type/Material (e.g., GEEETECH / Anycubic PLA) into the ACE view slots. Furthermore, when attempting to select the profile manually, the bridge throws a Python AttributeError in the MQTT callback and fails to update the slot.

Additional Context:

  • Custom RFID Tags: I am using custom/third-party filament (Geeetech) where I used ACE RFID (ANdroid App) to manually write the filament data onto an RFID tag. It never inserts Brand and Type for those into the Toolhead aswell, might need an additional bug report.
  • Presets Uploaded: I have already imported my custom OrcaSlicer presets into the bridge via the ZIP method.
  • Sync Impact: Because the bridge cannot correctly display or assign these slots, the AMS/filament sync in OrcaSlicer also fails for these specific colors and materials.
  • Toolhead vs. ACE: Interestingly, automatic and manual profile assignment works perfectly fine for the toolhead, but crashes specifically when trying to apply it to the ACE unit slots.
  • Only officiasl filament: Happems also if I just use Anycubic Filament

Steps to Reproduce

  1. Connect an Anycubic ACE 2 Pro Unit to the printer.
  2. Open the KX-Bridge UI and navigate to the ACE/multicolor view.
  3. Observe that the slot information (Vendor, Material) does not automatically populate for the GEEETECH PLA BAS profile and it just displays the name. Same also goes for Anycubic Filament.
  4. Attempt to manually select the profile for the slot.
  5. Observe the callback error.

Expected Behavior

The ACE view should automatically parse and display the correct Vendor and Filament Material from the OrcaSlicer profile. Manually selecting or assigning a profile to a slot should succeed without crashing the MQTT callback.

Actual Behavior

The slot details remain empty/incorrect, and attempting to manually assign the profile triggers a Python exception ('list' object has no attribute 'get') handling the multiColorBox/report MQTT payload.
image.png image.png
image.png
image.png

Environment

  • KX-Bridge Version: v0.9.28-nightly40
  • OrcaSlicer Version: -
  • Moonraker/Klipper Version: -
  • Operating System: Linux
  • Installation: Docker (Proxmox LXC / OCI)

Logs

19:11:35[bridge] [Printer 1] Connecting to 192.168.2.144:9883...
19:11:35[kobrax.mqtt] TLS connected cipher=TLS_AES_256_GCM_SHA384
19:11:35[kobrax.mqtt] CONNACK rc=0
19:11:35[kobrax.mqtt] SUB anycubic/anycubicCloud/v1/printer/public/20030/66d5f9ab96791b4c71d348779a3565f5/#
19:11:35[bridge] [Printer 1] MQTT connected
19:11:35[bridge] OrcaSlicer → Klipper → http://192.168.2.188:7125
19:11:35[bridge] Press Ctrl-C to stop
19:11:35[kobrax.mqtt] RX 66d5f9ab96791b4c71d348779a3565f5/response state= data=null
19:11:35[kobrax.mqtt] RX info/report state=done data={"aux_fan_speed_pct": 0, "fan_speed_pct": 0, "features": {"auto_leveling_support": true, "camera_timelapse_support": true, "delete_batch_support": true, "drying_first_support": false, "flow_calibration_support": true, "fod_support": true, "gcode_3mf_support": true, "keep_print_head_temp_support": true, "pre_cancel_support": true, "preheating_support": true, "shengwang_rdt_support": true, "shengwang_rtc_support": true, "vibration_compensation_support": true}, "ip": "192.168.2.144", "last_project": null, "model": "Anycubic Kobra X", "print_speed_mode": 2, "printerName": "Anycubic Kobra X", "project": null, "state": "free", "temp": {"curr_hotbed_temp": 26, "curr_nozzle_temp": 30, "target_hotbed_temp": 0, "target_nozzle_temp": 0}, "urls": {"fileUploadurl": "http://192.168.2.144:18910/gcode_upload?s=vO9pOQK9vL", "rtspUrl": "http://192.168.2.144:18088/live/OXUeAKm5"}, "version": "1.2.0.2"}
19:11:35[kobrax.mqtt] RX multiColorBox/report state=success data={"head_tools_model": 1, "multi_color_box": [{"auto_feed": 1, "drying_status": {"duration": 0, "remain_time": 0, "status": 0, "target_temp": 0}, "feed_status": {"code": 200, "current_status": -1, "slot_index": -1, "type": -1}, "humidity": 0, "id": -1, "loaded_slot": -1, "model_id": 40002, "slots": [{"color": [14, 191, 116], "color_group": [[14, 191, 116, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 0, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [222, 226, 231], "color_group": [[222, 226, 231, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 1, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [33, 39, 33], "color_group": [[33, 39, 33, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 2, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [0, 156, 189], "color_group": [[0, 156, 189, 255]], "consumables_percent": 0, "edit_status": 3, "icon_type": 0, "index": 3, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}], "status": 1, "temp": 0}, {"auto_feed": 1, "drying_status": {"duration": 0, "remain_time": 0, "status": 0, "target_temp": 0}, "feed_status": {"code": 200, "current_status": -1, "slot_index": -1, "type": -1}, "humidity": 49, "id": 0, "loaded_slot": -1, "model_id": 40002, "slots": [{"color": [0, 156, 189], "color_group": [[0, 156, 189, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 0, "sku": "HPL18-107", "status": 5, "type": "PLA", "weight": 1000}, {"color": [0, 150, 57], "color_group": [[0, 150, 57, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 1, "sku": "AHPLCG-107", "status": 5, "type": "PLA", "weight": 1000}, {"color": [238, 190, 152], "color_group": [[238, 190, 152, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 2, "sku": "", "status": 5, "type": "GEEETECH PLA Bas", "weight": 1000}, {"color": [33, 39, 33], "color_group": [[33, 39, 33, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 3, "sku": "AHPLBK-107", "status": 5, "type": "PLA", "weight": 1000}], "status": 1, "temp": 27}]}
19:15:30[bridge] AMS slots received: 7, loaded_slot=-1 (×77)
19:15:31[kobrax.mqtt] TX(web) multiColorBox/request action=setInfo data={"multi_color_box": [{"id": 0, "slots": [{"index": 2, "type": "PLA", "color": [238, 190, 152]}]}]}
19:15:31[bridge] setInfo (web) global=5 box=0 local_slot=2 type=PLA color=[238, 190, 152]
19:15:31[kobrax.mqtt] RX multiColorBox/report state=failed data=["multi_color_box", [{"filaments": {"id": 2}, "id": 0}]]
19:15:31[kobrax.mqtt] callback error for multiColorBox/report: 'list' object has no attribute 'get'
19:15:33[kobrax.mqtt] RX multiColorBox/report state=success data={"head_tools_model": 1, "multi_color_box": [{"auto_feed": 1, "drying_status": {"duration": 0, "remain_time": 0, "status": 0, "target_temp": 0}, "feed_status": {"code": 200, "current_status": -1, "slot_index": -1, "type": -1}, "humidity": 0, "id": -1, "loaded_slot": -1, "model_id": 40002, "slots": [{"color": [14, 191, 116], "color_group": [[14, 191, 116, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 0, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [222, 226, 231], "color_group": [[222, 226, 231, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 1, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [33, 39, 33], "color_group": [[33, 39, 33, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 2, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [0, 156, 189], "color_group": [[0, 156, 189, 255]], "consumables_percent": 0, "edit_status": 3, "icon_type": 0, "index": 3, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}], "status": 1, "temp": 0}, {"auto_feed": 1, "drying_status": {"duration": 0, "remain_time": 0, "status": 0, "target_temp": 0}, "feed_status": {"code": 200, "current_status": -1, "slot_index": -1, "type": -1}, "humidity": 49, "id": 0, "loaded_slot": -1, "model_id": 40002, "slots": [{"color": [0, 156, 189], "color_group": [[0, 156, 189, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 0, "sku": "HPL18-107", "status": 5, "type": "PLA", "weight": 1000}, {"color": [0, 150, 57], "color_group": [[0, 150, 57, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 1, "sku": "AHPLCG-107", "status": 5, "type": "PLA", "weight": 1000}, {"color": [238, 190, 152], "color_group": [[238, 190, 152, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 2, "sku": "", "status": 5, "type": "GEEETECH PLA Bas", "weight": 1000}, {"color": [33, 39, 33], "color_group": [[33, 39, 33, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 3, "sku": "AHPLBK-107", "status": 5, "type": "PLA", "weight": 1000}], "status": 1, "temp": 27}]}
19:15:39[bridge] AMS slots received: 7, loaded_slot=-1 (×3)
19:15:40[kobrax.mqtt] TX(web) multiColorBox/request action=setInfo data={"multi_color_box": [{"id": 0, "slots": [{"index": 3, "type": "PLA", "color": [33, 39, 33]}]}]}
19:15:40[bridge] setInfo (web) global=6 box=0 local_slot=3 type=PLA color=[33, 39, 33]
19:15:41[kobrax.mqtt] RX multiColorBox/report state=failed data=["multi_color_box", [{"filaments": {"id": 3}, "id": 0}]]
19:15:41[kobrax.mqtt] callback error for multiColorBox/report: 'list' object has no attribute 'get'
19:15:42[kobrax.mqtt] RX multiColorBox/report state=success data={"head_tools_model": 1, "multi_color_box": [{"auto_feed": 1, "drying_status": {"duration": 0, "remain_time": 0, "status": 0, "target_temp": 0}, "feed_status": {"code": 200, "current_status": -1, "slot_index": -1, "type": -1}, "humidity": 0, "id": -1, "loaded_slot": -1, "model_id": 40002, "slots": [{"color": [14, 191, 116], "color_group": [[14, 191, 116, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 0, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [222, 226, 231], "color_group": [[222, 226, 231, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 1, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [33, 39, 33], "color_group": [[33, 39, 33, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 2, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [0, 156, 189], "color_group": [[0, 156, 189, 255]], "consumables_percent": 0, "edit_status": 3, "icon_type": 0, "index": 3, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}], "status": 1, "temp": 0}, {"auto_feed": 1, "drying_status": {"duration": 0, "remain_time": 0, "status": 0, "target_temp": 0}, "feed_status": {"code": 200, "current_status": -1, "slot_index": -1, "type": -1}, "humidity": 49, "id": 0, "loaded_slot": -1, "model_id": 40002, "slots": [{"color": [0, 156, 189], "color_group": [[0, 156, 189, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 0, "sku": "HPL18-107", "status": 5, "type": "PLA", "weight": 1000}, {"color": [0, 150, 57], "color_group": [[0, 150, 57, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 1, "sku": "AHPLCG-107", "status": 5, "type": "PLA", "weight": 1000}, {"color": [238, 190, 152], "color_group": [[238, 190, 152, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 2, "sku": "", "status": 5, "type": "GEEETECH PLA Bas", "weight": 1000}, {"color": [33, 39, 33], "color_group": [[33, 39, 33, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 3, "sku": "AHPLBK-107", "status": 5, "type": "PLA", "weight": 1000}], "status": 1, "temp": 27}]}
19:15:52[bridge] AMS slots received: 7, loaded_slot=-1 (×8)
## Description This might be a bit niche or very specific work flow but After connecting a new ACE Unit, the bridge does not automatically pull the correct Vendor and Filament type/Material (e.g., GEEETECH / Anycubic PLA) into the ACE view slots. Furthermore, when attempting to select the profile manually, the bridge throws a Python `AttributeError` in the MQTT callback and fails to update the slot. **Additional Context:** * **Custom RFID Tags:** I am using custom/third-party filament (Geeetech) where I used ACE RFID (ANdroid App) to manually write the filament data onto an RFID tag. It never inserts Brand and Type for those into the Toolhead aswell, might need an additional bug report. * **Presets Uploaded:** I have already imported my custom OrcaSlicer presets into the bridge via the ZIP method. * **Sync Impact:** Because the bridge cannot correctly display or assign these slots, the AMS/filament sync in OrcaSlicer also fails for these specific colors and materials. * **Toolhead vs. ACE:** Interestingly, automatic and manual profile assignment works perfectly fine for the **toolhead**, but crashes specifically when trying to apply it to the **ACE unit slots**. * **Only officiasl filament:** Happems also if I just use Anycubic Filament ## Steps to Reproduce 1. Connect an Anycubic ACE 2 Pro Unit to the printer. 2. Open the KX-Bridge UI and navigate to the ACE/multicolor view. 3. Observe that the slot information (Vendor, Material) does not automatically populate for the GEEETECH PLA BAS profile and it just displays the name. Same also goes for Anycubic Filament. 4. Attempt to manually select the profile for the slot. 5. Observe the callback error. ## Expected Behavior The ACE view should automatically parse and display the correct Vendor and Filament Material from the OrcaSlicer profile. Manually selecting or assigning a profile to a slot should succeed without crashing the MQTT callback. ## Actual Behavior The slot details remain empty/incorrect, and attempting to manually assign the profile triggers a Python exception (`'list' object has no attribute 'get'`) handling the `multiColorBox/report` MQTT payload. <img width="255" alt="image.png" src="attachments/c1939aa8-58f1-4f45-a086-0932aeb5116f"> <img width="272" alt="image.png" src="attachments/12ea8c47-0dc9-4e75-90a7-cda979d8fa36"> <img width="264" alt="image.png" src="attachments/49c13f0c-9779-472c-8ca6-2da4d695956e"> <img width="254" alt="image.png" src="attachments/bcfa7975-7bea-4883-a886-828fd7136ade"> ## Environment - KX-Bridge Version: v0.9.28-nightly40 - OrcaSlicer Version: - - Moonraker/Klipper Version: - - Operating System: Linux - Installation: Docker (Proxmox LXC / OCI) ## Logs ``` 19:11:35[bridge] [Printer 1] Connecting to 192.168.2.144:9883... 19:11:35[kobrax.mqtt] TLS connected cipher=TLS_AES_256_GCM_SHA384 19:11:35[kobrax.mqtt] CONNACK rc=0 19:11:35[kobrax.mqtt] SUB anycubic/anycubicCloud/v1/printer/public/20030/66d5f9ab96791b4c71d348779a3565f5/# 19:11:35[bridge] [Printer 1] MQTT connected 19:11:35[bridge] OrcaSlicer → Klipper → http://192.168.2.188:7125 19:11:35[bridge] Press Ctrl-C to stop 19:11:35[kobrax.mqtt] RX 66d5f9ab96791b4c71d348779a3565f5/response state= data=null 19:11:35[kobrax.mqtt] RX info/report state=done data={"aux_fan_speed_pct": 0, "fan_speed_pct": 0, "features": {"auto_leveling_support": true, "camera_timelapse_support": true, "delete_batch_support": true, "drying_first_support": false, "flow_calibration_support": true, "fod_support": true, "gcode_3mf_support": true, "keep_print_head_temp_support": true, "pre_cancel_support": true, "preheating_support": true, "shengwang_rdt_support": true, "shengwang_rtc_support": true, "vibration_compensation_support": true}, "ip": "192.168.2.144", "last_project": null, "model": "Anycubic Kobra X", "print_speed_mode": 2, "printerName": "Anycubic Kobra X", "project": null, "state": "free", "temp": {"curr_hotbed_temp": 26, "curr_nozzle_temp": 30, "target_hotbed_temp": 0, "target_nozzle_temp": 0}, "urls": {"fileUploadurl": "http://192.168.2.144:18910/gcode_upload?s=vO9pOQK9vL", "rtspUrl": "http://192.168.2.144:18088/live/OXUeAKm5"}, "version": "1.2.0.2"} 19:11:35[kobrax.mqtt] RX multiColorBox/report state=success data={"head_tools_model": 1, "multi_color_box": [{"auto_feed": 1, "drying_status": {"duration": 0, "remain_time": 0, "status": 0, "target_temp": 0}, "feed_status": {"code": 200, "current_status": -1, "slot_index": -1, "type": -1}, "humidity": 0, "id": -1, "loaded_slot": -1, "model_id": 40002, "slots": [{"color": [14, 191, 116], "color_group": [[14, 191, 116, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 0, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [222, 226, 231], "color_group": [[222, 226, 231, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 1, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [33, 39, 33], "color_group": [[33, 39, 33, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 2, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [0, 156, 189], "color_group": [[0, 156, 189, 255]], "consumables_percent": 0, "edit_status": 3, "icon_type": 0, "index": 3, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}], "status": 1, "temp": 0}, {"auto_feed": 1, "drying_status": {"duration": 0, "remain_time": 0, "status": 0, "target_temp": 0}, "feed_status": {"code": 200, "current_status": -1, "slot_index": -1, "type": -1}, "humidity": 49, "id": 0, "loaded_slot": -1, "model_id": 40002, "slots": [{"color": [0, 156, 189], "color_group": [[0, 156, 189, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 0, "sku": "HPL18-107", "status": 5, "type": "PLA", "weight": 1000}, {"color": [0, 150, 57], "color_group": [[0, 150, 57, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 1, "sku": "AHPLCG-107", "status": 5, "type": "PLA", "weight": 1000}, {"color": [238, 190, 152], "color_group": [[238, 190, 152, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 2, "sku": "", "status": 5, "type": "GEEETECH PLA Bas", "weight": 1000}, {"color": [33, 39, 33], "color_group": [[33, 39, 33, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 3, "sku": "AHPLBK-107", "status": 5, "type": "PLA", "weight": 1000}], "status": 1, "temp": 27}]} 19:15:30[bridge] AMS slots received: 7, loaded_slot=-1 (×77) 19:15:31[kobrax.mqtt] TX(web) multiColorBox/request action=setInfo data={"multi_color_box": [{"id": 0, "slots": [{"index": 2, "type": "PLA", "color": [238, 190, 152]}]}]} 19:15:31[bridge] setInfo (web) global=5 box=0 local_slot=2 type=PLA color=[238, 190, 152] 19:15:31[kobrax.mqtt] RX multiColorBox/report state=failed data=["multi_color_box", [{"filaments": {"id": 2}, "id": 0}]] 19:15:31[kobrax.mqtt] callback error for multiColorBox/report: 'list' object has no attribute 'get' 19:15:33[kobrax.mqtt] RX multiColorBox/report state=success data={"head_tools_model": 1, "multi_color_box": [{"auto_feed": 1, "drying_status": {"duration": 0, "remain_time": 0, "status": 0, "target_temp": 0}, "feed_status": {"code": 200, "current_status": -1, "slot_index": -1, "type": -1}, "humidity": 0, "id": -1, "loaded_slot": -1, "model_id": 40002, "slots": [{"color": [14, 191, 116], "color_group": [[14, 191, 116, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 0, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [222, 226, 231], "color_group": [[222, 226, 231, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 1, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [33, 39, 33], "color_group": [[33, 39, 33, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 2, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [0, 156, 189], "color_group": [[0, 156, 189, 255]], "consumables_percent": 0, "edit_status": 3, "icon_type": 0, "index": 3, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}], "status": 1, "temp": 0}, {"auto_feed": 1, "drying_status": {"duration": 0, "remain_time": 0, "status": 0, "target_temp": 0}, "feed_status": {"code": 200, "current_status": -1, "slot_index": -1, "type": -1}, "humidity": 49, "id": 0, "loaded_slot": -1, "model_id": 40002, "slots": [{"color": [0, 156, 189], "color_group": [[0, 156, 189, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 0, "sku": "HPL18-107", "status": 5, "type": "PLA", "weight": 1000}, {"color": [0, 150, 57], "color_group": [[0, 150, 57, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 1, "sku": "AHPLCG-107", "status": 5, "type": "PLA", "weight": 1000}, {"color": [238, 190, 152], "color_group": [[238, 190, 152, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 2, "sku": "", "status": 5, "type": "GEEETECH PLA Bas", "weight": 1000}, {"color": [33, 39, 33], "color_group": [[33, 39, 33, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 3, "sku": "AHPLBK-107", "status": 5, "type": "PLA", "weight": 1000}], "status": 1, "temp": 27}]} 19:15:39[bridge] AMS slots received: 7, loaded_slot=-1 (×3) 19:15:40[kobrax.mqtt] TX(web) multiColorBox/request action=setInfo data={"multi_color_box": [{"id": 0, "slots": [{"index": 3, "type": "PLA", "color": [33, 39, 33]}]}]} 19:15:40[bridge] setInfo (web) global=6 box=0 local_slot=3 type=PLA color=[33, 39, 33] 19:15:41[kobrax.mqtt] RX multiColorBox/report state=failed data=["multi_color_box", [{"filaments": {"id": 3}, "id": 0}]] 19:15:41[kobrax.mqtt] callback error for multiColorBox/report: 'list' object has no attribute 'get' 19:15:42[kobrax.mqtt] RX multiColorBox/report state=success data={"head_tools_model": 1, "multi_color_box": [{"auto_feed": 1, "drying_status": {"duration": 0, "remain_time": 0, "status": 0, "target_temp": 0}, "feed_status": {"code": 200, "current_status": -1, "slot_index": -1, "type": -1}, "humidity": 0, "id": -1, "loaded_slot": -1, "model_id": 40002, "slots": [{"color": [14, 191, 116], "color_group": [[14, 191, 116, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 0, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [222, 226, 231], "color_group": [[222, 226, 231, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 1, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [33, 39, 33], "color_group": [[33, 39, 33, 255]], "consumables_percent": 100, "edit_status": 1, "icon_type": 0, "index": 2, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}, {"color": [0, 156, 189], "color_group": [[0, 156, 189, 255]], "consumables_percent": 0, "edit_status": 3, "icon_type": 0, "index": 3, "sku": "AHPLBK-101", "status": 5, "type": "PLA", "weight": 1000}], "status": 1, "temp": 0}, {"auto_feed": 1, "drying_status": {"duration": 0, "remain_time": 0, "status": 0, "target_temp": 0}, "feed_status": {"code": 200, "current_status": -1, "slot_index": -1, "type": -1}, "humidity": 49, "id": 0, "loaded_slot": -1, "model_id": 40002, "slots": [{"color": [0, 156, 189], "color_group": [[0, 156, 189, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 0, "sku": "HPL18-107", "status": 5, "type": "PLA", "weight": 1000}, {"color": [0, 150, 57], "color_group": [[0, 150, 57, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 1, "sku": "AHPLCG-107", "status": 5, "type": "PLA", "weight": 1000}, {"color": [238, 190, 152], "color_group": [[238, 190, 152, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 2, "sku": "", "status": 5, "type": "GEEETECH PLA Bas", "weight": 1000}, {"color": [33, 39, 33], "color_group": [[33, 39, 33, 255]], "consumables_percent": 100, "edit_status": 0, "icon_type": 0, "index": 3, "sku": "AHPLBK-107", "status": 5, "type": "PLA", "weight": 1000}], "status": 1, "temp": 27}]} 19:15:52[bridge] AMS slots received: 7, loaded_slot=-1 (×8) ```
image.png
46 KiB
image.png
42 KiB
image.png
14 KiB
image.png
17 KiB
Blaim added the
bug
 label 2026-07-23 21:31:16 +02:00
viewit commented 2026-07-24 13:57:33 +02:00
Owner
Copy Link

Thanks for the detailed logs, @Blaim — the 'list' object has no attribute 'get' crash is fixed.

Root cause: when the printer rejects a manual multiColorBox setInfo assignment, it replies with state: "failed" and data as a 2-element list (["multi_color_box", [...]]) instead of the normal dict shape ({"multi_color_box": [...]}). The bridge's callback called .get(...) on it unconditionally, which crashed and silently dropped the report entirely (including the regular slot-state update it would otherwise have applied). That's fixed now in _on_multicolor_box with a proper guard for the failure shape, plus a defensive check for any other unexpected data shape.

Important — this fixes the crash, not necessarily your underlying issue: the printer/ACE is still rejecting the assignment itself for your GEEETECH PLA Bas slot (and per your report, even for official Anycubic filament in the ACE, while the toolhead works fine). After this fix you'll get a clean rejection instead of a crash, but the slot still won't get assigned until we know why the printer is refusing it.

Could you help narrow that down:

  1. What exact type string and color are being sent when you assign the GEEETECH slot manually (should be visible in the bridge log as setInfo (web) global=... type=... color=...)?
  2. Does the same manual assignment fail for a slot that's not on custom RFID (e.g. a stock Anycubic PLA slot on the same ACE unit), to isolate whether this is RFID-data-specific or affects the ACE assignment path in general?

This will help figure out whether the ACE firmware expects a fixed set of material-type strings (and is rejecting free-text ones) or something else is going on.

Fix is committed locally on nightly, will go out with the next nightly build.

Thanks for the detailed logs, @Blaim — the `'list' object has no attribute 'get'` crash is fixed. **Root cause:** when the printer *rejects* a manual `multiColorBox setInfo` assignment, it replies with `state: "failed"` and `data` as a 2-element list (`["multi_color_box", [...]]`) instead of the normal dict shape (`{"multi_color_box": [...]}`). The bridge's callback called `.get(...)` on it unconditionally, which crashed and silently dropped the report entirely (including the regular slot-state update it would otherwise have applied). That's fixed now in `_on_multicolor_box` with a proper guard for the failure shape, plus a defensive check for any other unexpected `data` shape. **Important — this fixes the crash, not necessarily your underlying issue:** the printer/ACE is still *rejecting* the assignment itself for your GEEETECH PLA Bas slot (and per your report, even for official Anycubic filament in the ACE, while the toolhead works fine). After this fix you'll get a clean rejection instead of a crash, but the slot still won't get assigned until we know why the printer is refusing it. Could you help narrow that down: 1. What exact `type` string and color are being sent when you assign the GEEETECH slot manually (should be visible in the bridge log as `setInfo (web) global=... type=... color=...`)? 2. Does the same manual assignment fail for a slot that's *not* on custom RFID (e.g. a stock Anycubic PLA slot on the same ACE unit), to isolate whether this is RFID-data-specific or affects the ACE assignment path in general? This will help figure out whether the ACE firmware expects a fixed set of material-type strings (and is rejecting free-text ones) or something else is going on. Fix is committed locally on `nightly`, will go out with the next nightly build.
viewit commented 2026-07-24 13:58:49 +02:00
Owner
Copy Link

i will add debug log for 1. and 2.

i will add debug log for 1. and 2.
viewit commented 2026-07-24 14:01:22 +02:00
Owner
Copy Link

Follow-up: the questions in my last comment weren't fair to ask of you — that's information the bridge should already be putting in its own logs. I've fixed that instead of asking you to dig it out manually.

One piece was actually already answerable from what you posted (setInfo (web) global=6 box=0 local_slot=3 type=PLA color=[33, 39, 33]), but the second question (whether the same assignment fails on a non-RFID stock slot) would've required you to run an extra reproduction step just to compensate for our logs not correlating the failure with its cause.

The printer's rejection payload (["multi_color_box", [{"filaments": {"id": 2}, "id": 0}]]) carries no slot/type/color info by itself — just an opaque box id and some internal id. So the bridge now remembers the setInfo request it just sent and logs it together with the rejection, e.g.:

multiColorBox setInfo rejected by printer: request={'global': 6, 'box': 0, 'local_slot': 3, 'type': 'PLA', 'color': [33, 39, 33]}  raw_response=['multi_color_box', [{'filaments': {'id': 3}, 'id': 0}]]

That's one log line with everything needed to correlate a rejection with what was actually sent — no reproduction steps needed on your end. If you hit this again on the next nightly build, just paste that line and we'll have what we need directly.

Both fixes committed locally on nightly, going out with the next nightly build.

Follow-up: the questions in my last comment weren't fair to ask of you — that's information the bridge should already be putting in its own logs. I've fixed that instead of asking you to dig it out manually. One piece was actually already answerable from what you posted (`setInfo (web) global=6 box=0 local_slot=3 type=PLA color=[33, 39, 33]`), but the second question (whether the same assignment fails on a non-RFID stock slot) would've required you to run an extra reproduction step just to compensate for our logs not correlating the failure with its cause. The printer's rejection payload (`["multi_color_box", [{"filaments": {"id": 2}, "id": 0}]]`) carries no slot/type/color info by itself — just an opaque box id and some internal id. So the bridge now remembers the `setInfo` request it just sent and logs it together with the rejection, e.g.: ``` multiColorBox setInfo rejected by printer: request={'global': 6, 'box': 0, 'local_slot': 3, 'type': 'PLA', 'color': [33, 39, 33]} raw_response=['multi_color_box', [{'filaments': {'id': 3}, 'id': 0}]] ``` That's one log line with everything needed to correlate a rejection with what was actually sent — no reproduction steps needed on your end. If you hit this again on the next nightly build, just paste that line and we'll have what we need directly. Both fixes committed locally on `nightly`, going out with the next nightly build.
Blaim commented 2026-07-24 16:58:37 +02:00
Author
Copy Link

Hey so the error is fixed with nightly .42 and I'm able to switch the profile but it doesn't keep the custom selected profile.

image.png

after a refresh of the site
image.png

kx-bridge-log_20260724-154635.txt

Hey so the error is fixed with nightly .42 and I'm able to switch the profile but it doesn't keep the custom selected profile. <img width="266" alt="image.png" src="attachments/bf5c7be2-07d6-448f-a72d-8fed45ec3a75"> after a refresh of the site <img width="260" alt="image.png" src="attachments/9faffbb9-51c9-4201-b853-33fe94719e07"> [kx-bridge-log_20260724-154635.txt](/attachments/eb8026c0-b4ff-48df-a8c7-38f15b274952)
image.png
14 KiB
image.png
14 KiB
kx-bridge-log_20260724-154635.txt
163 KiB
viewit commented 2026-08-02 14:16:15 +02:00
Owner
Copy Link

Thanks for confirming the crash fix works, @Blaim — sorry it took a bit to get back to this one.

I dug further into the underlying rejection (not the crash, the actual "assignment doesn't stick" behavior) with a live MQTT capture against a real printer.

What I confirmed:

The setInfo payload the bridge sends is correct — I tested the exact same schema ({multi_color_box:[{id, slots:[{index,type,color}]}]}) against a real printer's non-ACE slot (box id: -1) and it applies cleanly (state: success, slot value actually changes). So this isn't a payload-format bug on our side.

For a real ACE box (id: 0), the printer flat-out rejects the same call with code: 10501, msg: "设置失败" ("setting failed") — even though the request itself was just plain type: "PLA", not the custom "GEEETECH PLA Bas" string. So it's not the ACE rejecting an unrecognized material name either.

Looking at your log more closely: your slot 2 in box 0 had sku: "" (empty) before the assignment attempt — meaning the printer/ACE has no recognized filament profile (SKU) for that spool, since it was written with a custom/third-party RFID tag rather than genuine Anycubic SKU data. After the repeated failed setInfo calls, that slot's report briefly showed status: 4, type: "" — i.e. the ACE dropped it into an error/unloaded state rather than leaving the old value alone. That's consistent with what you saw after refreshing: the manual selection didn't stick because the printer itself never accepted it, and the bridge's optimistic UI update got overwritten by the next real status report.

Conclusion: this looks like a firmware-level restriction — the ACE unit seems to require its own SKU/RFID-recognized profile before it will accept a manual type/color override via MQTT, and custom-written without a matching SKU don't satisfy that. This isn't something the bridge can work around at the protocol level; there's no alternate payload shape that bypasses it (I tried a couple of variants, all either succeeded exactly like the original shape or failed with the identical generic rejection).

I don't have a real ACE unit to test further variations against (e.g. whether writing a stock SKU via the ACE app first, then trying setInfo, changes anything) — if you're up for one more experiment: does the same manual assignment succeed on an ACE slot loaded with genuine Anycubic filament (proper SKU, no custom)? That would confirm whether SKU-presence is really the gate, or if it's something else specific to that ACE unit/slot.

Given this seems to sit in Anycubic's firmware rather than something fixable on the bridge side, I'll leave this open for now but move it out of active development unless the above test turns up something actionable.

Thanks for confirming the crash fix works, @Blaim — sorry it took a bit to get back to this one. I dug further into the underlying rejection (not the crash, the actual "assignment doesn't stick" behavior) with a live MQTT capture against a real printer. **What I confirmed:** The `setInfo` payload the bridge sends is correct — I tested the exact same schema (`{multi_color_box:[{id, slots:[{index,type,color}]}]}`) against a real printer's non-ACE slot (`box id: -1`) and it applies cleanly (`state: success`, slot value actually changes). So this isn't a payload-format bug on our side. For a real ACE box (`id: 0`), the printer flat-out rejects the same call with `code: 10501, msg: "设置失败"` ("setting failed") — even though the request itself was just plain `type: "PLA"`, not the custom "GEEETECH PLA Bas" string. So it's not the ACE rejecting an unrecognized material name either. Looking at your log more closely: your slot 2 in box 0 had `sku: ""` (empty) before the assignment attempt — meaning the printer/ACE has no recognized filament profile (SKU) for that spool, since it was written with a custom/third-party RFID tag rather than genuine Anycubic SKU data. After the repeated failed `setInfo` calls, that slot's report briefly showed `status: 4, type: ""` — i.e. the ACE dropped it into an error/unloaded state rather than leaving the old value alone. That's consistent with what you saw after refreshing: the manual selection didn't stick because the printer itself never accepted it, and the bridge's optimistic UI update got overwritten by the next real status report. **Conclusion:** this looks like a firmware-level restriction — the ACE unit seems to require its own SKU/RFID-recognized profile before it will accept a manual type/color override via MQTT, and custom-written without a matching SKU don't satisfy that. This isn't something the bridge can work around at the protocol level; there's no alternate payload shape that bypasses it (I tried a couple of variants, all either succeeded exactly like the original shape or failed with the identical generic rejection). I don't have a real ACE unit to test further variations against (e.g. whether writing a stock SKU via the ACE app first, then trying setInfo, changes anything) — if you're up for one more experiment: does the same manual assignment succeed on an ACE slot loaded with **genuine** Anycubic filament (proper SKU, no custom)? That would confirm whether SKU-presence is really the gate, or if it's something else specific to that ACE unit/slot. Given this seems to sit in Anycubic's firmware rather than something fixable on the bridge side, I'll leave this open for now but move it out of active development unless the above test turns up something actionable.
Blaim commented 2026-08-02 17:42:18 +02:00
Author
Copy Link

I ran the test with genuine Anycubic filament on the ACE unit, and checking the bridge logs revealed something interesting: the printer rejected setInfo on the genuine Anycubic slot too.

In my test, Slot 0 had an official Anycubic spool (sku: "HPL18-107"), and Slot 2 had a custom spool (sku: "").

When I tried manual assignment on Slot 0, the printer returned state=failed identical to the rejection on Slot 2
So it looks like Anycubic's firmware locks out manual setInfo MQTT overrides on ACE (box: 0) slots universally, not just when a SKU is missing.

I ran the test with genuine Anycubic filament on the ACE unit, and checking the bridge logs revealed something interesting: the printer rejected setInfo on the genuine Anycubic slot too. In my test, Slot 0 had an official Anycubic spool (sku: "HPL18-107"), and Slot 2 had a custom spool (sku: ""). When I tried manual assignment on Slot 0, the printer returned state=failed identical to the rejection on Slot 2 So it looks like Anycubic's firmware locks out manual setInfo MQTT overrides on ACE (box: 0) slots universally, not just when a SKU is missing.
Blaim commented 2026-08-02 21:02:54 +02:00
Author
Copy Link

Funny enough my fix in #101 (comment) fixed the manual assignment issue aswell!

Funny enough my fix in https://gitea.it-drui.de/viewit/KX-Bridge-Release/issues/101#issuecomment-686 fixed the manual assignment issue aswell!
viewit commented 2026-08-03 12:52:02 +02:00
Owner
Copy Link

Following up here since your original report actually described two separate problems, and one of them just got resolved as a side effect of the deeper dig in #101.

"Bridge does not automatically pull the correct Vendor and Filament type/Material into the ACE view slots" — this is now fixed, tracked and explained in detail in #101: the auto-matching logic for combined ACE-RFID strings like "GEEETECH PLA Bas" existed but was never actually wired into the code path that feeds the dashboard, so the ACE view kept showing the raw unmatched string. That's fixed now — see #101 for the full root-cause writeup.

Still open / not resolved by either fix: the manual profile-assignment rejection (the printer replying code: 10501 / "setting failed" when you try to explicitly assign a profile to an ACE-box slot, as opposed to it just not auto-detecting one) — that one still looks like a firmware-level restriction, as discussed earlier in this thread, not something fixable on the bridge side. Leaving this issue open for that part specifically; the crash and the auto-detection gap are both resolved.

If the improved auto-matching from #101 means you no longer need the manual-assignment path day-to-day, let us know and we can close this out — otherwise it stays open as a firmware-limitation tracker.

Following up here since your original report actually described two separate problems, and one of them just got resolved as a side effect of the deeper dig in #101. **"Bridge does not automatically pull the correct Vendor and Filament type/Material into the ACE view slots"** — this is now fixed, tracked and explained in detail in #101: the auto-matching logic for combined ACE-RFID strings like "GEEETECH PLA Bas" existed but was never actually wired into the code path that feeds the dashboard, so the ACE view kept showing the raw unmatched string. That's fixed now — see #101 for the full root-cause writeup. **Still open / not resolved by either fix:** the *manual* profile-assignment rejection (the printer replying `code: 10501` / "setting failed" when you try to explicitly assign a profile to an ACE-box slot, as opposed to it just not auto-detecting one) — that one still looks like a firmware-level restriction, as discussed earlier in this thread, not something fixable on the bridge side. Leaving this issue open for that part specifically; the crash and the auto-detection gap are both resolved. If the improved auto-matching from #101 means you no longer need the manual-assignment path day-to-day, let us know and we can close this out — otherwise it stays open as a firmware-limitation tracker.
Blaim commented 2026-08-03 13:38:21 +02:00
Author
Copy Link

No you understood me wrong, with the fix I provided I was also able to manually assign the filament profile for the ace units and it kept + synced it correctly to Orca Slicer even after a refresh of the browser.

Even tho it gave out that rejection in the log.

But will try it out once I got the new nightly!

No you understood me wrong, with the fix I provided I was also able to manually assign the filament profile for the ace units and it kept + synced it correctly to Orca Slicer even after a refresh of the browser. Even tho it gave out that rejection in the log. But will try it out once I got the new nightly!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is not working
bug
documentation
duplicate
This issue or pull request already exists
enhancement
New feature
enhancement
help wanted
Need some help
invalid
Something is wrong
known-issue
question
More information is needed
wontfix
This won't be fixed
No Label
bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
viewit
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: viewit/KX-Bridge-Release#100
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?