3 Commits

Include renames

Author	SHA1	Message	Date
octoturge	9359add6aa	Drive Klipper, OctoPrint and PrusaLink for real ... The three were println stubs. Each is now an HTTP client (Moonraker, OctoPrint's REST API, PrusaLink's v1 API) behind a small shared helper: status polled in the background, pause/resume/cancel, G-code lines, fan speed, and upload-and-start of a sliced file. A slicer project (.3mf) is refused for these, and so is an upload while a print is running. Telemetry and the completion watcher now read a vendor-neutral PrinterStatus instead of Bambu's PrintReport, so these printers report progress, temperatures and job state to the cloud. Written from the public API docs and tested against mock servers only; no real Klipper, OctoPrint or PrusaLink machine has been on the bench.	2026-10-30 07:49:31 +00:00
octoturge	7d4cf41999	Confirm the light and the upload on a real P1P ... Four things were shipped unverified because the printer was off when they were written. Three are now confirmed first-hand (P1P, 2026-10-15), and one is settled in the opposite direction from what was assumed. **`set_light` had never once reached a printer**, and `completion::run` blinks a finished print's chamber light with it. It works - but "accepted" is not "it changed": `ledctrl` answers `result: "success"` as soon as the command parses, exactly like the print-control verbs. So `lights_report` is now modelled on `PrintReport`, which is the only read-back there is, and the probe polls it rather than printing a reassuring message. Setting the light on and off reads `[{"node":"chamber_light","mode":"on"}]` / `"off"` back, about 3s later. The field was observed on v1 even though only the v2 schema declares it. **The blink itself works at the rate it ships at.** `completion::celebrate` is now public so the probe runs the real function instead of a copy: twenty `ledctrl` commands half a second apart, which a printer is entitled to refuse. None were refused, it returned after 10.35s, and the light ended `off` as specified - a blink that leaves the light on would look like a printer still working. **The firmware's own `flashing` mode is not the better option.** It is accepted, and the reply echoes all four parameters back (`led_on_time`, `led_off_time`, `loop_times`, `interval_time`), so the printer does parse them. But `lights_report` never reports `flashing` - it stayed on the previous mode for 12s of polling. A firmware blink is therefore unobservable: nothing can confirm it happened or tell when it ended, while the self-driven blink is built from a call that reads back. That is a better reason to keep `celebrate` than the one in the comment it replaces, which was that `loop_times` semantics were unconfirmed. Whether the light physically blinks is still unwitnessed - nobody was watching the machine. **Multi-MB FTPS upload works, and is slow.** A 4.96 MB project archive went up with an exact byte count and came back byte-identical (sha256). But it took 31.3s - about 0.2 MiB/s - so the 62 MB project already on that card would take six and a half minutes. Anything that uploads a job needs a timeout budgeted in minutes, not seconds. The claim in `download`'s comment that these files are "a few hundred KB" is gone; the card disproves it. Also adds `delete`, because the probe left a 5 MB file on a real SD card and there was no way to remove it. One explicit path, no globbing: the convenient version of this deletes something somebody printed from last week. Used to clean up, and the card is back as it was. New probe steps: `light on|off|flash`, `blink`, `upload <local> [name]`, `delete <path>`. 51 tests still pass.	2026-10-15 22:23:41 +00:00
octoturge	c22ccf5d22	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.	2026-10-15 21:27:24 +00:00