A printer with a wrong access code gave no explanation anywhere. The connect
callback's failure branch was a bare `state.connected = False`, discarding the
CONNACK reason code the printer had just sent, so the only trace was paho's
follow-up disconnect -- logged every 30 seconds as "rc=Unspecified error",
which is exactly what a powered-off printer produces. In the report behind this
fix one of three printers had been in that loop for the whole capture, and
neither the log nor the support bundle could say why.
Bambu speaks MQTT 3.1.1, whose CONNACK return codes 4 and 5 paho maps onto
reason codes 134 and 135. Both are now logged with the printer's own reason
string and, for those two, the remedy: the access code is regenerated whenever
LAN Only or Developer Mode is toggled, so it has to be re-read from the screen.
The access code itself is never logged -- it would land in every bundle.
The reason is kept on the client as a stable slug and plumbed through
test_connection into the connection diagnostic, which now distinguishes two
cases it previously conflated. "The printer refused our credentials" is
asserted only when the printer said so; when all Bambuddy knows is that there
is no session, the text hedges and names the alternatives (rebooting, or
already at its limit of simultaneous connections). The old wording claimed the
access code was most likely wrong in both cases.
Frontend needed no change -- ConnectionDiagnostic already renders
`<status>_<reason>` variants with fallback to the plain per-status text, so an
unrecognised slug degrades to today's wording rather than a missing key.
P1-series printers have a MicroSD slot but no reachable control to enable
"Store sent files on external storage": current P1 firmware (through
01.10.00.00) never publishes support_save_remote_print_file_to_storage, so
the Bambu Studio toggle never renders, and the P1S has no screen — leaving
store_to_sdcard stuck False with no way for the user to change it. The
external_storage check reported a permanently-unresolvable fail.
Add NO_REMOTE_STORAGE_TOGGLE_MODELS (P1S, P1P) + has_remote_storage_toggle(),
kept distinct from the no-slot NO_EXTERNAL_STORAGE_MODELS. When a model has a
slot but no reachable toggle and the option is off, the check now emits skip
with params reason=unsupported_model rather than fail, and overall no longer
escalates. A P1S reporting the option on still passes. Model-scoped and
default-open, so X1/P2S/H2 (where the fail is actionable) are unaffected; if
a future firmware surfaces the capability, drop the model and it reactivates.
The frontend DiagnosticChecklist renders a reason-specific message variant
(external_storage.skip_unsupported_model) so P1 users see an accurate
explanation instead of the generic "needs a live MQTT connection" skip text.
The fix propagates to the support-bundle diagnostic snapshot automatically.
A1 and A1 Mini ship without a MicroSD slot at all - there is no
firmware-side "Store sent files on external storage" toggle and the
slicers don't surface a slicer-side equivalent either. The connection
diagnostic was reading state.store_to_sdcard (home_flag bit 11), which
is never set on these models, so the check fell through to fail for
every A1-series user. Combined with the absent slicer UI it left users
thinking Bambuddy was wrong about a setting their hardware does not
have.
New NO_EXTERNAL_STORAGE_MODELS frozenset in utils/printer_models.py
enumerates A1, A1 Mini, and their internal codes (N1, N2S, A04, A11,
A12). has_external_storage() returns False for those, True for
everything else. Unknown models default to True so the check stays
active for future Bambu lineup additions - new no-slot models must be
added to the set explicitly.
The diagnostic now short-circuits to skip before reading
store_to_sdcard when printer.model is in the set. X1, P1, P2S, H2,
and X2D are unchanged - the bit-off -> fail signal is still the right
read for them.
The companion FTP-upload-timeout symptom in the same bug report (ftp
code 28 from BambuStudio when sending to the proxy VP) is a separate
Docker-bridge-mode networking constraint, not addressed here.
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