maziggy 3ce4ecfcf7 Report a print stage we cannot name at the default log level ...

STAGE_NAMES is hand-maintained and every new model adds to it, so a printer
    occasionally reports a number that is not in it and the card reads "Unknown
    stage (72)" -- which an H2C did, where the table runs to 66 and then jumps
    to 74. Stage transitions were logged only at DEBUG, off in normal running,
    so the sole record that it had happened was the card itself, and by the
    time anyone looked the printer had moved on.

    The asymmetry is the point: a stage we can name is worth DEBUG, and the one
    we cannot is the interesting one. An unnamed stage is now logged at INFO,
    once per stage number per session, with the model, the stage it came from
    and the print state at the time -- which is what naming it afterwards
    needs. Named stages are unchanged, so a normal print logs nothing new. -1
    is excluded: it is Bambuddy's own "not in a stage" sentinel and the field's
    initial value, so every print would otherwise report it on the way out of
    its last real stage.

    Fixes a latent crash found while testing this. The stage-change log line
    builds its text before the log level is consulted, so get_stage_name runs
    on every transition whatever the level is set to; a stg_cur that was not
    hashable -- malformed telemetry rather than an unknown stage -- raised
    TypeError out of STAGE_NAMES.get and aborted the whole state update.
    Labelling a value can no longer do that.

2026-08-15 14:58:45 +02:00

..

app

Report a print stage we cannot name at the default log level

2026-08-15 14:58:45 +02:00

tests

Explain Bambu Cloud's CAPTCHA challenge instead of repeating it (#2790)

2026-08-15 14:42:27 +02:00

__init__.py

…