Explain the printer's error codes instead of relaying numbers - #6
Conversation
Bambuddy's `hms_errors` entries carry no description at all — the schema is code/attr/module/severity/actions/full_code, and `code` is only the low half of the identifier. So an alert read "⚠️ Fehler: 0x4003", which tells nobody what to go and do. The sentence behind a code lives in Bambu's public catalogue, the same one Bambu Studio queries. `hms.py` looks it up against a bundled copy (both languages, ~65/40 kB gzipped) — bundled rather than fetched so the bot can still explain an error while the internet is down. `scripts/refresh_hms_codes.py` regenerates it after a firmware update. Both namespaces the printer mixes into that one list are covered: 16-char HMS codes (which encode the AMS unit and slot, so the text names the real slot) and 8-char print_error codes. An unlisted code still goes out as a number — that's what the wiki and support ask for. Severity picks the marker: 🛑 /⚠️ / ℹ️. Used by the intervention alert, !progress (on its own line — an explained error is a full sentence and would wreck the " · " status strip) and the failure notice, which previously said nothing at all when Bambuddy left error_message empty, i.e. almost always. Alert identity now keys on the full code, so two different faults in the same module no longer collapse into one incident. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bambu's catalogue endpoint takes `?d=<serial prefix>` — `01P` is our P1S, the same three characters Bambuddy keys its HMS action table off. Checked what that actually changes: nothing in the wording. Of the ~3900 codes the scoped and the generic list share, zero differ in text; scoping only filters the set. The P1S list omits 35 codes for hardware it doesn't have and knows 4 that the generic list leaves out — part-cooling fan, Ethernet accessory, SD-card wear. So fetch both and merge. Taking only the scoped list would leave rarer codes unexplained; taking only the generic one loses the fan fault on the single printer that can report it. A test pins the P1S-exclusive codes so a future refresh can't quietly drop the device fetch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Nachtrag: sind die Texte P1S-spezifisch? Nachgeprüft — jein, und es hat eine Änderung nach sich gezogen. Bambus Katalog-Endpoint nimmt Das Skript holt jetzt beide und merged ( |
1 participant
Was
Bambuddy hands the bot the error number only — its
hms_errorsentries have no description field (code/attr/module/severity/actions/full_code), andcodeis just the low half of the identifier. An intervention alert therefore read:Now it reads:
Wie
hms.pyresolves a code against Bambu's official catalogue — the same source Bambu Studio queries — bundled offline inhms_data/hms_{de,en}.json.gz(~4000 HMS + ~550 print_error codes per language, 65/40 kB). Bundled, not fetched: the bot must be able to explain an error while the internet is down.0700-2000-0002-0001, encode AMS unit + slot, so the text names the real slot) and 8-char print_error codes (0702-8002).full_codeis the key; when it's missing it's rebuilt fromattr+code.scripts/refresh_hms_codes.pyregenerates the tables after a firmware update.Wo es auftaucht
Fehler: 0x4003!progresserror_messageist selten gefüllt)Alert identity now keys on the full code, so two different faults in the same module no longer collapse into one incident.
Tests
225 pass (
./.venv/bin/python -m pytest tests -q) — newtests/test_hms.pycovers real catalogue lookups in both languages, theattr+codereconstruction, print_error codes, severity markers, unknown codes, junk-payload safety (this runs in the completion poller, where one exception kills the cycle for every tracker), plus the failure-message fallback.🤖 Generated with Claude Code