mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-10-02 12:15:36 +02:00
maziggy
71709c16aa
A printer in FINISH with an unacknowledged plate and something pending in its queue stopped and restarted drying once per scheduler tick, for as long as the plate stayed unacknowledged. The reporter's Home Assistant history recorded about 2000 state changes over ten days. No cycle ever ran long enough to remove moisture, and cycles the user had started by hand on other AMS units of the same printer were torn down with it. Two concerns had become tangled. Plate-clear answers "is the bed ready for the next job" and says nothing about whether the AMS may heat. The gap between a finished print and the acknowledgment is when drying is most useful -- the printer is free and nobody is waiting on it -- and leaving the plate unacknowledged is also how people hold the queue by hand, so the hold was costing them the drying it should have enabled. Four faults, all in print_scheduler. The "print takes priority" stop sat inside the not-idle branch. Drying is not one of the things _is_printer_idle looks at, so stopping a cycle can never turn a non-idle printer into an idle one: the stop was futile every time it fired, and never fired on the dispatches where it was supposed to mean something. It now runs when the printer is actually dispatchable, and only where the model cannot dry through a print -- #2758 settled that capable hardware should keep its cycle. mid_print was inferred from busy_printers, which means "the queue could not dispatch here this pass", not "is printing". A plate-held printer was therefore treated as printing: the mid-print spool-protection cap silently lowered its drying temperature, the cycle was logged as (mid-print) in FINISH, and it bypassed the very gate meant to hold it. busy_printers keeps its dispatch role; auto-drying now gets a narrow set snapshotted before the item loop -- running, held post-dispatch, or mid-upload -- and mid_print comes from the printer's own state. The interlock comment at the seed already documented this hazard and worked around it by staying out of the set; this generalises that instead of adding a third special case. The other call site was already passing the narrow set, so the wide one was the inconsistency. _stop_drying sent a stop to every AMS reporting dry_time > 0. One auto-dried unit was enough to kill a manual cycle on a different unit of the same printer, contradicting the contract _sync_drying_state already documents: the entry gate only knows about cycles Bambuddy began, so the action must not reach past them. Consequence worth stating -- after a restart Bambuddy cannot prove a running cycle is its own, so it leaves it alone rather than risk stopping somebody's manual dry. Fourth, and the reason #2770's guard did not catch this: a reading at or below the threshold popped the unit's whole entry, ended_at included, so the 30-minute re-arm cooldown went with it. An AMS reads higher warm than cool, which is #2770's own finding, so a unit a point or two above the threshold dipped below it as it cooled, wiped its history, and re-armed immediately. Lifting a suspension now clears the judgement and keeps the clock. queue_drying_block changes behaviour as a result. It previously had no effect on dispatch at all -- both branches skipped anyway, and it only decided whether drying was needlessly killed. With the stop on the dispatch path it now does what it says: a queued print waits for a running cycle. Off by default. Reported by @superflyer11, who traced both defects to the line and brought ten days of external sensor history to date the cadence.