Files
bambuddy/backend
maziggy 64a1defa7a Stop the AMS temperature alert firing for heat the user asked for (#1802)
The alert compares against ams_temp_fair, the same threshold that colours
    the printer card, which defaults to 35C. Drying deliberately runs at 45C
    for PLA, 65C for PETG and up to 85C on an AMS-HT, and the alert repeats
    once an hour for as long as the condition holds, so a twelve-hour dry
    sent twelve notifications about a temperature the user chose. It then
    kept sending them while the unit cooled back down, which is the half the
    reporter confirmed on an AMS 2 Pro and an H2C.

    Dispatch now consults the drying state the firmware already reports.
    dry_time alone is not enough: it reads 0 through the cooling phase that
    closes a cycle, so dry_status -- info bits 4-7, already parsed for the
    drying-complete edge -- carries the rest. That constant moves out of
    bambu_mqtt into a leaf util rather than being duplicated; drying_preflight
    would have been the natural home, but it imports printer_manager, which
    imports bambu_mqtt, and bambu_mqtt is one of the callers.

    The cool-down afterwards is held by a latch released as soon as the unit
    reads back at or below the threshold, rather than after a fixed delay, so
    a 65C cycle in a cold basement and a 45C one in a warm room each get the
    time they actually need. A two-hour cap bounds the one case the latch
    cannot resolve on its own -- a unit that never returns below the
    threshold -- and since such a unit would have been alarming with no
    drying involved, releasing there restores the ordinary behaviour instead
    of inventing a new alert.

    Two exclusions are deliberate. Humidity is untouched, because during
    drying that reading falling is the whole point. And dry_status 6,
    HeatOutOfControl, is kept out of the active set: an AMS that has lost
    thermal control is exactly when the alert should still arrive, so it must
    never read as expected heat.

    A cycle plus its cool-down outlasts a restart, so the latch is a settings
    row rather than a dict beside _ams_alarm_cooldown -- the internal
    timestamp-row pattern support.py already uses. It is read once per pass
    and written back only when a unit changed it. Stamps ahead of now are
    clamped on read, since a box whose clock jumps backwards writes them and
    suppression is measured as now minus the stamp; without the clamp the cap
    would measure from a moment that has not happened yet and hold the alert
    quiet for the skew on top of it.

    No new setting. The reporter was offered the opt-out checkbox they asked
    for and said they would not want it if the alert simply never fired
    during drying.
2026-08-17 15:43:42 +02:00
..