mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-08-11 00:30:12 -04:00
14d0d14365
Queue a print against a printer class -- "Any X1C", or a Slicer Pipeline whose target type is Printer class -- with every printer of that class switched off, and nothing happened. The job sat pending and no smart plug was touched, while the same file pinned to a specific printer powered that printer on within one queue check. The reporter's log holds both halves: thirteen minutes of the item being polled as (133, None, ...) and passed over, then a PATCH onto printer 2, then "Printer 2 offline, attempting to power on via smart plug(s)" on the very next tick. Same item, same plug, same Auto On setting. Powering a printer on had only ever been written inside `if item.printer_id:`. The model-based branch below it walks the same queue but its matcher classes an offline printer as a reason to keep waiting -- printers_offline collects the *name*, for the waiting reason -- and nothing on that path ever looks at plugs. _wake_printer_for_model adds it. The model query moves into _printers_for_model so the matcher and the wake step answer "which printers can this job run on" from one place: a job can only be woken onto a printer the matcher would also have considered. Candidates that failed the cross-model gate are excluded -- switching a printer on for a file that can never legally run on it leaves the job just as stuck, with the printer now drawing power. Two things it does that the fixed-printer branch does not: A printer awaiting plate-clear acknowledgment is skipped. Waking it buys nothing; it boots into IDLE and is held by the gate. That is what the reporter's log shows for the eighty minutes after their manual edit -- "printer 2 not available -- connected=True, state=IDLE, awaiting_plate_clear=True" every thirty seconds to the end of the capture. The flag is Bambuddy-side and persisted, so it is readable while the printer is still off. At most one printer per pass, because each wake blocks the queue loop for the boot wait. Several queued jobs bring several printers up over the following minutes rather than a whole shelf at once. A failed power-on opens a 600s per-printer cool-off. Without it the walk is by id, the pass spends its single attempt on the same broken printer every time, and a healthy sibling two slots down is never reached -- one unreachable plug starves its whole model, and costs a 180s boot timeout out of every 30s pass. Entries expire on read: a printer inside its cool-off is skipped before the power-on is reached, so a live entry can never be overwritten by a success. The failed printer is deliberately NOT added to busy_printers. It is off, not busy; labelling it busy would misdescribe it in every later item's waiting reason and, because an all-busy reason is treated as needing no user action, suppress the notification too. Assignment is left to the next pass. AMS trays arrive with the first status push after connect, so matching filament against a printer that booted five seconds ago can reject the printer we just woke. Finally, the waiting reason separates "Offline: X1C-1" from "Offline, no Auto On smart plug: X1C-2". Those are different problems and only the second is one the user has to go and fix -- it was also the first question the reporter had to be asked, and the queue could not answer it. Tests cover the wake, the plate-clear skip in both gate states, all-candidates- awaiting-plate-clear waking nothing, one wake per pass, the starvation case over two passes, cool-off expiry, no-Auto-On-plug being left alone and named, an incompatible sliced model waking nothing, connected printers being left alone, scheduled-for-later and manual-start jobs switching nothing on, and a regression pin on the fixed-printer branch. |
||
|---|---|---|
| .. | ||
| app | ||
| tests | ||
| __init__.py | ||