2 Commits

Include renames

Author	SHA1	Message	Date
octoturge	254798e8cb	Model vt_tray and the stage fields, and use them ... ## vt_tray closes a hole in the filament decision `filament_source_for` used to refuse a project that wanted the external spool, on a printer that had an AMS, purely because there was no way to see what the spool held - and claiming a match without looking is how the `use_ams: false` bug happened. Now that `vt_tray` is on `PrintReport`, the question can be answered: `external_spool_satisfies` reuses `map_to_trays` with the spool as the single candidate tray, so an `Ok` means every filament matched it. The decision is now: the AMS first when there is one, because a project sliced for the AMS should use the AMS even if the spool happens to hold the same filament; the spool if nothing in the AMS fits and the spool does; and an error otherwise, reporting the AMS mismatch rather than the spool one since that names what was wanted against what was loaded. A reported spool that does not match is a real negative now and is refused. One case stays unverifiable: a v2 printer reporting neither AMS trays nor `vt_tray`. v2 omits the key entirely, so absence means "not reported", not "empty". That one is logged as an unverified assumption instead of being passed off as a match - and it is the same reason `EXTERNAL_SPOOLS` is still a constant. Counting reported spools would give 0 on exactly the printer the ams_mapping schema says has two. Tests use the real P1P capture's own spool (PETG P9599a25 in D3C5A3FF): it satisfies a project asking for that filament, and does not satisfy one asking for the AMS's blue GFG99. Those two were indistinguishable before. ## stage reaches the cloud `stg_cur`/`stg` are modelled, and `stage` is now on `PrinterTelemetry`, through `continuum-schemas` and the ts-types mirror. Without it progress is ambiguous in a way that reads as a fault: on the confirmed P1P run `percent` climbed to 14% while `layer` stayed 0 for minutes, the printer walking `stg_cur` 54 -> 14 -> 13 -> 0 before laying the first layer. A console showing 14% at layer 0 with no stage looks stuck. A zero stage means "printing" and has its own test on both sides, because `skip_serializing_if = "Option::is_none"` plus one `unwrap_or_default` is all it takes to turn "printing" into "no stage". The backend test asserts a *wrongly typed* stage is rejected, not just that a valid one is accepted: `PrinterTelemetrySchema` permits unknown properties - verified - so `{ stage: 54 }` validates whether or not the field is declared. The negative is what fails if someone removes it. The live capture fixture is left alone. It predates the field, the field is optional, and editing a capture by hand would defeat the point of having one.	2026-10-15 21:37:20 +00:00
octoturge	9a314b2b9f	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.	2026-10-03 10:12:05 +00:00