Detects the printer-side variant of install step 4 — many users (esp. on
clean installs) forget to enable this and only notice when their archive
cards have no thumbnails. The diagnostic now catches it upfront.
Detection: read state.store_to_sdcard, which Bambuddy already parses from
MQTT push_status home_flag bit 11 (bambu_mqtt.py:153). Instant, no I/O.
An FTP upload-and-verify probe was tried first and rejected. /cache is
always writable from Bambuddy regardless of the slicer setting — only
BambuStudio's own behaviour changes when the toggle flips, not the
printer's acceptance policy. Confirmed empirically against X1C + H2D
with the slicer option toggled off: probe succeeded, home_flag bit 11
stayed True. So the only reliable signal is what the printer actually
reports about its own state.
Limitation: the printer-side variant only exists on newer firmware
(P2S 01.02 / Bambu Studio 2.6+). On older versions the toggle lives
only in the slicer and the printer never hears about it, so this check
will pass even when the user is missing step 4 in BambuStudio. The
skip-text and the wiki call this out explicitly. A reactive banner on
the no-3MF archive-fallback path is planned as a follow-up to cover
that case.
Statuses:
- pass: state.store_to_sdcard is True
- fail: state.store_to_sdcard is False (-> overall escalates to problems)
- skip: no live state, disconnected, or field never populated
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.
A triage review of the last 200 closed issues found ~1/3 were
user-side setup errors — printer not in LAN developer mode, blocked
ports, Docker bridge networking, wrong access code, cross-subnet —
each costing a multi-round-trip support exchange.
Add a Connection Diagnostic that runs those checks automatically:
- backend/app/services/printer_diagnostic.py: TCP probes of MQTT
8883 / FTPS 990 / RTSPS 322, LAN developer mode, Docker network
mode, printer/host subnet match, MQTT credential class; each
check returns pass/fail/warn/skip with a localized fix.
- Routes: GET /printers/{id}/diagnostic (saved printer) and
POST /printers/diagnostic (pre-save Add-Printer flow).
- ConnectionDiagnostic.tsx: modal + shared checklist, surfaced from
the printer card actions menu, an offline-printer quick button,
the Add-Printer dialog, and a new System-page section.
- The in-app bug reporter scans configured printers when the form
opens and always shows the result inline — a healthy confirmation,
or the detected problem and its fix.
- config.yml troubleshooting link repointed to the rendered wiki
page; bug_report.yml gains a diagnostic checkbox.
Diagnostic strings translated across all 8 locales. Backend service
unit tests (15) + frontend modal tests (3). Ruff clean, frontend
build clean, i18n parity green.
maziggy