2 Commits

Include renames

Author	SHA1	Message	Date
octoturgeandClaude Opus 5	6ff0c9a649	Derive the AMS mapping from the project, and blink on completion ... Two changes, both following from the print that paused at 1% because `use_ams: false` pointed an AMS-sliced project at the external spool. ## upload_project_file no longer guesses It now reads the `.3mf` it already holds and works out where each filament should come from. `Metadata/slice_info.config` names every filament's `tray_info_idx`, type and colour; the AMS report names the same three per loaded tray; matching them is the whole job. `src/printer/project_file.rs` does the reading and matching and is free of printer types, so it is testable without a printer - which is the only way this gets tested at all, the alternative being to notice a mapping bug by watching a machine print in the wrong colour. The mapping is derived *before* the upload: a project that cannot be matched should not result in a file being moved onto the machine that cannot then be printed. It never falls back to the external spool to make an unmatched project "work". The one case it answers `ExternalSpool` for is a printer reporting no AMS trays at all. A printer *with* an AMS whose project wants the spool is an error, not a fallback, because `vt_tray` is not modelled on `PrintReport` - there is no way to check the spool holds the right material, and claiming a match without checking is how this went wrong the first time. Two fixtures carry the real cases: `cube_slice_info.3mf` is the project that cost the print (deflated on purpose - every other test archive is Stored, so the decompression path and the flate2 backend behind zip's `deflate-flate2` would otherwise never run), and the existing `push_status_v1_p1p_idle.json` supplies the AMS side. The end-to-end test asserts they agree on `[3,-1,-1,-1,-1]`: both slots hold PETG GFG99 and only the colour tells them apart, so a matcher stopping at `tray_info_idx` would print the cube in black. A malformed `<filament>` element is an error rather than a skip. A skipped filament leaves a hole at its index, the hole becomes `-1`, and the printer is told that material is unused - so the plate prints in whatever remains mapped. New dependency: `zip` 9.0.3 (MIT) with `deflate-flate2`, plus `flate2` for a backend, which zip's feature does not select on its own. All six new crates are MIT, MIT/Apache-2.0, 0BSD/MIT/Apache-2.0, MIT/Zlib/Apache-2.0 or Zlib, and `cargo deny check licenses` passes. No bzip2, lzma, xz or zstd entered the graph. ## Lights on completion `completion::run` is a third daemon task that notices a print finishing and blinks that printer's chamber light for ten seconds, then leaves it off: 500ms on, 500ms off, twenty commands, ending dark. Its own task rather than a branch in the uplink's telemetry loop, because that loop only ticks while the cloud connection is up - and a light that only works when the internet does is not much of a notification for someone standing next to the printer. Three rules, each a false celebration avoided and each tested: only a *transition* into `FINISH` fires, because `FINISH` persists until the next print starts; a printer seen for the first time never fires, so restarting the gateway does not announce prints that finished yesterday; and `FAILED` never fires, because that is what a Bambu reports for a cancellation, including every `print.stop` this software sends. The blink is driven from `On`/`Off` rather than the firmware's `flashing` mode. `flashing` is in the schema but the meaning of `loop_times` versus `interval_time` is unconfirmed, so "blink for ten seconds" could not be predicted; two obvious commands give an exact duration. The light is left off even when a blink fails part-way, since a machine abandoned with its light on looks like one still working. `set_light` is **unverified against hardware** - the P1P was powered off when this was written, and the doc comment says so. The shape is built from `schemas/bambulab/{v1,v2}/request/system/ledctrl.schema.json` rather than by hand, and it goes out as a correlated request so a rejection is visible. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-15 21:27:24 +00:00
octoturgeandClaude Opus 5	1d95451c4c	Fix print.push_status parsing, and stop losing reports silently ... Pointed at a real H2C that was 20% into a job, `print_status()` returned nothing at all. The printer was in fact pushing a full status object every second; every one was arriving, failing to deserialize, and being dropped invisibly by an `if let Ok(report) = ..` with no `else`. That silence produced two confidently-wrong claims in our own comments, both corrected here: - `pushall`'s doc said whether v2 emits `push_status` unprompted was "an open question". It is not: v2 pushes a full 97-field object roughly once a second from the moment you subscribe, no trigger needed. There is no missing "other trigger" to hunt for. - The "sequence gap" warning blamed the network for dropped v1 updates. Those updates were not dropped in transit - they failed to parse, so they never reached the counter, making the next one that did look like a skip. Confirmed: seq 57, 62, 64 and 69 all arrived. After the fix, zero gaps and zero parse failures across a 25s run against both printers. Two concrete causes, both found with captured payloads: - v1 trays carry `tray_temp`/`tray_time`; v2 trays carry `drying_temp`/`drying_time`. All four were required, so *every* v1 push carrying AMS data failed. - A third tray shape existed that nothing modelled: an empty v2 slot sends `{"id": "2", "state": 0}`, which matched neither `EmptyTray` (it denies unknown fields, deliberately) nor `LoadedTray` (16 fields short). A parse failure now reports itself, naming the printer, the sequence id and the serde error. A report this process cannot parse is a defect in `PrintReport`, and the only way to fix it is to be told which field. `PrintReport` itself modelled 9 of 97 top-level fields, and none of them were progress or temperature - it was built from a truncated example. It now carries gcode_state, percent, layer counts, remaining time, nozzle/bed temperatures, fan gears, wifi and HMS entries. `merge_from`'s two dozen four-line blocks collapse to `newer.x.or(self.x.take())` one-liners: the old shape made adding a field a three-place edit, and forgetting the merge half produced a field that silently never survived a partial update. Two scale traps documented where they bite: reported fan speeds are 0-15 gears, not percent and not the 0-255 PWM we send (`set_fan_speed(50)` reads back as "7"); and v2 pins `sequence_id` to one value for minutes while contents change, so it orders and identifies nothing there. Two examples, and the distinction between them is the point. `live_reports` is read-only and safe against a printer mid-job. `bambu_idle_checks` writes, so it requires an explicit printer id and refuses to run unless that printer reports `gcode_state: "IDLE"`. Regression fixtures are verbatim captures off both printers, hardware identifiers scrubbed - the only way to keep this from regressing without a printer plugged in. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-03 10:12:05 +00:00