Updated CHANGELOG.md

CHANGELOG.md

@@ -22,6 +22,8 @@ All notable changes to Bambuddy will be documented in this file.
 
 - **Server-side slicing on an ARM64 host, for people with no x86_64 machine to point it at (#1821, contributed by @Felix-Rm)** — Both slicer sidecars ship as `linux/amd64` images and nothing else: OrcaSlicer's community ARM64 AppImage fails to extract under QEMU build emulation, and Bambu Studio publishes no ARM64 build at all, on any platform. That left ARM64 owners — a Pi 5, an ARM NAS, an Ampere VM — with one route to server-side slicing, which was to run the sidecar on a separate x86_64 box and point Bambuddy at it over the network. That is still the recommendation, because it is the only one that runs at full speed. For anyone with no second machine to spare, `slicer-api/docker-compose.arm64.yml` now pins both sidecars to the amd64 images so they run on the ARM64 host itself under QEMU, and it is proven on real hardware rather than assumed: a Debian 12 / RK3588 board slicing the same models as an amd64 box. It is a separate override file rather than two lines in the default compose file, for three reasons. It is slow — 3-6x native on that RK3588, worse as models get more complex, and an RK3588 is at the fast end of ARM SBCs, so a typical ARM NAS fares worse still. It needs QEMU binfmt registered on the host first, which not every appliance NAS will allow, and without it the containers die with `exec format error` — a worse failure than today's clear pull-time "no matching manifest", so it must be chosen deliberately rather than inherited. And a platform pin in the default file would silently keep every ARM64 user on emulation the day native ARM64 images do ship. Opting in is one line in `.env` (`COMPOSE_FILE=docker-compose.yml:docker-compose.arm64.yml`) so that every later `docker compose pull` and `up -d` keeps the override instead of quietly dropping it — the failure that recipe exists to prevent. The prerequisites, the per-distribution binfmt commands and the performance expectation are in the README and the wiki.
 
+- **A drying run can be scheduled for later, so it happens while nobody is standing at the printer (#2638, contributed by @bhamiltoncx)** — Manual drying was immediate only: someone had to be there to press Start, which meant either drying in the middle of the working day or not drying at all. The drying popover now has a **Start time** — **Now**, **After delay** or **At time** — and the last two queue the run instead of sending it, which is what makes an overnight dry on an off-peak tariff possible. The time you pick is the *earliest* start, not an exact one: the run begins on the first scheduler pass after it when the printer is idle and the AMS is actually able to dry, so a printer still working through the queue at 2am dries when it finishes rather than colliding with a print. While a run waits, the printer card says what it is waiting for rather than sitting silent — the printer being offline or busy, the AMS already drying, the AMS not being reported at all, and separately the two states nobody can wait out: the power adapter being unplugged and filament left at the AMS outlet, both of which name what to do. Cancel a pending run from the same card. A scheduled run goes through the same preflight the immediate button does, which is the point of the feature rather than an implementation detail: a model that can only dry from its own screen is refused when you schedule it, not hours later, and a firmware too old to accept the command — which cannot be checked while the printer is offline, the one case that reaches dispatch — fails the run visibly in red with the reason instead of publishing a command the printer ignores and then quietly cancelling itself. Failed runs stay on the card until dismissed. If a print claims the AMS mid-cycle the run returns to pending and gets its full duration again once the printer is free; stopping the dryer yourself while the printer is idle is read as meaning it, and cancels. Smart-plug **Auto Off After Drying** covers these runs like any other, since it keys off the printer's own telemetry. Viewing scheduled runs needs `printers:read` and scheduling or cancelling one needs `printers:control`, the same permission the immediate button has always used; finished rows are kept for seven days. One limit worth stating: nothing caps how *late* an interrupted run restarts, so a job interrupted overnight can resume in an expensive part of the day — check the card after an interruption if you are drying to a tariff. Wiki updated. Covered by backend and frontend tests.
+
 ### Changed
 - **A filament whose exact colour is not loaded now prints in the closest one available, not the first one within tolerance (#2804)** — When a file asks for a colour no spool matches exactly, the matcher falls back to spools that are close enough. It picked whichever of those came first in AMS slot order, so the winner depended on which slot a spool happened to sit in: a required `#3A7BD5` with a purple `#6253AD` in tray 1 and a near-identical `#3B7AD2` in tray 3 took the purple, and moving the spools between slots changed the outcome with nothing else changed. Eligible spools are now ranked by how close they actually *look*, and the nearest wins. Closeness is measured with CIEDE2000, the CIE's perceptual colour-difference formula, rather than by subtracting the RGB numbers — those two disagree often enough to matter, because RGB arithmetic overstates blue badly: against a dark green requirement it rates a purple as the nearer of two eligible spools and a green as the further one. Which spool qualifies as close enough is unchanged — the same per-channel tolerance as before — so no spool becomes usable or unusable because of this, only better or worse ranked among those already eligible. **This changes which spool some prints use.** If **Prefer Lowest Filament** is on, its ordering previously decided the fallback outright, and it now acts as the tie-break between spools that are equally close, on the grounds that printing in the right colour matters more than burning down a part-used spool, and that two equally close spools is the case that preference was actually for. Alpha is still ignored on both sides, so a transparent filament keeps matching its own colour. The four places that pick a spool — the scheduler's matcher and the three in the interface — now share one ranking rule instead of carrying four copies of it, which is what allowed them to disagree. The scheduler also logs which rule won for every slot it maps, and the colour distance when the winner was a near-match, rather than only doing so when Prefer Lowest was switched on; "why did it pick that spool" is answerable from the log now. Covered by backend and frontend tests.
 - **Preheat no longer gives up on a chamber-heated print whose file carries no bed temperature (#2727, contributed by @ticfinack)** — Preheat read its bed target out of the slicer metadata, and a file that carried none — common in OrcaSlicer's `gcode.3mf` exports — made it skip the whole stage and start the print against a cold chamber, which is the outcome preheat exists to prevent. Where the print needs chamber heat the bed is simply how that heat is produced, so those jobs now heat the bed to the **Keep-warm bed temperature** instead of bailing out. A bed temperature found in the file still wins, and a print with no chamber requirement still skips, so no bed temperature is invented for the print itself; preheat's target is transient either way, since the print's own G-code sets its bed at start. **If you have preheat enabled and your files carry no bed temperature, dispatch will now take noticeably longer than it used to** — those jobs previously skipped straight to the upload and will now wait for the chamber to converge and soak, up to twenty minutes at the default wait and soak settings. This applies only with preheat switched on, and the two settings that govern it are unchanged. In the same pass, preheat gained the soak-crediting described above: on a printer that reports its chamber temperature, a soak the chamber has demonstrably already served is shortened or skipped rather than repeated. Both apply wherever preheat runs, not only under the new keep-warm toggle.