capture_finish_photo (default-on) was forcing the timelapse MQTT field to
true on every print, even when the user explicitly unchecked Timelapse in
the slicer send dialog. On profiles with Timelapse Type = Smooth, that
flipped the printer's timelapse_record_flag and un-gated the per-layer
M622 J1 wipe blocks the slicer had baked in — toolhead parked off the
part every layer, on prints the user opted out of recording.
Root cause: #1397 implemented the finish-photo feature as a side channel
of "force the printer into timelapse-recording mode at dispatch" so the
last-frame extractor had a video to pull from. That conflated recording a
timelapse with snapping a finish photo, and the per-layer side effects
were decided at slice time by the user's timelapse_type, which Bambuddy
has no visibility into post-slice.
Fix: replace the force-on with a clean MQTT-state-driven trigger.
bambu_mqtt.py fires a new on_finish_photo_moment callback when
stg_cur transitions INTO 22 ("Filament unloading") while
_was_running AND end-of-print gate matches (progress >= 99 OR
layer_num >= total_layers OR remaining_time <= 0). The gate
disambiguates from mid-print color swaps (which also transit
stage 22 but at progress < 99). FINISH-state fallback in the same
handler fires the callback at the existing transition if stage 22
never arrived (cancel, external-spool-only, HMS halt, firmware
variants).
main.py registers on_finish_photo_moment as a top-level handler.
It pre-captures one camera frame at the trigger edge (external cam
→ buffered RTSP → fresh RTSP via capture_camera_frame_bytes) and
caches the JPEG bytes in _stage22_finish_frames[printer_id].
_background_finish_photo consumes the cached bytes before its
existing live-grab chain, so the saved photo has the better
framing (toolhead parked, before bed drop) without restructuring
the archive-resolution / fallback / notification wiring.
When a timelapse IS actively recording (user explicitly opted in),
pre-capture is skipped — _capture_finish_photo_from_timelapse
still extracts the last frame, which is still the best framing
and now has no force-on side effects because the user wanted the
video.
Removed: resolve_effective_timelapse, _resolve_effective_timelapse
wrapper, both background_dispatch call sites, the print_scheduler call
site, the archive.bambuddy_forced_timelapse write, _cleanup_forced_timelapse
(~75 lines including the FTP-DELE walk across /timelapse, /timelapse/video,
/record, /recording) and its call site. All paths now read
bool(item.timelapse) / bool(job.options.get("timelapse", False)) directly.
The archive.bambuddy_forced_timelapse DB column stays defined (default
False) for back-compat with existing rows — no consumer reads it anymore.
VP bridges bound to a target printer (Proxy mode, Queue mode with
specific target) forwarded the printer's raw AMS push_status to the
slicer untouched. bambu_mqtt.py::_handle_ams_data applies a
tray_exist_bits-driven cleanup to Bambuddy's internal state
(promote empty slots to state=9, wipe stale tray_type / tray_color /
tray_info_idx / tag_uid / tray_uuid / remain) so the AMS card renders
empty slots as Empty, but the VP bridge cache never ran the same
cleanup. Net result on real hardware: a printer with 3 loaded
filaments and several previously-loaded-now-empty slots had Bambuddy's
AMS card render those slots correctly as Empty, but BambuStudio after
Sync painted them as phantom loaded filaments with stale color and
material from before the slot went empty.
Root cause: two consumers of the same payload, only one wired to the
cleanup. _handle_ams_data ran it on every push; mqtt_bridge.py::
_on_printer_raw merged the ams blob via _merge_ams_dict but copied
tray_exist_bits through as an opaque scalar without acting on it.
Fix: factored the bit-clear logic out of _handle_ams_data into a
module-level helper apply_tray_exist_bits(units, tray_exist_bits_str,
*, power_on_flag, log_label). Internal path replaced with a single
call. Bridge calls it after _merge_ams_dict on the merged ams dict,
before the merged state is stored as the 1 Hz cached-as-base source.
Shared shutdown guard kept on both sides: all-zero bits +
power_on_flag=False is the printer-off pattern (#765, would
propagate phantom empties on every reconnect); nonzero bits +
power-off is valid idle-printer state (#1365, X1C between prints)
and still applies. AMS-HT units (id >= 128) skipped on both sides.
Tests: new TestApplyTrayExistBitsHelper (10 cases) pins the helper
contract directly. 3 new bridge regression tests reproduce the
#1726 wire shape, the shutdown guard, and the AMS-HT skip on the
cached slicer-facing state. Existing internal-state tests for the
bit-clear logic (covers state=9 promotion, loaded-slot preserve,
genuine-removal-with-power-on) continue to pass against the
refactored path.
One pre-existing bridge fixture had an inconsistent tray_exist_bits
('3' for 2 AMS units each with slot 0 loaded — bit 4 missing). The
shared cleanup exposed it; corrected to '11' (bits 0 + 4) to match
real-printer wire shape.
Reported by @needo37 with full code-level analysis including the
suggested fix shape and the BAMBUDDY_VP_DUMP_WIRE diagnostic to
verify on a live system.
The Re-print and Schedule modal toggles for Flow Calibration and Nozzle
Offset Calibration accepted "off" correctly and flowed it through to the
project_file MQTT publish — Bambuddy sent extrude_cali_flag: 2 and
nozzle_offset_cali: 2 per the "1 = run, 2 = skip" reading inherited from
the #1478 / #1682 work. Live test on H2D 01.x: with both toggles off,
the stg queue still scheduled stage 8 ("Calibrating dynamic flow") and
stage 39 ("Nozzle offset calibration"), and the printer ran both at
print start.
Root cause: 2 means "skip the explicit pass but still apply / verify
stored PA via the calibration stage" — close to a no-op K-factor wise
but the per-print physical sequence still runs. 0 is the encoding that
actually drops the stage from stg. A BambuStudio Send-dialog capture
on the same firmware showed 0 for both fields when the user unchecked
the calibrations — contradicting the #1478 commit's read of "BambuStudio
never sends 0."
Fix:
- extrude_cali_flag = 1 if flow_cali else 0 (was: else 2)
- nozzle_offset_cali = 1 if (nozzle_offset_cali and is_dual_nozzle) else 0
(was: else 2)
Dual-nozzle gate stays; single-nozzle prints continue to force-skip the
nozzle-offset cali their head doesn't support (#1682). The 1 (run)
branch is unchanged.
Verified live on the same H2D after the patch: stg dropped to
[29, 13, 4, 14, 3] (cooling, homing, filament change, nozzle cleaning,
vibration comp). Stages 8 and 39 gone.
Vibration compensation is NOT fixed by this commit: vibration_cali is a
bool in our and BambuStudio's wire format, and the H2D firmware queues
stage 3 regardless of the false value. Firmware-side, not solvable at
the dispatch layer with the current field. Filed as a follow-up.
Logs device.dev_model_name / dev_product_name / dev_id / project_name
at INFO level once per client session, falling back to device.keys()
if none of the known fields are present.
The MQTT push_status carries the model code in device.dev_model_name
on every message, but nothing in bambu_mqtt.py reads or logs that
field — so adding a new printer model meant chasing the code through
either Bambu cloud or a manual mosquitto_sub. A2L (#1684) was the
case that surfaced this: get_version also failed because the firmware
disconnected right after request topic subscription, so the support
bundle had no way to disclose the model.
INFO level so the line lands in support bundles without enabling
debug. One-shot via _device_id_logged, mirroring the existing
_nozzle_fields_logged flag at line 2095, so push_status spam is
avoided.
Future-proofs against Bambu renaming the field (the fallback dumps
device.keys() so a rename like model_name without the dev_ prefix
is still observable). 3 unit tests in TestDeviceIdentificationProbe
pin all three branches.
Bambuddy's project_file MQTT payload hardcoded "nozzle_offset_cali": 2 (skip),
giving users on H2D / H2D Pro / H2C / X2D no way to control the same toggle
BambuStudio exposes. Critical for diamond-nozzle setups that must keep the
calibration off.
start_print() now takes a nozzle_offset_cali kwarg; the value is encoded as
1 (run) or 2 (skip) and gated on is_dual_nozzle so single-nozzle machines
always send 2 even if a stale flag arrives. The kwarg threads through
printer_manager, both background_dispatch sites, and print_scheduler so
every dispatch path respects the per-item setting.
print_queue gains a nozzle_offset_cali column (DEFAULT TRUE, is_sqlite()
branch for Postgres BOOLEAN). Settings default key default_nozzle_offset_cali
defaults to TRUE to match BambuStudio. Schemas updated across print_queue,
library FilePrintRequest, archive ReprintRequest, settings.
PrintModal renders the new toggle only when the selected printer is dual-
nozzle (printer-mode: nozzle_count===2; model-mode: DUAL_NOZZLE_MODELS).
SettingsPage default-print-options row + QueuePage bulk-edit tri-state both
hide unless any registered printer is dual-nozzle. Labels reuse the existing
settings.default* keys so the only new i18n strings are
settings.defaultNozzleOffsetCali / Desc and queue.bulkEdit.nozzleOffsetCali
- real translations in all 11 locales.
The existing connection diagnostic proved TCP + TLS + auth + SUBSCRIBE but
not that the printer was actually publishing reports. A wrong-cased serial
passes mqtt_auth because the broker accepts the subscription regardless;
the user-visible symptom is empty AMS / no K-profiles / no custom filaments
in the slicer Device tab because the VP cached state is empty. Bambuddy
already logged the actionable hint at bambu_mqtt.py:498 but only to
container logs.
New printer_publishing check turns that warning into a structured
diagnostic result. Pass = bridge has seen at least one report since the
last (re)connect; fail = zero reports across the wait window with fix-text
pointing at the case-sensitive serial. Bounded 10s poll on the on-demand
UI route, no wait on the support-package gathering path so bundling stays
fast. Exits the moment a message arrives — typical wall-clock is 1-2s.
Frontend renders an elapsed-seconds counter plus a "Listening for status
report — up to 10s" hint during the pending state so the wait doesn't look
hung. PUBLISH_WAIT_DEFAULT_SECONDS pinned on both sides.
report_messages_since_connect exposed as a public property on
BambuMQTTClient so the diagnostic doesn't reach into private state.
When Bambuddy is restarted mid-print, the first MQTT push from the
printer carries `_previous_gcode_state = None`. The #1304 guard
deliberately suppresses on_print_start on that first push to prevent
duplicate archive creation — but on_print_start is also where
_capture_timelapse_baseline_at_start runs, so the in-memory
_timelapse_baselines dict stays empty for the resumed session.
At PRINT COMPLETE, _scan_for_timelapse_with_retries finds no baseline
and falls into its "take baseline now" fallback. By that point the
printer has already uploaded the in-flight MP4, so the snapshot
includes the new file. Every "Found N files / no new files since
baseline" retry then fails to detect a diff, and the archive ends up
with no timelapse attached — pwostran's report (#1485 follow-up): card
shows the finish snapshot but no video.
Add a sibling callback on_print_running_observed that bambu_mqtt fires
in the "Now tracking RUNNING state" branch when on_print_start was
suppressed. main.py wires it to a thin handler that looks up the
printer row and calls the existing _capture_timelapse_baseline_at_start.
Idempotent — skips if a baseline already exists (handles the rare
same-session race where on_print_start also fires for some reason).
The printer doesn't upload the timelapse until after PRINT COMPLETE,
so a baseline captured any time during the print is still pre-upload —
no narrow window to hit.
Verified against the in-the-field logs in #1485 (pwostran's 2026-05-23
support bundle):
pre-reboot: baseline = 7 files
reboot
post-reboot completion: fallback baseline = 8 files (includes new MP4)
-> all 4 retry attempts report "no new files since baseline"
10 new tests cover both the MQTT-side fire decision (fires when
suppressed, doesn't fire when on_print_start handles it, once per
session, payload shape mirrors on_print_start) and the main.py
handler (snapshot capture, double-capture guard, missing-printer-row
guard).
Five follow-up fixes to cross-printer re-slicing, all surfaced while
testing archive re-slices.
1. Re-sliced archive now records the printer it was sliced FOR.
slice_and_persist_as_archive copied sliced_for_model from the source
archive, so re-slicing X1C->H2D still showed "X1C sliced". Read it
from the freshly-sliced 3MF's parsed metadata instead, falling back
to the source only when absent.
2. Real slicer rejections are surfaced instead of silently masked.
_run_slicer_with_fallback retried with the 3MF's embedded settings on
any sidecar 5xx — including genuine content rejections (object off
the bed, incompatible filament temps), which "succeeded" only by
re-slicing for the source's original printer. A new
_slicer_rejection_message detects the slicer's own error string and
surfaces it as a 400; the embedded-settings fallback is kept only for
true CLI crashes.
3. A failed slice opens an error modal, not a 3s toast. The slicer's
reason is actionable and a toast hides it before it can be read. New
AlertModal (acknowledge-only); SliceJobTrackerContext shows it on a
failed job. New slice.failedTitle key in all 9 locales.
4. Sliced files no longer report "0 g" filament usage. The sidecar
doesn't always populate the X-Filament-Used-* headers;
ThreeMFParser._parse_gcode_header now also reads the slicer's own
"total filament weight/length" from the G-code header, and both
slice-persist paths fall back to it when the sidecar reports 0.
5. Nozzle-class re-slice guard. Re-slicing across the single-nozzle <->
dual-nozzle boundary (e.g. X1C -> H2D) fails BambuStudio's
multi-extruder validation; both slice routes now reject it up front
with a clear 400. The dual-nozzle model classification — previously
an inline tuple duplicated across start_print and the K-profile
routes — is centralized into DUAL_NOZZLE_MODELS / is_dual_nozzle_model
in printer_models.py, consumed by all three sites and the guard.
Full cross-nozzle-class re-slicing (dual-nozzle project_settings
reconciliation) remains separately tracked.
Tests: _slicer_rejection_message, _canonical_printer_model,
guard_nozzle_class_reslice, is_dual_nozzle_model, the G-code-header
filament parse, AlertModal, and end-to-end slice-API coverage including
an X1C-archive-to-H2D 400. Backend ruff + i18n parity clean; frontend
build clean.
A restart during an active print duplicated the running job in the
archive, and every further restart spawned another. on_print_start
re-attaches by subtask_id, falling back to a name match plus a 4-hour
staleness cutoff that cancelled + recreated any name-matched 'printing'
archive older than 4h - destroying the live archive of every long print.
Two fixes:
- start_print records the minted subtask_id (last_dispatch_subtask_id);
on_print_start falls back to it when the printer hasn't echoed one
yet, so queue/scheduled archives persist a restart-stable id.
- Replace the 4h cutoff with a progress-aware check: a name-matched
'printing' archive resumes whenever the printer reports real (or
unknown) progress; it is stale only when the printer shows a
freshly-started print (<1%) on an archive over 2h old.
The H2S never ran flow-dynamics calibration even with the print option
enabled, because start_print built the project_file command wrong:
- extrude_cali_flag was hardcoded to 0. A BambuStudio request-topic
capture from a real H2D (plus X1C/P2S captures) shows it is always 1
(run calibration) or 2 (skip, reuse stored PA), paired with flow_cali,
never 0 — so the printer skipped calibration regardless of the toggle.
- flow_cali and the other calibration/leveling fields were integer-
encoded for the H2 family on a mistaken belief that H2 firmware
requires 0/1. The same capture sends plain JSON booleans for every
model; the belief conflated these fields with use_ams (which does
need to stay boolean — the actual #1386 cause).
Fix: extrude_cali_flag = 1 if flow_cali else 2; send timelapse,
bed_leveling, flow_cali, vibration_cali and layer_inspect as booleans
for all models; drop the is_h_family integer-conversion branch.
use_ams is unchanged.
Corrected the two tests that asserted the integer format and renamed
them; all three model tests now also assert extrude_cali_flag.
Reporter's H2C connected over MQTT+TLS but every status field stayed
unknown. Root cause was layer-8: the MQTT broker is the printer, it
authenticates on the access code and SUBACKs any topic string, so a
wrong or mis-cased serial connects fine and silently receives nothing
(the report topic device/<serial>/report is case-sensitive; Bambu
serials are uppercase). Bambuddy stored and used the serial verbatim.
- schemas/printer.py: field_validator strip()+upper()s serial_number on
create, rejects blank-after-strip. The subscribed topic now always
matches the printer's correctly-cased one.
- bambu_mqtt.py: count report-topic messages per connection; when a
stale reconnect fires with zero reports received, log a one-shot
hint pointing at the serial number instead of looping silently.
Reporter on X2D set a 1h AMS dry; the printer powered off seconds in.
Support log: every "Sent drying command duration=1" was followed 3-9s
later by "AMS 0 drying complete (dry_time 60 -> 0)" -- the completion
callback fired right after drying started, arming smart-plug auto-off.
Root cause: the tray-bearing branch of the AMS partial-update merge
rebuilt the unit as {**ams_unit, "tray": merged_trays}, never spreading
existing_unit. Tray-bearing partials carry no drying fields, so dry_time
(and info) was dropped; the falling-edge detector read the absent field
as 0 and saw a false 60->0 edge.
- Merge: tray branch now spreads existing_unit first, preserving
dry_time / info / humidity / temp across tray-only partials. Matches
the no-tray branch. Also fixes dry_status/dry_sub_status UI flapping.
- Detector: only evaluate the falling edge when dry_time is explicitly
present and parseable; skip otherwise without updating state.
Two bugs in one report, both shipped here.
(1) Popover positioning. The flame-icon onClick on PrintersPage
computed popover position as a fixed { top: rect.bottom + 4,
left: Math.max(8, rect.right - 240) } with no viewport-overflow
check. The flame icon sits at the bottom of the AMS info section
on the printer card, so on most realistic viewports
rect.bottom + 4 + popover_height (~320px) overruns viewport.height
and the popover renders partially or entirely off-screen with the
Start button unreachable. Reporter worked around it via DevTools to
confirm the popover was actually there, just clipped.
Extract a computePopoverPosition() helper in utils/popoverPosition.ts:
- defaults to below + right-aligned to the trigger (preserves the
original visual layout when there's room),
- flips ABOVE the trigger when below would overflow AND above fits,
- stays below in the degraded case (popover taller than viewport) —
at least the top is visible and the user can scroll inside; flipping
to a top-clipped position would lose the action buttons too,
- clamps the left coordinate so a trigger near either viewport edge
can't push the popover off-screen horizontally either.
Both PrintersPage callsites (compact AMS row at :3498 and dual-nozzle
layout at :4011) route through the helper.
(2) Diagnostic logging for the silent-drying-ignore. Reporter's
support bundle shows the printer receives every ams_filament_drying
command (P1S 01.10.00.00 firmware, AMS-HT at ams_id=128) and ACKs
each one, but the AMS info field never changes — drying neither
starts nor stops on Bambuddy's request, while pressing Start on the
printer's touchscreen works immediately. The command JSON matches
the format documented as working on H2D, all required fields present.
Diagnosing the silent rejection needs the printer's actual response
payload — result/reason — but bambu_mqtt.py:918 was only logging the
response command name, not the body. The existing extrusion_cali_* /
ams_filament_setting debug path at :919-920 was the template; this
PR extends it to ams_filament_drying at INFO level (not DEBUG like
its siblings) because drying responses are rare (user-initiated only)
and INFO ensures the body lands in support bundles by default without
the user having to bump log level first. Paired with an outgoing-side
INFO log inside send_drying_command that captures the full wire JSON,
so the next bundle has both halves of the conversation.
No guessing on the command-side. Mutating a field that matches the
documented-working H2D shape (e.g. flipping close_power_conflict)
could break currently-working installs. When the reporter retries on
this build and re-attaches a bundle, the rejection reason is visible
and the command-side fix follows from real data.
Two-part fix for the #1322 follow-up by @RosdasHH.
Data layer.
The previous narrow heuristic in printer_manager.py only caught
the bare {"id": N} payload firmware sends right after a printer
restart. In steady-state operation — and on the more common
post-Reset-Slot path on P1S and A1 Mini BMCU — firmware sends a
populated payload and signals emptiness via the tray_exist_bits
bitmask. We already parse that bitmask and use it to wipe stale
tray_type / tray_color / tag_uid fields, but never touched the
state field, so downstream readers (printers.py API serializer,
inventory.py's tray_state in {9, 10} short-circuit, AMS card)
saw state: null and had to guess from absent payload fields.
Fix lifts tray["state"] = 9 (int — not "9"; inventory.py:1358
uses == not `in {...}` so a string would silently miss and the
reporter's deadlock would come back) to the outer `if not
slot_exists` branch, so the bitmask path now writes the
canonical "no spool" code for every empty slot regardless of
stale fields. The narrow heuristic in printer_manager.py:797
stays as belt-and-suspenders for any MQTT path that doesn't
flow through _handle_ams_data.
UI layer.
With the data flow now consistent, the AMS slot card renders
physically-empty slots distinctly from reset slots, per
reporter's mockup. New helper getEmptySlotKind(tray) returns
"physical" (state ∈ {9, 10}), "reset" (any other empty state),
or null (loaded). The inline label below the slot circle reads
"Empty" for physical and "Reset" for reset; pre-fix both showed
an em-dash. FilamentSlotCircle gains an emptyKind prop that
picks a quieter dashed border colour for reset slots so the
visual hierarchy reads loaded > reset > physically empty.
EmptySlotHoverCard gains a kind prop and switches between
"Empty slot" and "Slot reset — no spool assigned".
Reporter Kyobinoyo asked for the equivalent of the existing
print-finish auto-off but triggered when AMS drying ends.
Two new SmartPlug columns: auto_off_after_drying (default false),
off_delay_after_drying_minutes (default 10 — AMS chamber is hot
post-cycle so longer cooldown than the print-finish default of 5).
SQLite + Postgres migrations both idempotent.
Trigger lives in BambuMQTTClient — per-AMS _previous_dry_times
tracks the dry_time > 0 → 0 falling edge and fires a new
on_drying_complete(ams_id) callback. Plumbed through
PrinterManager.set_drying_complete_callback to
SmartPlugManager.on_drying_complete(printer_id, db), which walks
linked plugs and respects the per-plug toggle. Catches queue,
ambient and manual drying identically because it observes firmware
state, not scheduler intent.
Frontend: single "Auto Off After Drying" toggle + delay input on
the smart plug card, next to the existing print-finish auto-off
section.
Per-AMS plug routing (separate plug for AMS only, per-AMS targeting
on dual-AMS printers) deferred — Bambuddy's plug model is
plug→printer, so the trigger fires whenever any AMS on the linked
printer finishes a cycle.
H2S is single-nozzle (nozzle_count=1 across 9+ stored support bundles
and the reporter's diagnostic) but had been added to the H-family model
gate in start_print_job. That single flag controlled both the firmware
bool->int format (legitimately needed for the whole H-family, including
H2S) and the dual-nozzle external-spool routing (correct only for actual
dual-extruder printers).
With no AMS attached and an external-spool slot (tray_id=254), the
dual-nozzle branch wrote ams_id=254 into ams_mapping2 instead of the
canonical 255 — exactly the failure the comment six lines above warns
against. Firmware rejected the dispatch with 07FF_8012 "Failed to get
AMS mapping table". The use_ams=False fallback was also being skipped
because the H-family bypass was meant for dual-nozzle routing.
A second site at bambu_mqtt.py:3987 and its sibling at kprofiles.py:119
detected dual-nozzle by serial prefix ("094", "20P9", "31B8B"). H2S
shares prefix "094" with H2D, so prefix detection misclassified it too.
Split the conflated flag into two:
- is_h_family — firmware format (int 0/1 for calibration fields).
Includes H2S. H2S firmware structurally accepted the current command
shape (failure was at AMS routing, not parsing), so the int format
stays for H2S.
- is_dual_nozzle — external-spool routing and use_ams gating. Excludes
H2S. Source-of-truth is the runtime _is_dual_nozzle flag set from
device.extruder.info, with a model-name fallback for the brief window
after connect before push data arrives.
The K-profile delete site and the kprofiles route now use the same
runtime+model check instead of serial prefix.
The #765 guard against shutdown-time data wipes skipped any AMS update
with power_on_flag=False, but some X1C firmware emits power_on_flag=False
while idle with tray_exist_bits still reflecting the real slot inventory.
Older firmware (01.08.02.00) doesn't emit per-tray state=9/10 events, so
the bitfield path is the only signal — muting it left spool removals
undetected until a manual reconnect.
Narrow the skip to the exact shutdown pattern: zero bits AND
power_on_flag=False. Non-zero bits with power_on_flag=False are now
applied. The #765 shutdown protection is preserved (its regression test
uses tray_exist_bits='0' and still passes); newer firmwares are
unaffected because their per-tray state path catches the removal first.
Restarting Bambuddy mid-print misfired the plate-check + archive flow.
The is_new_print guard treated _previous_gcode_state=None → RUNNING as
a transition, but None just means we haven't seen any prior state yet —
catch-up from a printer that was already running, not a fresh start.
Add `_previous_gcode_state is not None` to the guard. _was_running still
flips on unconditionally, so completion detection is unchanged. 3 tests
that asserted the buggy behavior now seed an explicit prior state; new
regression test pins the contract for the reporter's exact scenario.
ams_set_filament_setting and reset_ams_slot encoded the single-external
case as {ams_id: 255, tray_id: 0, slot_id: 0}. The "LOCAL tray_id = 0"
comment was a misread of the printer's response (which echoes the local
slot position), not the request semantics.
Captured BambuStudio -> X1C exchange shows the request encoding is
{ams_id: 255, tray_id: 254, slot_id: 0} (global tray index in tray_id).
The previous code's tray_id: 0 is what the P1S in #1279 rejects with
result: "fail", which silently broke external-spool filament selection
on every Bambu printer with no AMS or external spool in active use.
Dual-external (H2D) branch was not in the captured exchange and is
explicitly pinned at the legacy encoding pending a Studio -> H2D capture.
When one spool ran out and the AMS transparently switched to a sibling
slot of the same material, the usage tracker credited the originally-
mapped spool with the full 3MF estimate AND added the fallback spool's
remain%-delta on top — so a 78g print could record as 138g across two
spools, leaving the empty spool's recorded weight beyond its label.
Two interacting bugs:
1. bambu_mqtt.py: the tray-change recorder gated on
`state in ("RUNNING", "PAUSE")`, but P2S firmware briefly transitions
out of RUNNING during the AMS swap (into LOADING etc.), so the
literal-string gate missed the switch entirely and tray_change_log
stayed empty. Re-key on the print-lifecycle flags
(_was_running and not _completion_triggered) so any tray change
between print start and completion is captured regardless of the
momentary gcode_state.
2. usage_tracker.py: the splitting branch was gated on
`not slot_to_tray`, so the splitting code only ran for prints where
the slicer mapping hadn't been captured — i.e. never on the actual
fallback case (slot_to_tray is populated by every print_cmd). Drop
the gate: when tray_change_log has > 1 entries, splitting takes
over and per-segment per-layer gcode usage replaces the stale
mapping. Path 2 (AMS remain%-delta) then naturally skips both trays
because they're already in handled_trays after splitting,
eliminating the double-credit.
In non-proxy VP modes (Immediate / Review / Print Queue), the slicer now
sees real AMS / FTS / nozzle / k-profile state from the target printer
and streams the live camera — full slicer-as-remote functionality without
giving up Bambuddy's queue / archive / dispatch features.
Architecture (cached-as-base, single source of truth). The bridge caches
the latest real push_status and info.get_version response from Bambuddy's
existing per-printer MQTT subscription — no second session on the printer,
firmware in-flight budget unaffected (#1164). _send_status_report serves
a near-byte-identical copy of the cached push with only the upload-state-
machine fields overridden. Command responses (extrusion_cali_get, AMS
write acks, xcam) fan out raw — they carry sequence_ids the slicer is
waiting on. Slicer-issued commands forward to the printer except
project_file / gcode_file, which still terminate locally because the file
lives on Bambuddy. Camera is a raw TCPProxy on bind_ip:322 → printer:322,
same approach proxy mode uses.
Field-shape gotchas pinned in the bridge module's docstring and the
new test file:
- Real Bambu pushes use json.dumps(indent=4) wire format. Compact JSON
fails BambuStudio's Send pre-flight silently.
- net.info[*].ip is the FTP destination IP (little-endian uint32).
Without rewriting to the VP bind IP, the slicer FTPs straight to
the real printer.
- upgrade_state.sn rewritten to VP serial; AMS-hardware sn fields
(n3f/0.sn etc.) left alone.
- ipcam.rtsp_url passes through unchanged; BambuStudio overrides the
URL host with the device IP it bound on, so :322 lands on the VP's
TCPProxy.
- extrusion_cali_get must forward; answering it locally hides the
user's stored per-filament k-profiles.
Setup nuance for camera: the VP's access code must match the target
printer's because the slicer authenticates RTSPS with whatever access
code is in its profile. MQTT and FTP work either way.
Tested e2e with BambuStudio and OrcaSlicer against H2D (dual-nozzle,
AMS 2 Pro + AMS HT) and X1C across all three non-proxy modes — sync,
send, k-profile lookup, AMS configuration from slicer, and live camera
all work. Proxy mode is untouched: SlicerProxyManager owns its own
proxies and never instantiates SimpleMQTTServer or MQTTBridge.
25 new tests in backend/tests/unit/test_vp_mqtt_bridge.py cover lifecycle,
caching, identity / IP rewriting, wire format, slicer→printer routing,
and the LE-uint32 IP encoder against the real H2D capture value.
paho's default max_inflight_messages=20 silently fills on Bambu's broker
after ~16-20 cumulative commands per session, leaving publish() returning
success while packets sit in paho's internal queue. force_reconnect heals
it because the inflight queue is per-session, but it costs one wasted
user action to trigger.
Lifting the ceiling to 1000 keeps QoS=1 untouched (deliberately chosen
for cross-model reliability — A1, P1S, X1C, H2D, P2S, X2D all need it)
and removes the inflight queue as the bottleneck without changing
wire-protocol behaviour. The 0.2.4b2 watchdog reconnect stays as
defence-in-depth.
Diagnosis credit: RosdasHH's QoS=1/0/2 bisect on #1164.
The ams_load_filament / ams_unload_filament MQTT primitives existed
in bambu_mqtt.py but were unused — no HTTP route and no UI. Surface
both as POST /printers/{id}/ams/load?tray_id={int} and
POST /printers/{id}/ams/unload, gated on PRINTERS_CONTROL.
Wire them into the existing AMS slot popover (next to "Re-read RFID")
and add a popover wrapper on the external spool slot which had none.
Hidden while the printer is RUNNING, mirroring the RFID re-read
gating. Both buttons enabled when permission is granted; the printer
no-ops gracefully if there's nothing to do (matches BambuStudio).
Dual-extruder H2D Ext-R support is the trickier piece. The existing
ams_load_filament(254) capture came from a single-extruder printer
and used slot_id=254, curr/tar=-1. Captured the Ext-R command from
BambuStudio fresh: it sends ams_id=255, slot_id=0 (the right
extruder index, NOT a slot index), target=255, and curr/tar = the
actual right-nozzle temp (read from state.temperatures["nozzle_2"],
falling back to 215 °C if cold so the printer doesn't reject the
command on a nonsensical temp). Added that as a new branch in
ams_load_filament; the existing tray_id=254 branch is preserved
verbatim — no risk of regression on single-external setups.
P1S 01.10.00.00 (and similar firmware revisions) only echo the .3mf
filename in print.gcode_file, dropping the Metadata/plate_N.gcode path.
The /cover route's regex falls back to plate 1 — and the printer card
shows the wrong plate's thumbnail on multi-plate prints.
Resolution order in the new resolve_plate_id() helper (used by both
the status route's current_plate_id and /cover):
1. The plate Bambuddy dispatched. start_print() now records
(dispatched_plate_id, dispatched_subtask) on PrinterState; the
subtask check rejects stale records from a previous Bambuddy
dispatch bleeding into a Studio-direct print on the same project.
2. plate_(\d+)\.gcode regex on state.gcode_file (existing behaviour
for firmware that does include the path).
3. After download, scan the 3MF for a unique Metadata/plate_*.gcode —
covers per-plate archives sliced separately in Studio without a
Bambuddy dispatch record.
4. Default to plate 1.
Cover-byte cache key simplified to (subtask_name, view_key) now that
plate resolution is late-bound. clear_cover_cache() already fires on
every print start, so re-dispatches with a different plate always
fetch a fresh thumbnail.
Bambuddy-dispatched prints additionally register the local archive
3MF in the cover cache at dispatch time, so /cover reads straight
from the archive directory and doesn't refetch the file over FTP
from a printer whose FTP server is busy serving the active print.
Coverage: 5 unit tests for resolve_plate_id, 4 unit tests for the
dispatch record on start_print, 2 integration tests for the cover
route (dispatch wins over plate-1 default; 3MF-scan fallback for
per-plate archive without dispatch record).
The FTS routes any AMS slot to either extruder, so AMS info reports
bits 8-11 = 0xE (uninitialized) and ams_extruder_map ends up empty.
The print modal's per-nozzle dropdown filter then hides every loaded
slot, leaving the user with an empty filament dropdown.
Detection: parse print.device.fila_switch from MQTT push_status into a
new FilaSwitchState dataclass on PrinterState; surface it through the
GET /printers/{id}/status response as a nullable FilaSwitchResponse.
Frontend: useFilamentMapping and FilamentMapping skip the per-extruder
filter when fila_switch.installed is true. Slots currently fed into a
track display an [L]/[R] routing badge in the dropdown so the user
can see where the FTS is currently routing them.
Tests: 4 backend unit (TestFilamentTrackSwitchDetection), 2 backend
integration (status route), 2 hook regression, 2 component regression.
Configuring AMS slots ~6 times in a row would silently stop reaching
the printer, with filament colours jumping around briefly ~1 min
later. Root cause was the zombie-session watchdog from #887.
When an ams_filament_setting response took >10 s (normal under load)
the watchdog set `_ams_cmd_unanswered=1` and zeroed
`_last_ams_cmd_time` so it wouldn't re-fire on every status push.
The response handler that resets the counter required
`_last_ams_cmd_time > 0` — so when the late response arrived, the
reset path skipped it, leaving the counter armed at 1. The next
slow response on a fresh command (possibly minutes or hours later)
would take the counter to 2 and force-reconnect mid-publish — the
in-flight command got dropped, surfacing as "Cannot set AMS
filament setting: not connected" if the user retried during the
~1 min reconnect window.
Fix: drop the `_last_ams_cmd_time > 0` guard. Any
ams_filament_setting response proves the channel is alive, so the
counter must reset unconditionally. Real zombie sessions (no
responses at all for two consecutive >10 s windows) still trip the
watchdog correctly.
Regression test in test_bambu_mqtt.py drives the exact reporter
sequence: watchdog fires (clears timer, increments counter) →
late response arrives (must reset counter) → next slow response
(must only count as 1, not 2). Other 10 zombie-detection tests
still pass.
Reprinting from archives sometimes failed immediately with a MicroSD R/W
exception, with the printer's MQTT push referencing a 3MF from a
different unrelated archive. Once it started, every subsequent reprint
hit the same error until the container was restarted.
Root cause from @smandon's support package: paho-mqtt's client-side QoS
1 queue. When the printer's command channel goes half-broken (telemetry
flowing, publishes silently dropped — same #887/#936 pattern),
background_dispatch.py:993 hits its 15s deadline and calls
force_reconnect_stale_session(). That function was force-closing the
underlying socket so paho's auto-reconnect would kick in, but the same
mqtt.Client instance, same client_id, and same in-process QoS 1 queue
stayed alive across the reconnect. Any unacked publish from the broken
session — typically the just-sent project_file for the new archive —
got replayed verbatim on the new connection. The queue accumulates
across multiple stuck dispatches in one Python process, so by the
second or third stuck reprint there were several stale
project_file/resume/stop/clean_print_error commands queued together;
the printer latched onto whichever stale path it processed last,
couldn't find the file on its SD card, and emitted 0500_4003. Container
restart was the only thing that wiped paho's in-process queue.
Replaced socket-close with a context-aware reconnect via a new
_reset_client_for_reconnect() router:
Async-context callers (dispatch deadline, FastAPI handlers via
check_staleness) → hard-reset: client.disconnect() (broker drops
session, clean_session=True), client.loop_stop() (kills paho's
network thread and its queue), null _client, fresh connect() with
incremented client_id. New connection is genuinely empty, no replay.
Paho-network-thread callers (dev-mode probe + ams_filament_setting
zombie detection inside _update_state) → socket-close fallback.
loop_stop() from inside the network thread would self-join and
deadlock, so the safe pattern there is "close the socket and let
paho's loop detect it and auto-reconnect on the same client".
Routing decision uses asyncio.get_running_loop() — paho's callback
thread has no loop, every legitimate hard-reset caller does.
7 regression tests:
- TestForceReconnectRouting (3): sync-context → socket-close fallback,
async-context → hard-reset with disconnect()+loop_stop()+null,
state-disconnected broadcast fires once on either path
- TestHardResetClientDirect (3): helper directly — old client gets
disconnect()+loop_stop(), _client cleared, failing disconnect()
doesn't propagate so background_dispatch's await chain can't break
- TestZombieSessionDetection / TestDeveloperModeProbeTimeout (updated):
paho-thread context still goes through socket-close, preserving the
legacy contract for those paths
Three bugs that surfaced together while debugging an H2D cancel:
1. Cancelling a print stamped failure_reason="Layer shift" in archives
AND left the printer card stuck on "1 problem" forever. Four causes:
(a) POST /printers/{id}/print/stop never set the user-stopped flag, so
on_print_complete couldn't override "failed" -> "cancelled".
(b) HMS-derived failure_reason heuristic mapped any module-0x0C HMS to
"Layer shift". Module 0x0C is "Motion Controller" broadly (includes
cameras, markers, AND the cancel-sequence echo 0C00_001B). Real
layer-shift codes live in module 0x03. Same false-positive class
existed for "Filament runout" (any 0x07) and "Clogged nozzle" (any
0x05). Replaced with a 23-code curated short-code map; unknowns
leave failure_reason=None.
(c) Cancel-echo HMS codes (0300_400C "The task was canceled.",
0500_400E "Printing was cancelled.") were polluting state.hms_errors
via both the hms[] and print_error parse paths. Filter them at
parse time so the frontend never sees them.
(d) Frontend bucketed gcode_state="FAILED" as a problem unconditionally.
Real failures attach an HMS error; user-cancels don't — so FAILED-
without-HMS now buckets as "finished" and only escalates to "error"
when there's an active known HMS.
2. logs/bambuddy.log was silently dropping records from named child
loggers. TraceIDFilter was attached to root_logger, but Python's
logging only invokes a Logger's filters on records originating at that
logger — propagated child-logger records skipped it, formatter raised
KeyError, handler.handleError dropped the record. Moved the filter
from root_logger.addFilter() to handler.addFilter() on each handler,
matching the filter's own docstring guidance.
derive_failure_reason() extracted as a pure function for testability.
status="cancelled" now symmetrically yields "User cancelled" alongside
"aborted".
20 regression tests across:
- backend/tests/unit/test_failure_reason_derivation.py (11)
- backend/tests/unit/services/test_bambu_mqtt.py::TestHMSUserActionFiltering (4)
- backend/tests/unit/test_trace.py::TestFilterMustBeAttachedToHandlerNotLogger (1)
- frontend/src/__tests__/pages/PrintersPageBucketing.test.ts (5; includes
the H2D-cancel-echo "FAILED + only unknown HMS" case)
When a file sliced for the wrong nozzle size is dispatched, the printer
goes IDLE -> PREPARE -> FAILED without ever entering RUNNING. Completion
detection required prev=RUNNING or _was_running=True, so on_print_complete
never fired and the queue item stayed at "printing" forever -- blocking
every subsequent pending item for that printer (check_queue seeds
busy_printers from any row in 'printing').
Fire completion on FAILED from PREPARE or SLICING too. Restricted to
those two pre-print states so a stale FAILED on first connection
(prev=None) still can't accidentally advance an unrelated queue item.
Also populate PrintQueueItem.error_message from the current HMS error
list via the existing hms_errors.py lookup, so users see e.g.
"[0500_4038] The nozzle diameter in sliced file is not consistent
with the current nozzle setting" instead of a blank failure reason.
Bambu started shipping H2C units with a new serial prefix (`31B8B…`
observed on a January 2026 unit) instead of the legacy `094…` shared by
the H2D/H2C/H2S family. Two serial-prefix-driven paths — the K-profile
edit branch in `kprofiles.py` and the delete-K-profile MQTT command in
`bambu_mqtt.py::delete_kprofile` — were silently routing the new units
through the single-nozzle format.
Match on 5 chars (`31B8B`): covers the 3-char model code plus the two
revision bytes, leaving the revision-letter slot free to iterate. This
mirrors the X2D precedent of using a longer-than-3-char prefix when a
single data point can't confirm family reuse.
Runtime dual-nozzle detection via `device.extruder.info` count and
model-string branches (`self.model in ("H2C", "H2D", …)`) are already
prefix-agnostic — no change needed there.
- backend/app/api/routes/kprofiles.py: add "31B8B" to is_h2d tuple
- backend/app/services/bambu_mqtt.py: same in delete_kprofile
- backend/tests/unit/services/test_bambu_mqtt.py: regression test
`test_h2c_new_prefix_uses_dual_nozzle_format`
Critical safety fix. The bed-jog dialog's "Home Z" button sent a bare
`G28 Z` over gcode_line. On Bambu printers where the Z endstop is at
the top (bed moves UP into it — H2C, H2D, H2S, X1 family), `G28 Z`
skips the toolhead-park step that a full `G28` runs first, so the bed
rises at full speed with nothing getting out of the way. The reporter
only escaped damage because the toolhead happened to be parked on the
purge chute.
The /printers/{id}/home-axes endpoint and BambuClient.home_axes() now
always send bare `G28` regardless of the axes argument, triggering the
firmware's safe multi-step routine (park toolhead → home XY → home Z).
The axes argument is kept for API compat but ignored; invalid values
still return 400.
Frontend retitles the button "Auto Home" and updates the dialog copy
in all 7 locales so users aren't surprised when X/Y motion happens
before Z. Parameterized regression test asserts z/xy/all all produce
bare G28.
Archive reprints and library-file prints built the MQTT project_file
command with hardcoded project_id="0", subtask_id="0", task_id="0".
Printers key per-job state (including gcode_start_time) on those IDs,
so reprints looked like continuations of the same job and third-party
MQTT observers (OctoEverywhere) reported compounding durations across
repeat replays — a 40 min job reprinted from archive showed ~1h40m,
and a second reprint of the same file showed ~4h. BambuStudio mints
fresh IDs per submission; bambu_mqtt.start_print() now does the same
using an epoch-millisecond timestamp for all three fields. md5 is
deliberately left empty to avoid activating firmware md5-validation
against a digest we can't compute without re-reading the upload.
Added 6 regression tests in TestStartPrintUniqueIdentityFields
covering non-zero IDs, md5 stays empty, uniqueness across successive
submissions, numeric-string format, and blast-radius guard on
unrelated payload fields. Updated CHANGELOG.
After hours idle the MQTT connection can degrade so telemetry still
flows but published commands never reach the printer. The existing
dev-mode probe only ran on first connect; this adds tracking for
user-initiated ams_filament_setting commands — two consecutive
unanswered commands (10 s timeout each) trigger force_reconnect.
The Bambu Lab X2D (launched April 2026, dual-nozzle, enclosed, hardened
steel rod gantry, AMS 2 Pro compatible) identifies itself as internal
model code N6 via SSDP/MQTT, and real serials begin with 20P9. None of
these identifiers existed in Bambuddy's registries, so the camera
service fell back to the chamber-image protocol on port 6000 (X2D
doesn't speak it), firmware-check logged "Unknown printer model: N6",
and the dual-nozzle K-profile paths — gated on the H2D serial prefix
"094" — would have treated X2D as single-nozzle.
Backend:
- Register N6 → X2D across every registry (PRINTER_MODEL_ID_MAP,
PRINTER_MODEL_MAP, STEEL_ROD_MODELS, ETHERNET_MODELS,
CHAMBER_TEMP_SUPPORTED_MODELS, firmware-check API keys + wiki path,
virtual-printer SSDP/product/serial tables, DB vp_model_fixes).
- supports_rtsp(): match the X2 display-name prefix and the N6 internal
code; camera now routes to RTSP on port 322.
- Dual-nozzle serial prefix check in bambu_mqtt.delete_kprofile and
kprofiles.set_kprofile broadened to ("094", "20P9") — X2D now takes
the H2D-style cali_idx in-place edit path.
- is_h2d model gate in bambu_mqtt.start_print extended with "X2D" so
timelapse / bed_leveling / flow_cali / vibration_cali / layer_inspect
are sent as integers and external-spool ams_id 254/255 routing is
preserved (H2D-style deputy-nozzle addressing).
X2D uses hardened steel rods like P2S — it is intentionally placed in
STEEL_ROD_MODELS, not CARBON_ROD_MODELS. A regression-guard test pins
the classification.
Frontend:
- mapModelCode in PrintersPage and SpoolBuddyAmsPage handle N6 and X2D.
- Enclosure-door badge and airduct-mode whitelists include X2D.
- MaintenancePage.getMaintenanceWikiUrl routes X2D to P2S wiki URLs for
steel-rod lubrication, belt tension, cold-pull, and PTFE tube
(exported to enable direct unit testing).
Tests:
- test_printer_models.py: TestX2DModel (10 assertions).
- test_bambu_mqtt.py: X2D in start_print ams_mapping and is_h2d gate;
TestDeleteKProfileDualNozzleDetection across H2D, X2D, P2S, X1C.
- MaintenancePageWikiUrls.test.tsx: 15 assertions covering X2D, P2S
regression, X1C/H2D/A1Mini regression, and model-name normalisation.
Docs:
- README: added X2 series to the supported printers table.
- CHANGELOG: new entry under 0.2.3b4 Fixed.
Credit to @krautech for the report and debug bundle, and to @legend813
for PR #989 which seeded most of the registry changes — rod-type
classification was corrected (steel, not carbon) and the dual-nozzle /
K-profile / is_h2d gaps were added on top.
Four attempts at making the printer-card SD badge stable on H2D all failed:
the final straw was powering on an A1 causing every connected H2D to flip to
red simultaneously. Bambu firmware SD signaling is not reliably derivable
from MQTT — the legacy `sdcard` field is sporadic and inconsistently typed,
and home_flag bits 8-9 are cleared on heartbeat pushes regardless of card
state with no clean way to distinguish heartbeats from full status reports.
Remove the badge from the Printers page card and the Printer Info modal,
drop `sdcard` from the frontend PrinterStatus type, and strip all home_flag
derivation and heartbeat-handling code from the MQTT parser.
`state.sdcard` is retained on the backend and populated only from a plain
truthy read of the `sdcard` field, because firmware_update.py uses it as a
precondition before starting firmware installs.
Third follow-up on the H2D SD card badge. The prior 3-strike downgrade still
lost the race: on idle printers, a nearby printer coming online (e.g. an A1
reconnecting) triggered an MQTT activity burst that let idle H2Ds accumulate
≥3 heartbeat home_flag pushes before the next full push_status, flipping every
H2D badge to red at once.
Reworked the derivation:
- the top-level `sdcard` field is authoritative when present (truthy check
handles bool / int / "HAS_SDCARD_NORMAL" string variants)
- home_flag bits 8-9 are only consulted on full push_status payloads
(detected via ≥2 of gcode_state, mc_percent, nozzle_temper, print_type,
stg_cur, ams)
- bare heartbeat pushes carrying home_flag alone no longer affect SD state
Removed the now-dead `_home_flag_seen` latch and 3-strike counter. Tests in
TestSdCardParsing rewritten to cover the new semantics.
H2D sends heartbeat-style home_flag pushes where bits 8-9 are clear
even when a card is inserted, so a single heartbeat flipped the badge
to red until the next full push. Downgrades true->false now require
three consecutive clear reads; upgrades apply immediately.
Follow-up to the earlier H2D SD card badge fix. The badge was still
flapping because Bambu firmwares send partial MQTT pushes carrying only
the legacy `sdcard` field (without home_flag), and the fallback path
re-engaged on every such push. Latch home_flag as the canonical source
once seen; reset the latch on reconnect so a firmware change still
re-learns.
When a project_file command was unacknowledged for 15s, Bambuddy
previously logged "printer may need restart" and left the broken MQTT
session in place — requiring the user to power-cycle the printer. The
existing half-broken-session recovery only ran via the developer-mode
probe path, which skips printers with a known developer_mode value.
Extract the existing force-reconnect logic into a reusable helper and
call it from _verify_print_response on dispatch timeout. The next
dispatch attempt then lands on a fresh MQTT session without a reboot.
Parse `sdcard` from `home_flag` bits 8-9 (HAS_SDCARD_NORMAL /
HAS_SDCARD_ABNORMAL) when available and fall back to a type-tolerant
truthy check on the top-level `sdcard` field. Firmware ships that
field inconsistently (bool, int `1`, or string `"HAS_SDCARD_NORMAL"`),
so the previous `is True` identity check flipped the badge to red on
every report that carried a non-bool value.
Surface four Home Assistant-style controls on the Printers page card:
- SD Card badge in the top status row (green / red, icon-only).
- Enclosure Door badge in the top status row (green / yellow, icon-only).
Detection per printer family — X1/X1C/X1E read home_flag bit 23, all
others read top-level `stat` (hex string) bit 23 — so X1 firmware that
does not flip stat bit 23 stops false-triggering "open". WebSocket
status-change dedup key now includes door_open so toggling the door
alone publishes a push, no 30s REST-poll wait.
- Airduct Mode badge beside the speed control (cooling / heating)
for P2S/H2D/H2C/H2S; one-click dropdown calls the existing
set_airduct MQTT command via a new POST /printers/{id}/airduct-mode
route.
- Force Refresh entry in the kebab menu — calls the existing
/printers/{id}/refresh-status endpoint to request a pushall snapshot
without forcing a reconnect.
Tests: door-open parsing (X1 home_flag, non-X1 stat, ignore mismatched
source, invalid hex) and airduct route (validation, not-connected,
success, failure).
The dev mode probe (ams_filament_setting to ext slot) fired on every
auto-reconnect, which destabilized some firmware MQTT brokers (A1/P1)
causing a reconnect-probe-disconnect feedback loop. Now caches the
probe result across reconnects and only probes once on first connect,
with a 5s delay to let the session stabilize.
New dedicated MQTT methods, API endpoints, and UI buttons for
loading/unloading filament from the external spool holder without
requiring an AMS. Includes state guards to prevent load when filament
is already loaded and unload when nothing is loaded.
Add timeout and retry to the developer mode probe. After a keep-alive
timeout, paho auto-reconnects but the session can be half-broken: the
printer sends status but ignores commands. The probe had no recovery —
one unanswered probe permanently blocked retries. Now times out after
10s with one retry; two consecutive failures force-close the socket for
a clean reconnect.
Race condition in _update_state: dev mode probe released GIL via MQTT
publish between raw_data overwrite and vt_tray list restoration, letting
the event loop iterate over raw dict keys (strings) instead of spool
dicts. Affects A1, P1, and X1Plus firmware that don't send the fun field.
Fix: normalize vt_tray dict→list before raw_data assignment, restore
preserved fields before any GIL-releasing work, add defensive guard in
printer_state_to_dict.
Replace polling-based bed cooldown monitor with event-driven approach.
Some firmware stops sending bed_temper after print completion, causing
the 30-min polling loop to time out on stale cached values. Now reacts
instantly to bed_temper MQTT data via a new on_bed_temp_update callback.
Single-nozzle printers (X1C, P1S, A1) report tray_now=254 for external
spool, but BambuStudio sends ams_id=255 (VIRTUAL_TRAY_MAIN_ID) in the
print command's ams_mapping2 field. Bambuddy was passing 254 as-is,
causing firmware to target AMS tray 0 instead of external spool —
resulting in 07FF_8012 "Failed to get AMS mapping table" or prints stuck
at heatbed heating when an AMS is connected but empty.
Map external spool to ams_id=255 for all non-H2D printers. H2D
dual-nozzle printers retain 254 (deputy) / 255 (main) distinction.
maziggy