starred/bambuddy-maziggy-1

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 08:25:54 +02:00

[GH-ISSUE #1150] [Bug]: MQTT print command acknowledgment timeout (15s) too short for P1P — causes 0500-4003 parse error #828

New issue

Closed

opened 2026-05-07 00:14:06 +02:00 by BreizhHardware · 3 comments

BreizhHardware commented

2026-05-07 00:14:06 +02:00

Owner

Originally created by @d3ni3 on GitHub (Apr 28, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1150

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

When sending a print job from Bambuddy's File Manager or Archive (reprint), the printer occasionally returns error 0500-4003 ("unable to parse print file"). The FTP upload completes successfully (STOR 226 confirmed), but the P1P takes significantly longer than 15 seconds to acknowledge the MQTT print command.

The print-dispatch verifier treats the unacknowledged project_file command as a broken MQTT connection and forces a fresh MQTT session. However, the P1P is not in a zombie state — it is genuinely processing the command, just slowly. It starts the print ~2 minutes 15 seconds after the original command was sent, well after Bambuddy has already given up and forced a reconnect. That reconnect mid-initialization appears to be what causes the 0500-4003 parse error on the printer side.

In other words: the 15s timeout is a reasonable safeguard against zombie MQTT connections, but it fires too aggressively for the P1P, which has a legitimate but slow acknowledgment latency under normal conditions.

Printing the same file freshly sliced and sent directly via BambuStudio works without issues.

Expected Behavior

The MQTT acknowledgment timeout should be long enough to accommodate the P1P's response latency. A forced MQTT reconnect should not be triggered when the FTP upload was confirmed successfully (STOR 226) and the printer is still processing a valid print command.

Suggested fix: increase the timeout for P1P/P-series printers, make it configurable per printer model, or suppress the forced reconnect when a successful STOR 226 was already received.

Steps to Reproduce

Send a print job from Bambuddy (Archive reprint or File Manager) to a P1P
Printer takes >15s to acknowledge the MQTT print command
Bambuddy triggers forced MQTT reconnect
Printer displays error 0500-4003

Printer Model

P1P

Bambuddy Version

0.2.3.2

SpoolBuddy Version

No response

Printer Firmware Version

01.10.00.00

Installation Method

Docker

Operating System

Linux (Other)

Relevant Logs / Support Package

2026-04-28 06:25:26,820 INFO  [backend.app.api.routes.archives] Dispatched reprint archive 59 for printer 1 (dispatch_job_id=2, dispatch_position=1)
2026-04-28 06:25:27,671 INFO  [backend.app.services.bambu_ftp] FTP connected successfully to [PRINTER-IP] (model=P1P, prot_c=False)
2026-04-28 06:25:27,755 INFO  [backend.app.services.bambu_ftp] FTP uploading /app/data/archive/1/20260427_174432_Filament_Spool_Rack.gcode/Filament_Spool_Rack.gcode.3mf (1762110 bytes) to /Filament_Spool_Rack.3mf
2026-04-28 06:25:39,240 INFO  [backend.app.services.bambu_ftp] FTP STOR confirmed for /Filament_Spool_Rack.3mf: 226
2026-04-28 06:25:39,241 INFO  [backend.app.services.bambu_ftp] FTP upload complete: /Filament_Spool_Rack.3mf (1762110 bytes in 10.6s, 162 KB/s)
2026-04-28 06:25:39,259 INFO  [backend.app.services.printer_manager] PRINT COMMAND: printer=1, file=Filament_Spool_Rack.3mf, caller=background_dispatch.py:539:_process_job
2026-04-28 06:25:54,264 WARNING [backend.app.services.background_dispatch] Printer P1P (1) did not respond to print command within 15s (state still IDLE) — printer may need restart
2026-04-28 06:25:54,264 WARNING [backend.app.services.bambu_mqtt] [[SERIAL-REDACTED]] Forcing MQTT reconnect: print command unacknowledged after 15s (state still IDLE)
2026-04-28 06:25:54,561 INFO  [backend.app.services.bambu_mqtt] [[SERIAL-REDACTED]] Disconnect callback after stale reconnect (expected), rc=Unspecified error

[Second attempt, same pattern:]

2026-04-28 06:26:45,940 INFO  [backend.app.services.bambu_ftp] FTP uploading /app/data/archive/library/files/07d485e1ef5c4a9ab7190bef84257e70.3mf (4068755 bytes) to /Filament_Spool_Rack_Rack_(less_tight).3mf
2026-04-28 06:27:12,526 INFO  [backend.app.services.bambu_ftp] FTP upload complete: /Filament_Spool_Rack_Rack_(less_tight).3mf (4068755 bytes in 26.6s, 149 KB/s)
2026-04-28 06:27:12,543 INFO  [backend.app.services.bambu_mqtt] [[SERIAL-REDACTED]] Sending print command: {...}
2026-04-28 06:27:27,546 WARNING [backend.app.services.background_dispatch] Printer P1P (1) did not respond to print command within 15s (state still IDLE) — printer may need restart
2026-04-28 06:27:27,547 WARNING [backend.app.services.bambu_mqtt] [[SERIAL-REDACTED]] Forcing MQTT reconnect: print command unacknowledged after 15s (state still IDLE)

[Printer eventually starts the first job ~2m15s after the original print command:]

2026-04-28 06:29:54,079 INFO  [backend.app.services.bambu_mqtt] [[SERIAL-REDACTED]] PRINT START detected - file: Filament_Spool_Rack.gcode.3mf, subtask: Filament_Spool_Rack, is_new: True, is_file_change: False

Screenshots

No response

Additional Context

Bambuddy Version: 0.2.3.2
Printer Model: Bambu Lab P1P
Printer Firmware: 01.10.00.00
File size in failing case: ~1.7 MB and ~4.0 MB (both affected)
No firmware update occurred between working and failing prints
The same file had worked multiple times via Bambuddy before the issue started occurring
Sending a freshly sliced file directly via BambuStudio always works

Checklist

I have searched existing issues to ensure this bug hasn't already been reported
I am using the latest version of Bambuddy
My printer is set to LAN Only mode
My printer has Developer Mode enabled

Originally created by @d3ni3 on GitHub (Apr 28, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1150 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description When sending a print job from Bambuddy's File Manager or Archive (reprint), the printer occasionally returns error `0500-4003` ("unable to parse print file"). The FTP upload completes successfully (STOR 226 confirmed), but the P1P takes significantly longer than 15 seconds to acknowledge the MQTT print command. The print-dispatch verifier treats the unacknowledged `project_file` command as a broken MQTT connection and forces a fresh MQTT session. However, the P1P is not in a zombie state — it is genuinely processing the command, just slowly. It starts the print ~2 minutes 15 seconds after the original command was sent, well after Bambuddy has already given up and forced a reconnect. That reconnect mid-initialization appears to be what causes the `0500-4003` parse error on the printer side. In other words: the 15s timeout is a reasonable safeguard against zombie MQTT connections, but it fires too aggressively for the P1P, which has a legitimate but slow acknowledgment latency under normal conditions. Printing the same file freshly sliced and sent directly via BambuStudio works without issues. ### Expected Behavior The MQTT acknowledgment timeout should be long enough to accommodate the P1P's response latency. A forced MQTT reconnect should not be triggered when the FTP upload was confirmed successfully (STOR 226) and the printer is still processing a valid print command. Suggested fix: increase the timeout for P1P/P-series printers, make it configurable per printer model, or suppress the forced reconnect when a successful STOR 226 was already received. ### Steps to Reproduce 1. Send a print job from Bambuddy (Archive reprint or File Manager) to a P1P 2. Printer takes >15s to acknowledge the MQTT print command 3. Bambuddy triggers forced MQTT reconnect 4. Printer displays error 0500-4003 ### Printer Model P1P ### Bambuddy Version 0.2.3.2 ### SpoolBuddy Version _No response_ ### Printer Firmware Version 01.10.00.00 ### Installation Method Docker ### Operating System Linux (Other) ### Relevant Logs / Support Package ``` 2026-04-28 06:25:26,820 INFO [backend.app.api.routes.archives] Dispatched reprint archive 59 for printer 1 (dispatch_job_id=2, dispatch_position=1) 2026-04-28 06:25:27,671 INFO [backend.app.services.bambu_ftp] FTP connected successfully to [PRINTER-IP] (model=P1P, prot_c=False) 2026-04-28 06:25:27,755 INFO [backend.app.services.bambu_ftp] FTP uploading /app/data/archive/1/20260427_174432_Filament_Spool_Rack.gcode/Filament_Spool_Rack.gcode.3mf (1762110 bytes) to /Filament_Spool_Rack.3mf 2026-04-28 06:25:39,240 INFO [backend.app.services.bambu_ftp] FTP STOR confirmed for /Filament_Spool_Rack.3mf: 226 2026-04-28 06:25:39,241 INFO [backend.app.services.bambu_ftp] FTP upload complete: /Filament_Spool_Rack.3mf (1762110 bytes in 10.6s, 162 KB/s) 2026-04-28 06:25:39,259 INFO [backend.app.services.printer_manager] PRINT COMMAND: printer=1, file=Filament_Spool_Rack.3mf, caller=background_dispatch.py:539:_process_job 2026-04-28 06:25:54,264 WARNING [backend.app.services.background_dispatch] Printer P1P (1) did not respond to print command within 15s (state still IDLE) — printer may need restart 2026-04-28 06:25:54,264 WARNING [backend.app.services.bambu_mqtt] [[SERIAL-REDACTED]] Forcing MQTT reconnect: print command unacknowledged after 15s (state still IDLE) 2026-04-28 06:25:54,561 INFO [backend.app.services.bambu_mqtt] [[SERIAL-REDACTED]] Disconnect callback after stale reconnect (expected), rc=Unspecified error [Second attempt, same pattern:] 2026-04-28 06:26:45,940 INFO [backend.app.services.bambu_ftp] FTP uploading /app/data/archive/library/files/07d485e1ef5c4a9ab7190bef84257e70.3mf (4068755 bytes) to /Filament_Spool_Rack_Rack_(less_tight).3mf 2026-04-28 06:27:12,526 INFO [backend.app.services.bambu_ftp] FTP upload complete: /Filament_Spool_Rack_Rack_(less_tight).3mf (4068755 bytes in 26.6s, 149 KB/s) 2026-04-28 06:27:12,543 INFO [backend.app.services.bambu_mqtt] [[SERIAL-REDACTED]] Sending print command: {...} 2026-04-28 06:27:27,546 WARNING [backend.app.services.background_dispatch] Printer P1P (1) did not respond to print command within 15s (state still IDLE) — printer may need restart 2026-04-28 06:27:27,547 WARNING [backend.app.services.bambu_mqtt] [[SERIAL-REDACTED]] Forcing MQTT reconnect: print command unacknowledged after 15s (state still IDLE) [Printer eventually starts the first job ~2m15s after the original print command:] 2026-04-28 06:29:54,079 INFO [backend.app.services.bambu_mqtt] [[SERIAL-REDACTED]] PRINT START detected - file: Filament_Spool_Rack.gcode.3mf, subtask: Filament_Spool_Rack, is_new: True, is_file_change: False ``` ### Screenshots _No response_ ### Additional Context - Bambuddy Version: 0.2.3.2 - Printer Model: Bambu Lab P1P - Printer Firmware: 01.10.00.00 - File size in failing case: ~1.7 MB and ~4.0 MB (both affected) - No firmware update occurred between working and failing prints - The same file had worked multiple times via Bambuddy before the issue started occurring - Sending a freshly sliced file directly via BambuStudio always works ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [x] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode - [x] My printer has Developer Mode enabled

BreizhHardware

2026-05-07 00:14:06 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

2026-05-07 00:14:07 +02:00

Author

Owner

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

Never heard of a printer that takes so long to start a print....weird.

The 15-second timeout you hit was a v0.2.3.2 limit. Commit 9d041868 already bumped it to 90 seconds in v0.2.4b1-daily.20260427.
On its own, 90 seconds still wouldn't have caught your case (your printer took ~135 seconds to start the print). So the bigger fix: the watchdog now checks whether MQTT telemetry is still arriving before it force-reconnects. If push_status was received within the last 30 seconds, the session is healthy and the printer is just slow to parse — we leave MQTT alone instead of reconnecting and triggering 0500_4003. Original half-broken-session protection (#887/#936/#1136) still kicks in when telemetry has actually stopped.

Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you now.

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

@maziggy commented on GitHub (Apr 28, 2026): Never heard of a printer that takes so long to start a print....weird. 1. The 15-second timeout you hit was a v0.2.3.2 limit. Commit 9d041868 already bumped it to 90 seconds in v0.2.4b1-daily.20260427. 2. On its own, 90 seconds still wouldn't have caught your case (your printer took ~135 seconds to start the print). So the bigger fix: the watchdog now checks whether MQTT telemetry is still arriving before it force-reconnects. If push_status was received within the last 30 seconds, the session is healthy and the printer is just slow to parse — we leave MQTT alone instead of reconnecting and triggering 0500_4003. Original half-broken-session protection (#887/#936/#1136) still kicks in when telemetry has actually stopped. Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you now. ----- 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-07 00:14:07 +02:00

Author

Owner

@d3ni3 commented on GitHub (Apr 28, 2026):

Okay, thanks for the explanation. I'll wait for the daily build and give it a try.

@d3ni3 commented on GitHub (Apr 28, 2026): Okay, thanks for the explanation. I'll wait for the daily build and give it a try.

BreizhHardware commented

2026-05-07 00:14:07 +02:00

Author

Owner

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

The issue no longer occurs in the latest daily build :-)
Thanks!

@d3ni3 commented on GitHub (May 1, 2026): The issue no longer occurs in the latest daily build :-) Thanks!