63 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
octoturge	c6cf9bcb5e	Report discovered printers to the cloud, off by default ... The gateway could already find printers; only a human reading a terminal could see the result. So adding a printer in the web console still began with walking to a machine to read its IP address off the screen. Now a background task scans on a timer and sends a `discovered_printers` frame. It cannot finish the job - the credential is on that screen and no probe can read it - but it removes the address, the serial and the guesswork about which vendor the thing is. OFF by default, which is the load-bearing part of this commit. A /24 sweep is 254 TLS handshakes and up to three HTTP requests per host, and nothing watching can tell that from a port scan; on a corporate network, being indistinguishable from a port scan is itself the problem. A gateway that did this by default would scan networks its operator never meant to point it at, and the first they would hear of it is from their own security team. So: - `discovery.enabled` is false unless set, per gateway, in that gateway's own config. The cloud cannot switch it on. A setting whose whole purpose is to bound what this process does to the local network has to be decided where that network is understood, which is not in a data centre. - `subnets` is explicit, never derived from this host's interfaces, so a second NIC, a VPN or a container bridge cannot widen the sweep. Anything wider than a /24 is still refused, now at config-import time rather than when the timer first fires. - A flag that is neither `true` nor `false` is an error, not a shrug. The two readings of a typo are not equally safe. - Naming a subnet without setting `enabled` scans nothing - the safe reading of an incomplete instruction - and `enabled` with nowhere to look is refused as the mistake it is. - The env var can switch it *off* over a file that enables it, which is the direction that has to work: a Proxy Box's config is signed in the cloud, so an operator who finds their gateway probing cannot just edit it. What a scheduled scan will not do, unlike the example CLI: send `M115`. Opening a serial port toggles DTR, which reboots an Arduino-based board and ruins a print in progress. The example can do it behind `--yes-reset-the-printer` because a human is standing there; a timer has nobody to ask, so it does not get the option and reads sysfs instead. Two things that took more care than expected: `Scan::looked()`. An empty report means "this gateway looked and its network has no unconfigured printers", so sending one after every probe failed would state something untrue about the farm. A partial failure is still evidence, though - withholding a good sweep because a container can never bind SSDP would suppress it forever - so the test is "did anything succeed", not "did everything". `fleet::configured()` reads the fleet file at parse level rather than through `load`, because the entry it most needs to recognise is the one `load` refuses: a printer discovery suggested, pasted in, with the access code not yet typed in. Re-offering that printer as a fresh find is noise at the one moment the operator is mid-way through adding it. Verified against the real LAN: a sweep found both printers by TLS certificate with correct serials and no credentials, and the frame it produced validates against the backend's EdgeClientMessageSchema. The `wire` subcommand on the example prints exactly that frame, and the capture is pinned as a backend fixture. SSDP remains untestable here - this container is a router hop from the printers and multicast does not cross one.	2026-10-19 08:21:30 +00:00
octoturge	1cd8ce25c3	Authenticate config bundles: Ed25519, per-box identity, no plaintext ... The hash in a bundle only proved it was undamaged. Anyone who could write the stick could write both files, so a Proxy Box would install a config handed to it by whoever got physical access - including a config pointing the box at a different cloud. Encryption alone does not fix that either. While plaintext was accepted an attacker simply did not encrypt, and the box took it. So a Box now refuses plaintext outright, and the bundle carries a signature. A third entry, `config.toml.sig`: strict TOML with `box_id`, `config_version` and a raw Ed25519 signature. What is signed is `signed_message()` - a domain tag, the length-prefixed box id, the version big-endian, then the raw `config.toml` bytes. Raw bytes rather than the archive, so the signature is independent of ZIP framing, compression, entry order and encryption. The box id and version are inside the signed message rather than beside it, so neither can be edited without breaking it, and the length prefix stops a byte-shifting collision between the id and the config. Past decryption the order is hash, signature, box id, version, then parse and validate. The claims in the `.sig` are attacker-controlled text until the signature over them verifies, so nothing is concluded from them before then - and nothing about this box's identity is revealed before then either, which is why unsigned junk cannot be used to probe which box it is talking to. Which error wins when a box cannot even open a bundle: a signature over the plaintext is only checkable after decryption, so a box with the wrong key cannot distinguish "meant for another box" from "forged". Wrong key wins. Neither bundle installs either way, it is nearly always the true cause, and calling something forged that we could not open would be an accusation we cannot support. Replay is enforced rather than documented away: `config_version` must not go backwards, recorded in a sidecar beside the installed config. An equal version is accepted on purpose, because the version is written before the config, so a power cut between the two leaves "new version, old config" and re-inserting the same stick repairs it. The other write order would leave a replay window instead. Both key sets are lists, so the cloud's signing key and a box's own key can be rotated. `load_provisioning()` is the single seam where a box's identity and keys come from; a TPM or secure element replaces that function and nothing else. A missing file means unprovisioned, and the box then says loudly what it cannot check - but an empty or malformed one is an error, because quietly reading a broken key file as absent would turn a provisioning mistake into a box that accepts unsigned bundles. Not verified: interop with the real cloud signer. These tests prove the box accepts what this code defines as correct, not that the cloud will produce the same bytes - the message layout, the pure-Ed25519-no-prehash choice and the `.sig` shape all need a cross-check against the configurator's own crypto library once it exists. A compromised cloud signing key still breaks every box trusting it; revocation is not built.	2026-10-19 08:08:27 +00:00
octoturge	ad55645ec9	Accept an AES-encrypted config bundle from the cloud ... The bundle is authored by Continuum Cloud's configurator and downloaded by the customer, so it travels over the internet and then on a USB stick while holding the gateway token and possibly a wifi PSK. That makes it a secret at rest, and confidentiality is the benefit encryption actually delivers here. WinZip AES-256 ("AE-x"), via the zip crate's `aes-crypto` feature. That pulls in aes, hmac, pbkdf2, sha1, constant_time_eq and zeroize - all permissive (MIT/Apache-2.0, and CC0-1.0 OR MIT-0 OR Apache-2.0 for constant_time_eq), each checked against docs/LICENSES.md, and `cargo deny check licenses` passes. **Legacy ZipCrypto is refused outright**, whatever key is configured: it falls to a known-plaintext attack. The test is on metadata, not on a failed decrypt - `encrypted()` is set for ZipCrypto and AES alike, but only AES carries the AE-x extra field, so encrypted-without-it is ZipCrypto and the whole bundle is rejected. Judged in the first pass, before any decrypt call, so the crate's ZipCrypto path never runs on our input. Mixed bundles - one entry encrypted, the other not - are rejected too. The caps now bound *decrypted* output, so a small ciphertext that inflates is capped exactly as a plaintext bomb is. Everything else holds unchanged for an encrypted bundle: zip-slip, the inner config.toml.sha256, the no-environment validation, atomic install, and a rejected bundle never touching the installed config. Failures are distinguished, because "wrong key" and "damaged" need different answers: no key on the box and a wrong key both say "not for this box", while tampered or damaged ciphertext says it failed its AES integrity check. A wrong key passes AES's 16-bit password check 1 time in 65536 and then fails the HMAC, so that message names a wrong key as a possibility. **The limitation to be clear about: with plaintext bundles still accepted, encryption does nothing against tampering.** An attacker supplies a plaintext bundle and never touches the crypto. The tamper goal only begins to hold once `accept_unencrypted` is false, which is one line in main.rs and is deliberately not flipped yet - doing so breaks every stick made before the configurator encrypts, and every hand-made development stick. That is a product decision, not a code one. More generally, encryption is not authenticity: the AES HMAC detects modification only by someone without the password, and the password has to live on the box, so extracting it from one image breaks every box sharing it. It raises the bar from "anyone with a text editor" to "anyone who can read a firmware image". The module docs say exactly that and do not call it tamper-proof. `check_authenticity` is a named no-op where an Ed25519 check over the config, verified against a *public* key in the box image, belongs - it verifies nothing and says so, so the missing authenticity is a searchable gap rather than an implicit one. `load_bundle_key` is the single marked seam where provisioning lands. Its current `$CONTINUUM_BUNDLE_KEY_FILE` / `/etc/continuum/bundle.key` lookup is a placeholder, not a decision: shared-vs-per-box keys, where the key lives, and rotation are open product questions and the mechanism depends on none of them. Encrypted fixtures are genuine AES ZIPs written by the zip crate itself, and one test confirms the config text is absent from the ciphertext. The ZipCrypto fixture sets the encrypted flag without an AE-x field, which is the metadata shape this must refuse. Unproven: interop with whatever ZIP writer the cloud actually uses (only archives written by this same crate version were read back), AES-128/192, and `load_bundle_key` itself, which reads process env and so has no test.	2026-10-19 07:56:25 +00:00
octoturge	64d46dbc49	Load proxy settings from a file, and import them from a pendrive ... Everything came from CONTINUUM_* environment variables, which suits neither shape the product ships in. A Proxy Box is an appliance whose settings arrive on a USB stick; a proxy on someone's PC is a config file they edit. Precedence is stated once, in config.rs: the file is the base, env overrides it, defaults fill the rest. `Config::from_env` keeps its behaviour and the struct is unchanged, so existing callers and tests are untouched. Layering is `Config::layered(file, env_lookup)` with the environment injected as a closure, so tests do not have to mutate process env to cover it. The bootstrap is read from $CONTINUUM_BOOTSTRAP, then /etc/continuum/bootstrap.toml, then nowhere - and nowhere means PC mode with ./continuum.toml, so an env-only deployment behaves exactly as before. The working directory is deliberately not searched, and the bootstrap itself must never come from a stick: it is what says whether sticks are trusted at all. Bundle format is continuum-config.zip holding config.toml and config.toml.sha256. The hash is checked before the bytes are parsed - the TOML parser should not be the first thing to read possibly-corrupt input - and **the comments say plainly what that buys: corruption and change, not forgery.** Anyone who can write the stick writes both files. It is an integrity check under a recorded trust assumption, that physical access to the box is trusted; a signature with the key in the box image is named as the follow-up that would give authenticity. sha256 via openssl, already a direct dependency, so no new crate and `cargo deny check licenses` still passes. The hazards of ingesting a file off removable media, all tested: Zip-slip is refused on absolute paths, `..` components, backslash separators, drive prefixes, NUL and non-UTF-8 names, and one bad entry rejects the whole bundle rather than being skipped. The stronger guarantee is structural though: entries are only ever read **by index, matched against two literal names**, and no write path is ever derived from an archive name, so a hole in the name check still writes nothing. A test confirms a bundle carrying `../evil.toml` alongside a valid config writes nothing outside the target and leaves the installed config alone. Zip bombs are capped at 16 entries, 256 KiB per entry and a 1 MiB file on the stick. Declared sizes are refused in a first pass that decompresses nothing, and a bounded reader then caps actual output so a lying header gains nothing. Installing is atomic: temp file in the destination directory - not /tmp, since rename is only atomic within a filesystem - created 0600 from the first byte because the config holds the gateway token, fsync, rename, then a best-effort directory fsync. A write that fails halfway leaves the previous config intact and no temp file behind. A bad stick never costs the box its config: a bad hash, bad TOML, an unsafe entry or missing settings all return Rejected and are logged as keeping the existing config. A correctly-hashed config is also validated **with no environment at all**, so a stick cannot install something that parses now and fails to start on the next boot - which would be a bricked box caused by exactly the stick we were being careful about. PC mode ignores pendrives twice over, by mode and by an emptied directory list, because on a general-purpose machine importing settings from a USB stick would be a way to change them behind the user's back. A [network] block is parsed, validated and exposed, and stops there. main.rs logs a warning that this build does not apply it, so a box given network settings cannot look like it acted on them. Applying them needs root, is specific to the appliance image, and a wrong write strands the box - it wants its own decision, not a side effect of reading a file. continuum.toml is gitignored, since it holds the gateway token. Not done, and not claimed: no signature, so no authenticity. There is no real pendrive here, so the removable-media path was tested with ordinary directories standing in for mount points - real udisks/udev mounts, FAT behaviour, a genuinely yanked stick and how promptly the 5s poll notices a mount are all unproven. The watcher's install-then-exit flow, which relies on a supervisor restarting the process, has no test and no supervisor exists in this environment; a stick left permanently inserted reports Unchanged rather than looping, because the hash matches. Env still overrides on a box, so a box is only pendrive-only to the extent its environment is trusted - bootstrap.rs says so.	2026-10-19 07:49:46 +00:00
octoturge	da28597eeb	Report the OctoPrint API as what it is, and let the operator name it ... Reporting a detected printer as `prusa_link` asserted a product nothing on the wire mentions. What a probe observes is that something speaks the OctoPrint REST API; PrusaLink is one implementation of it, OctoPrint itself is another, and without a credential the two are indistinguishable - every PrusaLink identity endpoint requires digest auth. So discovery now reports `vendor = "octoprint"`, the protocol it actually saw, and carries `ambiguous_with` so the rendered entry prints a comment offering `prusa_link` directly above the `vendor` line. Changing it is a one-word edit in the file the operator is already pasting into, which is the right place for a question only they can answer. The exception is a body that names itself: `/api/version`'s `text` field reads "PrusaLink 0.7.0" or "OctoPrint 1.9.3", so on the rare unauthenticated 200 the answer is known and no choice is offered. For that to mean anything, `octoprint` had to become a vendor `fleet.rs` accepts - otherwise discovery printed a block that would not load. It maps to the same client as `prusa_link`, because they speak the same API, with an `OctoPrintFlavour` recording which. The flavour is stored now, while the client is still a stub, precisely because no probe can settle it: it is the operator's answer, and without somewhere to keep it the real client would have to ask them a second time. `PrusaLinkPrinter` is accordingly now `OctoPrintPrinter` - one client for the API family - since a struct called PrusaLink holding a flavour that says "Generic" is a contradiction someone would later have to unpick. **Found by the new test, and the reason it exists:** `fleet::load` did *not* reject an entry whose credential was blank. `require_field` took an `Option`, so `access_code = ""` arrived as `Some("")` and loaded happily - which falsified the claim this feature was built on, that printing a block with an empty credential is safe because pasting it in unfinished fails loudly at startup. It does now. An empty credential is not a usable one; it only moves the failure somewhere worse, where a Bambu printer is refused at MQTT and a PrusaLink one 401s on every poll with nothing saying the field is blank. This is the same trap as `??`-instead-of-`||` on an environment variable that ships empty, which the backend's `auth/edge_secret.ts` and `s3/index.ts` both document; it bites identically on a TOML key. tests/discovery_to_fleet.rs is new and closes the loop: discovery and fleet are coupled by nothing but a string, unit tests on either side cannot catch a drift between them, and the symptom of a drift is an operator pasting in exactly what they were told to and the gateway refusing to start. It renders a candidate for every vendor, fills in the credential the way a human would, loads it for real, and checks the handle matches the vendor asked for - not merely that something loaded, since `octoprint` and `prusa_link` share a client and a mapping that collapsed them would still load and still be wrong. Verification: the Moonraker probe now runs end to end over real HTTP against a stand-in serving Moonraker's documented `/printer/info`, and correctly reports a klipper entry named from the returned hostname. Port 80 cannot be bound without root here, so the PrusaLink path is covered by a test that takes a real socket answering a real digest challenge - the one link unit tests on the classifier cannot reach, and the one PrusaLink is identified by.	2026-10-19 07:40:28 +00:00
octoturge	a401773406	Discover Klipper, PrusaLink and serial printers too ... Discovery found only Bambu printers, so a mixed farm still meant typing most of printers.toml by hand. It now covers the four vendors fleet.rs accepts, over both transports. Detection splits in two, and keeping the halves apart is what makes this honest. "Something at this address speaks X" needs no credential from any vendor, and is most of the value - it yields the address and the vendor, which is two of the three or four fields an entry needs. "What is it called, what firmware does it run" only has an answer where the vendor publishes one unauthenticated: Bambu always, Moonraker usually, PrusaLink never. So an HTTP 401 counts as a find rather than a failure. A password prompt from /api/version is proof that something is serving /api/version, which is the question being asked. It also makes the Moonraker probe correct without having to know how a given host configured [authorization], which is not knowable from outside. Klipper is `GET :7125/printer/info`, Moonraker's own identity endpoint, which returns hostname and software_version. PrusaLink is `GET :80/api/version`; its OpenAPI specification puts digestAuth on every operation including /api/v1/info, so there is no unauthenticated identity endpoint at all and a 401 is the best available answer - which is enough, since the only field still missing is the API key no probe could supply. This cannot distinguish PrusaLink from OctoPrint, and that is not fixable from outside: PrusaLink deliberately implements OctoPrint's API. A wrong guess an operator can see and correct beats skipping a real printer. Two guards against claiming things that are not printers, both now tested against what a real LAN actually answers. Three devices on the test segment answer /api/version with HTTP 200 and a body that is not JSON - a router, a device with a logon page, and one serving gzip - so a 200 must carry OctoPrint's guaranteed `api` field, and Moonraker's must carry the `result` wrapper every Moonraker reply has. And a bare 401 is not enough either: routers, NASes and cameras all password protect port 80, so a 401 must carry a *Digest* challenge, which PrusaLink's spec guarantees and the Basic-auth crowd does not send. A sweep of the real /24 still finds exactly the two Bambu printers and nothing else. Serial detection is passive by default, and that is a safety property rather than a limitation. Opening a serial port toggles DTR, which reboots an Arduino-based board - marlin_serial.rs documents the same thing from the other direction - so a firmware handshake against a machine that happens to be printing ruins the print, and discovery is exactly what someone runs while a farm is busy. So list_ports opens nothing: it reads USB descriptors out of sysfs, which is where udev reads them from, and gets the manufacturer, product and USB serial without touching the device. That is enough to render an entry, since a serial printer's block needs only a path and a baud rate. probe_m115 is the opt-in extra that learns the firmware and the exact machine type, and it refuses to run without --yes-reset-the-printer, the same shape as bambu_print_probe's --yes-start-a-real-print. sysfs rather than tokio-serial's libudev feature: a gateway appliance should not need libudev-dev at build time to list its own ports, and reading the four files udev would read is thirty lines and no dependency. The walk climbs to the USB device holding idVendor rather than counting parents, because a ttyACM link points at an interface and a ttyUSB link at a usb-serial port, each a different depth down. Only Prusa's own USB vendor id counts as evidence of a printer. Everything else in the table is a generic bridge chip - FTDI, CH340, CP210x - that a printer is likely to be behind but that a GPS or an Arduino project could equally be, so those are reported with "could be a printer or any other serial device" rather than asserted. Entries now carry exactly the fields each vendor's loader demands and no others, with a test that fails if to_toml_entry and fleet.rs drift apart, and a rendered entry for a vendor whose client is still a stub says so - otherwise an operator pastes in a Klipper printer and gets a gateway that connects and does nothing. Found while testing the M115 parser: a value ran to end-of-input instead of end-of-line, so the last field on a line swallowed what followed and UUID read as "cede2a2f-...\nok". Unverified, and untestable here: the Klipper and PrusaLink probes (no such hardware) and all serial detection (no serial device attached, and /sys/class/tty holds only virtual consoles). Every parser those depend on is unit tested against recorded protocol text, including the real non-printer responses above.	2026-10-19 07:28:05 +00:00
octoturge	e4344b208b	Find printers on the network instead of retyping their details ... Setting up a farm meant reading five fields off each printer's screen into printers.toml, and the serial is the one that punishes a typo: 15 unspaced alphanumerics that address Bambu's MQTT topics, so a wrong character produces a gateway that connects to the broker, subscribes to a topic no printer publishes, and reports nothing. Two mechanisms, because they fail in different places: SSDP (`listen_ssdp`) hears the announcements Bambu printers send to 239.255.255.250 unsolicited, on 2021 and 1990. It learns the most - the model and the operator's own name for the printer come only from here - but multicast does not cross a router, so it finds nothing from a gateway on a different VLAN than its printers, which is an ordinary way to run a workshop. The TLS certificate (`identify`) is the dependable one. Every Bambu printer puts its serial in the subject CN of the certificate it presents on 8883, readable with no credentials, no MQTT session and across subnets. Verified against both real printers: a P1P gives CN = 01S09B441900143 (issuer BBL CA, TLS 1.2) and an H2C CN = 31B8BP5A1800585 (BBL Device CA O1C2-V2, TLS 1.3), each an exact match for what printers.toml already said. A blind sweep of their /24 found exactly those two and nothing else, in 24s. Reading an unverifiable certificate is deliberate and worth being plain about: it is being read as a name tag, not trusted. There is nothing to verify it against - the serial is what is being learned, and a P1P does not chain to the bundled Bambu CA at all. Trust is still decided by BambuTls::resolve and the trust-on-first-connect pinning, where credentials actually get sent. `to_string` and not the deprecated `as_utf8`, which truncates at an interior NUL; `valid_serial` would reject the untruncated form anyway, which is why the shape is checked rather than the name trusted. `entries_by_nid` on the subject specifically, because an issuer's CN sits earlier in the DER and anything scanning for the first CN reports the certificate authority as the printer. Three decisions that are not incidental: It prints a [[printer]] block and does not write printers.toml. Discovery cannot learn an access code - that code is the only thing between anyone on the network and control of the machine - so every block is incomplete by construction, and fleet::load rejects an empty access_code. Writing a half-finished entry in would stop the gateway starting. `vendor = "bambu"`, never a guessed v1/v2. That value auto-detects on connect, and a firmware update can move a physical printer between dialects, so a guess in a file goes stale silently. There is a tempting correlation in the two printers to hand - the v1 machine negotiated TLS 1.2 and the v2 one TLS 1.3 - but two samples is not evidence. A sweep refuses anything larger than a /24. 256 addresses is every printer anyone has on one segment, and a mistyped /8 would be sixteen million connection attempts across somebody's network. The SSDP path has not received a real announcement: the only host available to test from is routed to the printers rather than on their segment, so their multicast cannot arrive. Hence the parser is tolerant - a header spelled differently costs one field, not the printer - and `raw` mode dumps every datagram, so the first run on a real segment is a test that shows its working rather than only its conclusion. openssl is named directly for the CN read. It is already in the tree - native-tls is openssl on Linux - so this adds nothing to the build, and Apache-2.0 passes `cargo deny check licenses`.	2026-10-19 00:51:09 +00:00
octoturge	042cf430ff	Include the cause chain when go2rtc cannot be reached ... reqwest's Display is only "error sending request for url (...)" - the reason is one or two sources down, and "connection refused" versus "timed out" is the entire content of the message. This error is relayed to the cloud and then to a viewer, so it is the only explanation anyone gets for a camera that will not play. It now reads "could not reach go2rtc at http://127.0.0.1:1984: ...", naming go2rtc explicitly, because by far the likeliest cause is that it is not running and an error mentioning only a port sends whoever reads it looking at the network instead.	2026-10-19 00:37:27 +00:00
octoturge	1a0037af36	Answer relayed WebRTC offers from the gateway's own go2rtc ... Adds src/uplink/webrtc.rs: on a webrtc_offer from the cloud, POST the offer to go2rtc on 127.0.0.1 and send the answer back as webrtc_answer, or the reason as webrtc_error. No credential is involved, because the request goes to loopback and go2rtc exempts loopback from its API password. That is measured, and it is also why a probe from the gateway cannot be used to check the password is working - test from another host for that. Spawned rather than awaited in the select! loop: go2rtc gathers ICE candidates before answering, which includes a STUN round trip, so awaiting inline would stall telemetry and heartbeats for a whole farm while one person opened one camera. It rides the outbound queue added earlier for exactly this kind of out-of-band reply. The bind address is turned into a loopback URL by taking its port and refusing anything it cannot read a port out of - guessing 1984 would produce a gateway that silently signals to the wrong place when someone has moved it. Stream names are validated rather than percent-encoded, since a real one is a printer id and anything else is a bug or an attempt at one. camera.rs now states why there are no ice_servers and no TURN credentials on this side: the viewer's browser is pinned to relay-only, so it allocates the relay and go2rtc just sends to it. Only one side of a session needs one. That asymmetry is load-bearing, not tidy - go2rtc reads its config once at startup, so rotating short-lived credentials here would mean restarting it and dropping every viewer on a timer.	2026-10-19 00:32:57 +00:00
octoturge	d13284b585	Keep a test's doc comment attached to its test ... Adding the test_auth helper put it between `/// The URL shape confirmed from a real H2C's ipcam block.` and the test that comment describes, so the comment documented the helper instead. Clippy's empty_line_after_doc_comments caught it. Also takes clippy's from_ref over a clone in the new render-stability test.	2026-10-18 22:01:21 +00:00
octoturge	70763108f8	Require a password on go2rtc's API ... The API listener is what serves WebRTC, and it defaults to :1984 on every interface, so anyone who could reach the gateway could watch any printer with a camera. The RTSP server was closed on 2026-10-18; this was the other half and the one that actually carries video. Measured against go2rtc 1.9.14, feeding it this module's own rendered config: from a non-loopback address /api/webrtc, /api/ws, /api/streams and the web UI all answer 401 without credentials and 200 with them, while :8554 stays closed. go2rtc exempts loopback, which is worth knowing twice - it is why a probe from the gateway still works without credentials, and why such a probe cannot be used to confirm auth is on. The password is generated once per run from /dev/urandom, or taken from CONTINUUM_GO2RTC_PASSWORD. Once per run matters: the config is re-rendered every 30s and compared byte-for-byte to decide whether to restart go2rtc, so a per-render credential would restart it and drop every viewer every half minute, with no symptom but dying video. A test pins that. It is never logged - it goes into the config file, which already holds every printer's access code and is already documented as a secret, so there is one place to protect rather than two. An operator-supplied password is escaped for YAML, because a config go2rtc cannot parse means a camera that silently never appears. No opt-out flag. The alternative is an unauthenticated video feed of someone's workshop, which is not a thing to leave behind a setting, and nothing in this crate calls go2rtc's API so nothing internal breaks. Note this does NOT let a browser play a stream directly - see the next commit's notes and PLAN.md. go2rtc sends no CORS headers and 401s the unauthenticated preflight, so the relay is required, not optional.	2026-10-18 22:00:51 +00:00
octoturge	7a0201c0de	Test that a late command failure reaches the cloud ... The outbound queue had no coverage, and it is exactly the kind of code that looks right and does nothing: the failure path only runs minutes after the command was answered, so nothing in the ordinary flow would notice it was missing. Stands up a real websocket server and runs the real `uplink::run` against it, asserting two results for one command_id in order - ok:true on acceptance, then ok:false carrying a reason that names what went wrong. That the id repeats is the contract, not a bug to deduplicate. It touches no printer and makes no outbound request: the fleet is empty and `dispatch` checks the fleet before downloading, so the command fails on a lookup. The unreachable URL is on port 1 so a regression that did reach the network fails fast rather than hanging on a real host. Verified to fail without the feature, not just to pass with it: stubbing out the send makes it time out waiting for the second result. That check is worth doing by hand here - the go2rtc RTSP test asserted the absence of a config key and passed the whole time the server was open.	2026-10-18 21:52:05 +00:00
octoturge	f88103a510	Back the uplink reconnect off from 5s to 60s ... A gateway cannot tell a cloud that is briefly restarting from a token the cloud will never accept: with the edge token on the upgrade request, both are just a failed handshake here. So a flat 5s retry meant a permanently misconfigured gateway knocking twelve times a minute, forever - pointless, and the shape of the thing the other end would eventually have to rate-limit. Doubles to a 60s ceiling, which is still short enough that an outage resolves without anyone touching the gateway. That matters when the gateway is in someone else's workshop. The reset is on a completed handshake, which is why `connect` is split out of what is now `serve`: a handshake is the only unambiguous evidence that the cloud is reachable and this gateway is accepted. Resetting after the connection ended instead could not tell a connection that lived an hour from one that never opened. Re-verified live against the backend and both printers with continuum-backend's scripts/e2e-edge.sh.	2026-10-18 20:03:49 +00:00
octoturge	930d117c4e	Report a long-running command's failure to the cloud, not just the log ... A `start_print` is acknowledged the moment it is accepted: the transfer takes minutes at the measured 0.2 MiB/s and the backend gives up after ten seconds, so the real outcome can only ever arrive late. Until now there was nowhere for it to arrive - the uplink's `select!` loop was the only writer, and a task outside it could not reach the socket. A failed job start therefore reported success, and the reason lived only in this gateway's log, on a machine in someone else's workshop. Adds a bounded mpsc queue, created outside the reconnect loop so a message produced while the socket is down waits for the next connection rather than being dropped. A late failure goes back as a second `CommandResult` for the same command_id, carrying the reason. Be clear what that buys: the backend is no longer awaiting that command, so the result does not change the job's fate - the job never reaching `printing` is what fails it, and that already worked. What it adds is the reason, next to the farm and gateway that produced it. Attaching it to the job row needs a column `print_jobs` does not have. Nothing is sent on success; the telemetry that follows says it better. Also documents, in the module doc, why telemetry is not buffered across an uplink gap - it is a decision now rather than a gap. See PLAN.md.	2026-10-18 20:00:00 +00:00
octoturge	51ff768153	Close go2rtc's RTSP server, which was open all along ... Found by installing go2rtc and running the real daemon against the live H2C, which is also how the comment this replaces turned out to be wrong. `camera.rs` said: "No `rtsp:` or `webrtc:` block: ... Opening go2rtc's own RTSP server would publish every printer's camera on the LAN unauthenticated, which is not something to do by default." The reasoning was right and the conclusion was backwards. **Omitting the key does not leave the server off - go2rtc defaults to :8554.** Measured against go2rtc 1.9.14 with exactly the config this module generated: `rtsp://<gateway>:8554/h2c` answered a DESCRIBE with a real video SDP, with no credentials sent at all. Every printer with a camera was being republished to anything that could reach the port. The unit test asserted that the rendered config contained no `rtsp:` key, and from that concluded no server was opened. It passed throughout. A test that asserts a key is absent cannot tell "off" from "defaulted on" - it now asserts the value that actually turns it off, and that an empty fleet closes it too, since a gateway with no cameras is the config most likely to be left running. `webrtc:` is left at its default on purpose: it is not a second stream server, because a session only exists after an SDP offer through the API, and the browser needs those candidates. The API listener itself is unauthenticated and stays that way for now - the browser reaches it directly, there is no relay, and the frontend is handed only a URL and a stream name - so anyone on the gateway's LAN can watch. That is a real limit, now written down here and in PLAN.md rather than implied. Two smaller things from the same session: - The logged stream count was `matches("\n ").count() - 1`, which reported one stream for a config with none: the `{}` of an empty mapping indents exactly like a stream does. It made the log say a camera was being served when none was, and it hid that the two writes on startup are genuinely different configs (empty, then the fleet once it reports) rather than a pointless rewrite. Counted from the sources now, collected once so the number describes the config actually written. - Recorded what is now confirmed: go2rtc connects to `rtsps://bblp:<access_code>@<ip>:322/streaming/live/1` and pulls video - 984,604 bytes over `rtsp+tcp`, no certificate complaint, no auth failure. The printer runs LIVE555 and sends H.264 High profile level 4.1, which a browser plays natively over WebRTC, so no transcoding and no ffmpeg on the gateway. The `rtspx://` prefix go2rtc documents for skipping TLS verification is not needed. Verified after the fix with the real daemon: the generated config now leaves :8554 closed while :1984 and the WebRTC port stay up. 65 tests, clippy unchanged, licenses ok.	2026-10-18 13:43:19 +00:00
octoturge	ad150cd29e	Send the edge token on the upgrade, not in the hello ... The uplink put its edge JWT in a `token` field on the `hello` message. It now goes in an `Authorization: Bearer` header on the WebSocket upgrade request, which the backend verifies before the socket exists - so a bad token is an HTTP 401 here rather than a connection that opens and is then closed, and the credential stays out of the URL, where it would land in every access and proxy log on the way. `Authorization` is the header those tools already know to redact. `farm_id` stays on the hello even though the token carries the same claim: the backend checks the two against each other rather than trusting the message, so sending it is how a configuration mismatch gets caught instead of silently working against the wrong farm. The cost is that tokio-tungstenite no longer derives the handshake from a URL for us - a request we build ourselves needs its own `Host`, `Connection`, `Upgrade`, `Sec-WebSocket-Version` and `Sec-WebSocket-Key`, and a handshake missing any of them is rejected rather than ignored. `host_header` errors rather than guessing if the URL has no authority, because a wrong `Host` fails the handshake far less legibly than this does. Verified against a real backend rather than assumed: a valid token handshakes to HTTP 101 and the server reads the farm from the token, and a forged one is refused with 401 before any socket exists. 64 tests, clippy unchanged at the two deliberate variant-size warnings, `cargo deny check licenses` ok.	2026-10-17 14:00:05 +00:00
octoturge	3b93a1b4e1	Confirm at the network layer that a P1P has no RTSP endpoint ... `camera.rs` said a P1/A1 camera is reachable only over Bambu's port-6000 JPEG stream, inferred from the absence of `rtsp_url` in what the printer reports. Checked directly today: the H2C accepts TCP on 322 and the P1P *refuses* 322 while listening on 6000. So the inference was right and is now a fact. Worth writing down, because it closes off the tempting shortcut - there is no URL to guess for a P1P, the endpoint does not exist.	2026-10-15 23:10:57 +00:00
octoturge	6a0d80a381	Generate go2rtc's config from what the printers report ... go2rtc has been supervised since before this commit, with nothing to serve: `CONTINUUM_GO2RTC_CONFIG` pointed at `./go2rtc.yaml`, and that file did not exist in the repository or anywhere else. A watchdog was restarting a process that had no cameras configured. `camera.rs` writes it, from the `rtsp_url` a printer publishes in its own `print.push_status` `ipcam` block rather than from `printers.toml`. The URL is already something the machine tells us, so asking an operator to keep a second copy of it - and to update it by hand when a printer's address changes - would be asking for drift. Two tasks, not one: the builder decides what should be served, the watchdog keeps the thing serving it alive. They meet at one `Notify`, because go2rtc reads its configuration only at startup, so a changed config needs a restart. The watchdog now selects the child's exit against that notification and skips its backoff on a deliberate change. What this does *not* cover is most printers, and that is the honest limit. Only the X1/H2 class publishes an RTSP URL - confirmed against two real machines: the H2C reports `rtsps://192.168.0.21:322/streaming/live/1`, the P1P reports an `ipcam` block with `ipcam_dev: "1"` and no URL at all. "A camera exists" and "a camera you can connect to" are different facts. A P1/A1 needs Bambu's proprietary port-6000 JPEG stream, which this crate does not speak, so those printers report no `camera_stream` and a UI should offer a player only when one is present. Details worth keeping: - The config is rendered sorted so an unchanged fleet is byte-identical, and on the first pass it is compared against the file on disk - without that, every daemon restart rewrites an identical file and drops every live viewer. - Written through a `.tmp` and renamed. The watchdog can restart go2rtc at any moment, and a half-written config fails to parse, which takes every working stream down rather than one. - Never logged, and gitignored: the credentials go in the URL because that is the only place go2rtc takes them for an RTSP source, so the file holds printer access codes. - A reported URL with no scheme is refused rather than repaired. One bad entry makes go2rtc fail to load the whole file. - No `rtsp:` or `webrtc:` block. The API listener is what serves WebRTC to a browser, which is the only consumer here; opening go2rtc's own RTSP server would publish every printer's camera on the LAN unauthenticated. - `stream_base_url` is reported in `hello`, not derived from the listen address: `:1984` is a bind address and not something a browser can open. Unset means "advertise nothing", which is the right default, because a wrong URL makes the UI offer a player that cannot connect. It is a LAN address either way - there is no relay, so this works for an operator in the workshop and not for anyone outside it. 63 tests, clippy unchanged at the two deliberate variant-size warnings, `cargo deny check licenses` ok. go2rtc itself stays operator-installed and is not distributed.	2026-10-15 23:03:02 +00:00
octoturge	901d5e9748	Execute start_print, and never await it on the uplink task ... The gateway can now run a cloud-dispatched print: download the job file from the presigned URL in the command, then hand it to the existing `upload_project_file`, which derives the filament mapping from the archive, transfers it over FTPS and starts it. ## The download refuses to be a weapon `src/uplink/download.rs` checks the HTTP status before reading a byte, because an expired presigned URL answers 403 with an XML error document and writing *that* to a printer as a project is the worst outcome available. It rejects a `Content-Length` over 256 MiB before reading, and enforces the cap while streaming as well, so a server that lies or omits the length cannot make a small gateway box buffer until the OOM killer arrives. A byte count that disagrees with `Content-Length` is an error: a `.3mf` is a zip, and a truncated one loses the central directory the printer needs. HTTPS only, no redirects, and the URL is stripped from error messages. `PrinterCommand` no longer derives `Debug` for the same reason - `dispatch` logs every command, and a presigned URL is a bearer credential until it expires. It prints as `<redacted>`. ## Why it is spawned `start_print` is the one command that cannot be answered inline, and the reason is not latency. Everything else here is an MQTT publish returning in milliseconds. This downloads tens of megabytes and then transfers them at a measured 0.2 MiB/s - about four minutes for a 50 MB project - and awaiting that inside the uplink's `select!` loop stops heartbeats and, far worse, stops telemetry for the duration. No telemetry is what makes spawning mandatory rather than tidy. The cloud now derives a job's state from the telemetry that follows a start, so a gateway that goes silent for four minutes during every job start withholds exactly the information the job depends on - while the backend times the command out after ten seconds and concludes the start failed. The job would be requeued onto a printer that was busy printing it. So the `ok` means "accepted, working on it", which is all a start reply was ever trusted to mean. `runs_for_minutes` is an exhaustive match rather than a `matches!`, so a new variant has to make that choice instead of defaulting to the stall. The gap this leaves is honest and recorded in the code: a failure after the ack has no `CommandResult` to travel on, because answering later needs an outbound channel this loop does not have. Until it does, the gateway's log is where the reason lives and the backend reaps the job. reqwest 0.12 with `rustls-tls-native-roots`, not 0.13: 0.13 pulls `webpki-root-certs` under CDLA-Permissive-2.0, which is not on the allow list, and `aws-lc` brings OpenSSL-licensed C. `cargo deny check licenses` passes. 54 tests.	2026-10-15 22:53:47 +00:00
octoturge	76b3894ca9	Say when a filament source is being ignored, and what a real failure looked like ... Two things a real end-to-end run on the P1P taught, neither of them a fix. `start_uploaded_file` silently discarded its `filament` argument for a bare `.gcode`. That is protocol-correct - the v1 `gcode_file` request has only `command` and `param`, with no `use_ams`/`ams_mapping` to put it in, so a bare gcode draws whatever its own tool changes select. But the argument is required, and a caller passing `FilamentSource::ams([3, ..])` would reasonably believe it took effect. "A filament choice quietly overridden" is the precise bug `FilamentSource` was introduced to stop, so this now warns instead of dropping it. The other is the whole-path confirmation, which is worth having written down because it ended in a *physical* failure rather than a clean success. The derivation read the project's one PETG/GFG99 filament and produced slot 3; the printer echoed `tray_tar: 3`, so it agreed; 297,227 bytes went up with an exact byte count; `IDLE -> PREPARE -> RUNNING`; it heated to 255C - and then paused itself at stage 54 with `print_error: 0x07008003` and `hms: [{attr: 0x07002300, code: 0x00020004}]`, a broken-filament fault on the slot it was loading. Every line of this code did the right thing and the print still did not happen. That is the argument for the thing this commit documents rather than changes: `command_outcome` can only report what the printer said about the command, and "accepted" has now been shown to be three distinct steps away from "printing". Anything that reports job status has to watch `gcode_state`, `print_error` and `hms` after the fact - a job dispatcher that trusts the start reply will report a successful print that never ran. Also noted: `tray_now` is not a usable confirmation on its own. It went 255 -> 3 -> 254 over the run, so only the transition through the real slot number is evidence; a single read can land on either sentinel.	2026-10-15 22:37:28 +00:00
octoturge	df6dfca3ca	Refuse a truncated project, and drive the whole path from the probe ... `upload_project_file` already existed - as a `GenericPrinter` trait method, which is why a grep for `pub async fn` missed it and this commit nearly reimplemented it. It logged `written` and `byte_count` next to each other and never compared them, so a short write was something you could only notice by reading the logs afterwards, and the next line printed the truncated file anyway. A `.3mf` is a zip: cut the end off and the central directory goes with it, so the printer gets an archive it cannot open. That is also the failure a slow transfer invites, and this transfer is slow - 4.96 MB took 31.3s, so a 62 MB project is minutes of exposure. `print-project <local> [name]` runs that method against a real printer, so the harness tests the production entry point rather than the three pieces in sequence. It deliberately takes no `--ams`: the whole point is that the mapping comes out of the archive. Gated like `start`, on a terminal state and `--yes-start-a-real-print`. Confirmed end to end on the P1P (2026-10-15, with the owner's go-ahead), with the same project the 2026-10-11 run used: the derivation read one PETG/GFG99/ `#2850E0` filament out of `Metadata/slice_info.config` and produced `mapping=[3]`, padded to five trays; 297,227 bytes went up with an exact byte count; `IDLE -> PREPARE -> RUNNING`. The AMS on that machine has slot 2 in black and slot 3 in blue, same product and same `tray_info_idx`, so picking slot 3 is the colour tie-break doing real work rather than a one-candidate match.	2026-10-15 22:32: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	13bfec97fe	Clear the clippy warnings, except the two that are not cosmetic ... Down from 29 warnings to 2, in the spirit of 4ab95ff. The doc warnings were all one mistake made repeatedly: a paragraph wrapped so that a line *began* with `- ` or `+ `, which rustdoc reads as a markdown list marker and the following lines as unindented continuations. The prose always meant an em-dash. Fixed by moving the dash to the end of the previous line and re-wrapping; not one word changed, which is the point - these comments record things confirmed against real printers and are worth more than the warning. The genuine lists just had their continuations de-indented and stayed lists. The code ones are `match x { V(v) => .., _ => {} }` to `if let`, and nested `if let Some(x) = .. { if cond { .. } }` to a let-chain. None had an `else`, so each is the same control flow written once instead of twice. Two warnings are left deliberately, because fixing them is not cosmetic: `AmsTray` (544 bytes against 32) and `BambuReport` (984 against 120) both have one variant far larger than the rest. The fix clippy wants is a `Box`, which changes how every reader of those enums is written and puts an allocation on the push_status path that currently has none. Worth measuring before doing, not worth doing to silence a warning. 51 tests still pass.	2026-10-15 21:43:06 +00:00
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	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
octoturge	431dd849da	Make the filament source explicit, and print from the AMS ... `start_uploaded_file` hardcoded `use_ams: false` / `ams_mapping: ""`, which silently overrode whatever the slicer had chosen. On a P1P with an AMS and a project sliced for it, that is not a missing feature - it points the print at the external spool. Confirmed on 2026-10-11: the print started, heated to 250C, reached 1%, then the printer paused itself with `print_error: 50364420` and `tray_now: 255`. Nothing in the command's reply said so; `result` was `success`, because the command had been accepted. So `FilamentSource` is now a required argument with no default, because there is no safe default - picking wrong draws the wrong filament or none. The `ExternalSpool` variant sends the empty *string* the schema's trailing `oneOf` demands, and `ams` takes slots per project filament index and pads to every tray the printer has, per the padding rule in `schemas/bambulab/v1/common/ams/ams_mapping.schema.json`. It refuses an empty mapping (padding `[]` would mean `use_ams: true` with nothing mapped), one longer than the printer has trays, and any negative that is not -1. Confirmed live with the real mapping: `ams_mapping: [3,-1,-1,-1,-1]`, `use_ams: true` took the printer to RUNNING, `tray_now` became 3 - the slot the project was sliced for - and it ran past 1% to 13% with `print_error: 0`, where the external-spool attempt had paused. Finding the mapping needed reading the project back off the card, so FTPS gains `download`/`download_file` and the probe a `fetch` step. The archive's `Metadata/slice_info.config` lists each plate's filaments with `tray_info_idx` and colour - here one PETG GFG99 at `#2850E0`, matching AMS slot 3's `2850E0FF` - and `Metadata/plate_1.gcode` is present, which also confirms the hardcoded `param`. `upload_project_file` is left on the external spool and is the one remaining place that can pick wrong, because it is vendor-generic and an AMS mapping is a Bambu concept. It is unreachable - there is no start-print command on the uplink - and the fix is for it to derive the mapping from the `.3mf` it already holds, which needs a zip reader and so a dependency decision.	2026-10-11 22:35:51 +00:00
octoturge	0077e15490	Record what a real sliced project did, and widen the start guard ... A second live run, this time against a project the owner sliced in Bambu Studio rather than a file already on the card, and through `start_uploaded_file` itself rather than a hand-built body - so the root-vs-cache fix is confirmed end to end. `gcode_file` in the printer's own status came back as `cube-test-2026-10-11.gcode.3mf`, 150 layers, print_type `local`. It also found a defect the first run could not. The print heated to 250C, reached 1%, and then the printer paused itself: `print_error: 50364420` (`0x03008004`), `hms: []`, `tray_now: 255`. 255 is the external spool, which is exactly what the hardcoded `use_ams: false` selects - so that pair overrode the slicer's own filament choice and pointed an AMS-sliced project at an external spool. The first run looked fine only because it was stopped during PREPARE, before filament mattered. The doc comment said that pair was "accepted, and the print ran"; it now says what it actually does, because silently changing which filament a print uses is worse than not supporting AMS at all. The `start` guard demanded IDLE, which meant the harness refused every print following a cancelled one - a Bambu reports an operator cancellation as FAILED. IDLE, FINISH and FAILED are all terminal; PREPARE, RUNNING, PAUSE and SLICING mean the machine is committed, and anything unrecognised is still refused rather than assumed idle. `bambu_cache_list` now prints nozzle/bed temperatures and remaining time. State plus layer number cannot tell a print that is working from one that is stalled: a P1P sits at layer 0 for minutes during bed levelling and purge, and the only thing moving in that window is the heat.	2026-10-11 17:55:01 +00:00
octoturge	939c35fb91	Confirm the print path on a real P1P, and stop discarding its answer ... Print control (pause/resume/stop) and print start are now both confirmed against the P1P on the LAN, and doing that turned up three real defects. `start_uploaded_file` published fire-and-forget, so the printer's reply was thrown away. Asking it to print a file it does not have returned `Ok(())`, and watching `print.push_status` could not tell that apart from a successful start, since both leave the machine IDLE for a while. The printer does in fact answer - `{"command":"gcode_file","param":"...","reason":"error string","result":"fail"}` - and it echoes the `sequence_id` we send, so `request` correlates it. Both this and `control_print` now go out as correlated requests and run the reply through `print_command_outcome`. The upload and the print command disagreed about where files live. `upload` cwd'd into `cache/` while the printable projects are in the card's root: the root holds 43 `<name>.gcode.3mf` archives, `cache/` holds the printer's own extracted `<project>_plate_N.gcode` working copies with `.gcode.bbl` sidecars. Those extracted copies are not independently printable - `gcode_file` with `param: "/cache/Cube_plate_1.gcode"` was rejected for a file the FTPS listing shows is right there - while `project_file` with `url: "ftp:///Cube.gcode.3mf"` started a print. So the destination is now a parameter and both halves point at `SD_ROOT`. What the hardware settled, recorded in the doc comments: the `ftp:///` url spelling is right, `param: "Metadata/plate_1.gcode"` works for a single-plate project, `use_ams: false` + `ams_mapping: ""` is accepted, and a stop during PREPARE/RUNNING moves the printer to FAILED, which is how Bambu reports an operator cancellation. What it did not settle: all three control verbs answer `result: "success"` on an *idle* printer, so the reply means "accepted", not "the state changed" - callers still have to read `gcode_state` back. `PrinterCommand::ControlPrint` makes this reachable from the cloud at all; until now pause/resume/stop existed in the proxy with no way to send them. Still no start-print variant, now for a different reason: the path around it is missing, not the hardware proof. Also: `list_dir` for any directory (how the layout above was found, without sending a print command to guess), `request_raw` for probing an unconfirmed command shape, and two examples - `bambu_cache_list` (read-only) and `bambu_print_probe` (gated steps, `start` needing both IDLE and --yes-start-a-real-print).	2026-10-11 17:38:27 +00:00
octoturge	588ca85842	Compile the modules once, and clear the warning backlog ... `cargo check --all-targets` emitted 32 warnings; it now emits none. Almost all of them came from one cause: main.rs declared `mod config/fleet/printer/uplink` while lib.rs declared the same modules, so every file was compiled twice, once per crate. In the binary copy nothing is externally reachable, so every `pub use` re-export and every method that only an example or a test calls was genuinely dead - and the warnings were real about the binary while being wrong about the library's actual public API. main.rs now uses the library crate and keeps only `mod go2rtc`, which nothing else needs. The rest, individually: - `ModuleInfo` was re-exported from bambu_commands but not from printer, so it was unreachable even though `GetVersionResponse.module` is a public field of type `Vec<ModuleInfo>` - a caller could not name the type of a field it can read. Re-exported rather than dropped. - Three stub `publish` impls take a payload they do not use yet; renamed to `_payload`. - One unused import in examples/test_bambu_certs.rs. That leaves the `async_fn_in_trait` lint on GenericPrinter, which is now `allow`ed with the reasoning written down rather than left to fire on every build. The old comment said it "only matters once this is wired into the multi-threaded daemon", which has since happened - so the question got answered instead of deferred: the futures cannot be required to be `Send`, and that is fine because every printer is reached through one Arc<Mutex<Vec<..>>> from the uplink's own task, so they are created and polled in the same place. The note says what to do if a printer ever gets its own task. No behaviour change. Tests still pass and the daemon was re-verified against the live P1P and H2C through the full backend path.	2026-10-03 12:16:48 +00:00
octoturge	ca3846b7c7	Make the uplink match the written protocol, and test that it does ... Adds tests/uplink_protocol.rs, the gateway half of a contract test whose other half is continuum-backend/tests/edge_protocol.test.ts. It checks that every message the backend sends is one this gateway can read, and that what this gateway writes is what the schema says it writes. It found two things immediately. Telemetry was serializing empty fields as explicit nulls. serde emits `"job_name": null` for an empty Option unless told otherwise, and the backend's validator treats a missing key and an explicit null as different things - so every batch containing an idle printer, which by definition has no job name, would have been rejected whole. Every optional field now has skip_serializing_if, confirmed against a live capture: an idle P1P's snapshot has no nulls in it at all. ServerMessage had no variant for the handshake being rejected. A bad or expired token would have arrived as "unparseable message from cloud, ignoring" and then been retried every five seconds forever, which in the logs is indistinguishable from a network fault. HelloError is now a real variant, logged at error level naming the env var to go fix, and it stops the connection attempt instead of looping on it. Also exposes config and uplink from lib.rs so the test can reach them, same reason fleet and printer are already there. Verified live against a P1P and an H2C for the whole run, including the H2C finishing its print: RUNNING 98% -> FINISH 100% layer 50/50 with the nozzle cooling 84C -> 76C, all of it arriving through the uplink, no warnings.	2026-10-03 10:37:24 +00:00
octoturge	91fbcaf665	Route telemetry up and commands down over the cloud uplink ... The proxy did not actually proxy. `fleet` was loaded and connected in main.rs and then never touched again, while the uplink said hello and sent heartbeats into the void - two halves of the program running side by side with nothing between them. Both directions are wired now. Up: every 5s, one vendor-neutral `PrinterTelemetry` snapshot per printer that has reported, batched into a single `Telemetry` message. The snapshot is a translation rather than a forwarded `print.push_status`, because it has to describe a Prusa too, and because Bambu's wire format has traps (0-15 fan gears, ints-or-floats temperatures) that should not reach the rest of the system. Down: a `Command` is looked up by our own printer id, executed, and answered with a `CommandResult`. `PrinterCommand` is deliberately small and deliberately has no "start a print" variant - `start_uploaded_file` has never been run against hardware, and the first thing to exercise it should be a human watching the machine, not a message from the internet. The fleet becomes `Arc<Mutex<Vec<PrinterHandle>>>` so main and the uplink can share it. One lock for the whole Vec is coarse - a slow command to one printer stalls telemetry for all of them - which is fine at a handful of printers and is the shape to revisit (a lock per printer, or an actor task each) before a farm gets large. Two things found by running this against the live P1P and H2C: - A v1 Bambu reached the cloud as a row of nulls with one real bed temperature in it, while the v2 H2C beside it was fully populated. v1 only sends a *complete* status when asked, and `pushall`'s own doc comment said to call it periodically - nothing ever did. Each telemetry tick now collects, then requests the next refresh, so v1 telemetry runs one tick behind instead of staying stuck on fragments. The quirk lives in `PrinterHandle::refresh_status` so the uplink does not have to know it. - The third instance of the silent-swallow parse bug, at the old uplink/mod.rs:63: `if let Ok(server_msg) = serde_json::from_str(..)` with no else. Same shape that hid broken `print.push_status` parsing for weeks, except here it would mean commands vanishing with the cloud never being told. Now a `match` with a loud `Err` arm. Verified end to end against both printers with a throwaway WebSocket server: H2C `RUNNING 88% layer 48/50 13min nozzle 230/230 bed 35/35`, P1P `IDLE 0% nozzle 23.5/0 bed 22.5/0`, both fan commands `ok=true`, zero warnings over 24s.	2026-10-03 10:22:22 +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
octoturge	0ab602ed79	Add real FTPS upload to Bambu printers ... `upload_project_file` was a `println!`. MQTT can start a print but can only name a file the printer already has, so moving the bytes there is a separate protocol: implicit FTPS on port 990, user `bblp`, password the same access code MQTT uses, into the printer's own `cache/` directory. Confirmed live against a P1P: 102 bytes uploaded, byte count matched exactly, first attempt. Deliberately suppaftp's *blocking* client on `tokio::task::spawn_blocking` rather than its async one. The blocking client takes a plain `native_tls::TlsConnector`, so this reuses `BambuTls::build_connector()` unchanged and every TLS trust decision for a printer stays in that one method; the async client needs a second TLS stack (`async-native-tls`) whose futures-vs-tokio `AsyncRead` mismatch has already cost this project a debugging session. `connect()`'s doc comment already pointed at `spawn_blocking` as the eventual answer for blocking work, and a multi-megabyte upload earns it more obviously than a handshake does. `connect_secure_implicit` sits behind suppaftp's `deprecated` feature because implicit FTPS is what the RFCs deprecated in favour of explicit AUTH TLS. The printers only speak implicit, so the feature is on. Split into `upload_file` (FTPS only) and `start_uploaded_file` (the MQTT command that begins printing), because the two halves have very different consequences: moving a file onto a printer is inert and reversible, while starting a print commits the machine to hours of physical work. That split is what made the transfer testable against real hardware at all. `start_uploaded_file` dispatches on file type - a `.3mf` is a container so `print.project_file` needs both a `url` and a `param` naming the gcode inside it, while a bare `.gcode` has nothing to select and `print.gcode_file` takes just a path. It has deliberately never been fired; its doc comment lists the three guesses to confirm first. suppaftp is MIT OR Apache-2.0, checked against docs/LICENSES.md before being added, along with all 22 crates it pulled in.	2026-10-03 10:11:36 +00:00
octoturge	f3f6e21012	Declare proprietary licensing and enforce permissive-only dependencies ... Continuum is intended to be sold, so every dependency has to permit distribution in closed-source commercial software. This crate carried `license = "UNLICENSED"`, which is not valid SPDX and made `cargo deny` fail outright; `LicenseRef-Proprietary` with `publish = false` is what marks it first-party instead. The note in deny.toml is the part that earns its keep: `src/go2rtc.rs` spawns go2rtc from PATH and expects the operator to have installed it, so we currently distribute nothing. go2rtc shells out to ffmpeg, and ffmpeg is LGPL-2.1+ only when built without `--enable-gpl` - most prebuilt binaries are GPL builds because they bundle x264. If we ever ship either binary, those build flags become our problem. Policy and full audit: continuum-common's docs/LICENSES.md.	2026-10-03 10:11:05 +00:00
octoturge	305c41993d	Update docs and prune examples superseded by real functionality ... README/certs/README/.env.example/printers.example.toml were all still describing this as a learning-stage stub with no real printer protocol clients - rewritten to reflect the real Bambu MQTT client, cert auto-pinning, and marlin serial connection that now exist. - Remove examples/fetch_bambu_cert.rs: its manual fetch-and-save workflow is now what BambuPrinter::connect()'s ensure_trusted does automatically on every connect, so it has no remaining use case. - Fix examples/printer_polymorphism.rs, which no longer compiled - dispatch_gcode was replaced by real methods earlier this session; swapped in print_status() as the vendor-only-extension example. - Remove Config::bambu_ca_cert_overrides/bambu_require_valid_cert and the .env vars documenting them - confirmed dead (nothing read them), fully superseded by printers.toml's per-printer ca_cert_path/ require_valid_cert plus automatic trust-on-first-connect pinning. - Fix stale doc comments in printer/mod.rs and printer/bambu.rs that described certificate trust and MQTT as not built yet, or referencing the now-removed example. No behavior change in the daemon itself - verified with cargo build --examples and a live run of printer_polymorphism and auto_connect_bambu against the real P1P/H2C printers.	2026-09-07 16:17:15 +00:00
octoturge	23f157d07a	Prefix generated sequence_id instead of offsetting it ... A printer's own free-running counter for unsolicited messages is always a plain numeric string, so a non-numeric prefix ("cxproxy-") rules out collision with it outright, rather than a large numeric starting offset merely making collision improbable. Confirmed sequence_id need not be numeric (live test, ISO-timestamp-prefixed value round-tripped fine) and re-verified the new prefixed IDs round-trip through get_version on both P1P (v1) and H2C (v2).	2026-09-07 15:03:14 +00:00
octoturge	256463e29c	Add get_calibration; fix a real 10KB packet-size ceiling; revert bad correlation-field experiment ... Real bug found and fixed live: both rumqttc clients default to a 10KB max packet size in both directions. A real H2C's get_version reply (25625 bytes - it reports a lot of modules: dual AMS, AMS HT, six WTM units, ...) blew straight through that on the v5 client and killed the whole connection outright (a real MQTT protocol error, not a timeout). Raised to 1MB on both clients - print.push_status reports can get large too. Also tried, and reverted after live-testing disproved it: replacing request()'s sequence_id correlation with a homemade continuum_correlation_id field, on the understanding that most replies echo back arbitrary extra request fields. True in general, false for get_version specifically - a real H2C's reply had exactly ["command", "module", "sequence_id"], nothing extra survived, so every get_version call started timing out. Reverted to sequence_id, which is what's actually proven (twice now, on both protocol versions) to round-trip for this command. Added BambuPrinter::get_calibration(option) - print.calibration gets a real, correlated reply (confirmed live: it does echo sequence_id) on both protocol versions, per the schema fixes in continuum-schemas. `option` is the request's own bitmask, left to the caller rather than defaulled to "run everything" - this triggers a real physical calibration sequence on the printer, not a read-only query like get_version, so it hasn't been live-tested here without explicit confirmation first.	2026-09-07 14:55:09 +00:00
octoturge	6ce60542c6	Add pushall + print_status cache; fix envelope, race, and matching bugs ... PrintReport now flattens CommandEnvelope (sequence_id/command) - push_status.schema.json composes the shared envelope like every other Bambu message; the struct's old doc comment concluded otherwise from a capture that turned out to be an incomplete example (also missing dozens of other real fields), not proof the message lacks them. Added BambuMqttSession's PrintStatusCache: the in-memory print.push_status object, replaced wholesale on v2 (always full) or on a v1 message with msg != 1 (forced/full), merged field-by-field otherwise (v1's organic partial updates) via PrintReport::merge_from. Tracks last_sequence_id to warn on a gap in the organic stream. BambuPrinter gets pushall() (v1-only; pushing.pushall doesn't exist in v2's schema at all) and print_status(). Three real bugs found and fixed via live testing against an actual P1P, none of them guessable from the schema alone: - pushall's reply doesn't echo the sequence_id we send - the printer stamps its own free-running counter regardless of what triggered it. request()'s ID correlation silently can't work here; first fix attempt added request_next_of_category (wait for the next message under a category, no ID needed). - That undershot too: matching by category alone let an unrelated "print" message (that category carries many commands - gcode_line, pause, push_status, ...) satisfy the wait before the real push_status reply arrived, so pushall() returned Ok having consumed the wrong message - now keyed by (category, command). - A real ordering race: handle_incoming_report woke a waiting oneshot before updating the print_status cache, so a caller could resume and check print_status() before the write landed - pushall() returned Ok immediately followed by print_status() still showing None. Fixed by applying the cache update before sending on any matched oneshot. Superseded by real protocol knowledge before any of the above needed to ship, though: push_status carries its own msg field (1 = automatic/ partial, 0 = forced/full) - the actual, reliable, self-describing signal for which kind a message is, regardless of timing or which client (if any) triggered it. PrintStatusCache now reads that directly instead of inferring it from request correlation, and pushall() is plain fire-and- forget (publish, no wait) since there's nothing left to correlate for - confirmed live: msg reads correctly off a real P1P, and the cache populates/updates correctly with no gap warnings across several organic pushes. request_next_of_category is kept (a future case may still need "no correlation ID at all" for real), just no longer used here. Also: the poll loop now logs when it exits instead of returning silently - that silence is exactly what made a real dropped MQTT connection to a live H2C indistinguishable from "nothing happening" during testing.	2026-09-07 14:39:55 +00:00
octoturge	835a4ae778	Auto-pin certificates on connect; fix Custom TLS mode for real MQTT ... connect() now calls ensure_trusted() before opening the MQTT session, so a newly-added printer with no ca_cert_path configured just works: bundled CA if it verifies, trust-on-first-connect auto-pin if it doesn't (P1P, at least) - the same thing examples/auto_connect_bambu.rs already did by hand, now automatic on every real connect. Wiring that in immediately surfaced a real, second instance of a bug the codebase already knew about: build_connector()'s BambuTls::Custom branch used add_root_certificate on the pinned certificate - but ensure_trusted pins a *leaf* cert (CN = the printer's serial number, issued by Bambu's own CA, not a root), for byte-exact fingerprint comparison, not chain validation. Handing that leaf to add_root_certificate asks OpenSSL to treat it as its own trust anchor - exactly the "self-signed certificate in certificate chain" failure test_tls_handshake's doc comment already described, just not fixed at this second call site (the one the real MQTT connection actually uses) until now. native_tls has no per- certificate verification callback hook (unlike rustls), so Custom now accepts any certificate at the TLS layer instead, relying on ensure_trusted having already fingerprint-verified this exact printer moments before - weaker than continuous pinning on every reconnect, but not a fresh regression: pinning a leaf as a root here never worked. Verified live: deleted P1P's existing pin entirely, ran the daemon, and watched it auto-fetch, pin, and connect on the very first attempt - the freshly-pinned certificate came back byte-identical to the one that was there before. Both configured printers (P1P forced v1, H2C auto-detected v2) now connect successfully from a cold start with zero manual steps.	2026-09-05 21:45:32 +00:00
octoturge	4add7c1248	Wire fleet::load into main.rs; fix request() reply unwrapping ... main.rs never actually loaded printers.toml or connected anything - fleet/printer were only ever exercised by standalone examples. Now main() loads the fleet (path configurable via CONTINUUM_PRINTERS_PATH, default "printers.toml") and connects every printer concurrently at startup, logging success/failure per printer rather than failing startup over one bad printer. That surfaced a real bug the instant it ran against a live printer: complete_pending() was sending the whole {"info": {...}} wrapper through the pending oneshot, not the unwrapped body - BambuPrinter::get_version deserializing that into GetVersionResponse failed with "missing field module" even though module was right there, just one level deeper than expected. Fixed by unwrapping the single category key before completing the pending request, symmetric with how a request gets wrapped on the way out. Verified live against a real H2C (MQTT v5/BambuMQTT v2): connect, get_version, and the full pending-request correlation all worked end-to-end, returning real firmware versions for every module (main board 01.01.05.00, both AMS units, AMS HT, etc). The other configured printer (P1P, forced v1) failed with a real, expected TLS error - it doesn't chain to the bundled CA, matching the already-documented P1P quirk; needs the ca_cert_path/fetch_bambu_cert workflow, not a code fix.	2026-09-05 21:39:26 +00:00
octoturge	416ef6db07	Add BambuPrinter::get_version, the first real request/response round trip ... Documents request()'s real constraint on BambuMqttSession directly (not all Bambu commands map 1:1 to a reply, and even where one exists its shape can differ by protocol version - e.g. pushing.pushall triggers an ongoing print.push_status stream rather than a direct reply, and print.calibration data lives inside push_status on BambuMQTT v1 but gets its own report on v2 - so request() is only correct for genuinely one-shot, sequence_id-correlated commands like info.get_version). get_version itself is Bambu-only (no GenericPrinter equivalent, matching test_tls_handshake/fetch_certificate/ensure_trusted's existing pattern): builds the request via continuum-schema-instance, sends it through BambuMqttSession::request, and parses the reply into the existing hand-written GetVersionResponse - reusing the struct already validated against real captured Bambu JSON in bambu_commands_demo.rs, rather than introducing a second response representation. Verified structurally (no real broker reachable from here - confirmed this sandbox has no route into the printer's LAN at all, not just a blocked port): connect fails gracefully against an unreachable host, and get_version correctly reports "not connected" rather than panicking when called without a live session.	2026-09-05 21:27:59 +00:00
octoturge	9643c8b685	Real MQTT wiring for Bambu: connect, auto-detect v5/v3.1.1, request/reply ... Removes GenericPrinter::receive (two disconnected fire-and-forget stubs that didn't actually give request/response) in favor of a real mechanism in the new src/printer/bambu_mqtt.rs: - BambuMqttSession wraps whichever rumqttc client a connection ended up using (v3.1.1's AsyncClient/EventLoop for BambuMQTT v1, v5's for BambuMQTT v2 - different types, different event/error shapes) behind one interface. `open()` respects ForceV1/ForceV2, and for Auto tries v5 first, falling back to v3.1.1 on any failure (see the module doc comment for why "any failure", not a precisely-matched version- rejection code - unverified against a live printer, no broker here to test against). - Reuses BambuTls::build_connector (now pub(crate)) for rumqttc's TLS transport via TlsConfiguration::NativeConnector, instead of a second, separate TLS trust story - hence rumqttc now pulls in use-native-tls instead of its default rustls stack, so there's one TLS implementation in the binary, not two. - request() publishes and waits (with a timeout) for a report whose sequence_id matches, correlated via a shared pending-request table that a spawned background task completes as reports arrive - the first real tokio::spawn in this crate, flagged as deferred since printer/mod.rs's very first doc comment; this is why it was deferred until now, and why it's needed now (polling the eventloop has to run continuously, independent of whatever call site is waiting). - publish()/publish_raw() are the fire-and-forget half, for commands like gcode_line that only get acknowledged implicitly. BambuPrinter::connect/send_gcode_line/publish now call the real session instead of printing what they would do. Verified against 192.0.2.1 (a reserved, never-routable test address): both AsyncClient/EventLoop pairs actually attempt a real TCP connection and fail gracefully (network timeout, not a panic) when nothing answers, and Auto genuinely attempts both while ForceV1 skips straight to v3.1.1.	2026-09-05 21:04:39 +00:00
octoturge	b352fd618d	Add upload_project_file/send_gcode_line, real Marlin serial, Bambu protocol auto-detect ... - GenericPrinter grows upload_project_file, send_gcode_line, and a generic upload_gcode<P> driver that streams a whole gcode file line by line through any vendor's send_gcode_line. - PrusaSerialPrinter's connect/send_gcode_line are real (not stubs): a held-open MarlinSerialConnection (src/printer/marlin_serial.rs) writes each line and waits for Marlin's "ok" before sending the next. Config changed from com_port: i16 to port: String + baud_rate: u32 to hold a real device path. - Bambu: BambuGenericPrinter + BambuV1Printer/BambuV2Printer collapsed into one BambuPrinter, since which MQTT/BambuMQTT version (v3.1.1/v1 vs v5/v2) a printer speaks is discovered at connect() time (or forced), not something config should pick a type for - the same physical printer can change after a firmware update. printers.toml gets a new "bambu" vendor (auto-detect, the default) alongside bambu_v1/bambu_v2 (force a specific one). - Bambu's gcode_line request is now built for real via continuum-schema-instance against continuum-schemas' JSON Schema, picking the v1 or v2 schema directory based on the detected protocol version, instead of a hand-written serde struct. - Added rumqttc as a dependency (not wired up yet - the real MQTT v5-then-v3.1.1 fallback connect and the publish/receive plumbing are still stubs).	2026-09-05 20:40:21 +00:00
octoturge	a2d4e578ec	Replace em dashes with hyphens across docs and comments	2026-08-29 08:13:54 +00:00
octoturge	1583f531fa	Add print.rs (AmsState/AmsUnit/AmsTray/XcamSettings), fix print vs pushing ... Mirrors continuum-schemas' schemas/bambulab/ restructuring: PushallResponse removed (it never existed on the wire — pushall's request goes to "pushing", but the state-push stream it triggers arrives under "print", a different root key, not a direct reply). BambuReport::Pushing(...) -> BambuReport::Print(PrintReport). AmsTray is an untagged enum (Empty/Loaded) rather than one struct full of Option<T> fields, matching the JSON Schema's oneOf for the same slot - #[serde(deny_unknown_fields)] on EmptyTray is load-bearing: untagged enums try variants in order, and a loaded tray (superset of Empty's one field) would otherwise incorrectly match Empty first. Verified against the full real ams/xcam example from the conversation via examples/bambu_commands_demo.rs - both the empty and loaded tray in that payload deserialize to the correct enum variant.	2026-08-28 23:19:20 +00:00
octoturge	4eef52714b	Move bambulab JSON Schemas to continuum-schemas (moved+restructured there) ... Schema definitions belong in the schemas repo, not the service that happens to be their only current consumer — see continuum-schemas' commit for the restructuring (envelope.schema.json unversioned at bambulab/ root, v1/ split into request/ and report/ subdirectories).	2026-08-28 22:58:34 +00:00
octoturge	42eb0b62d5	Add JSON Schema documentation for bambulab/v1, with real inheritance ... Mirrors src/printer/bambu_commands/ as language-agnostic schema docs (not used for codegen — the Rust structs stay hand-written). envelope.schema.json is the base; get_version/pushall request+response schemas extend it via allOf + $ref, which is genuinely closer to real inheritance than anything else in this project's schema stack: proto and Rust only ever gave us composition (embed a field holding the base struct), never a mechanism that reuses a *referenced* schema's constraints automatically. Verified with the jsonschema Python library, not just written by hand: all three real examples from the conversation validate correctly, and — importantly — negative tests confirm the base schema's required fields and the command consts are actually enforced through the allOf chain, not just documented. README covers the one real gotcha (additionalProperties: false on a base schema silently breaks allOf composition, since allOf validates each sub-schema against the whole instance independently rather than merging them).	2026-08-28 22:53:59 +00:00
octoturge	166761479b	Replace proto-based bambu_protocol with plain-Rust bambu_commands/ ... One file per command (get_version.rs, pushall.rs), each holding its request AND response together. CommandEnvelope (sequence_id + command) is the shared-fields piece every command embeds via #[serde(flatten)] — the 'inheritance' replacement for these structs, same composition idea as BambuGenericPrinter in bambu.rs, just expressed as a struct field instead of impl-block delegation. examples/bambu_commands_demo.rs round-trips both commands against Bambu's exact real JSON (from the original conversation) and confirms byte-for- byte matches, same as the removed proto version did — this replacement is behaviorally identical, just without protoc/build.rs in the loop.	2026-08-28 22:49:06 +00:00
octoturge	8e5d85202f	Wire InfoCommand through as one real, runnable example ... BambuRequest::Info(InfoCommand) is now live (was commented out) — examples/bambu_protocol_demo.rs constructs one, serializes it, and prints it next to Bambu's real wire JSON for comparison. Run it and copy this exact shape (proto message -> use it here -> add an enum variant) for every other command.	2026-08-28 22:41:55 +00:00
octoturge	6e18215af5	Add GenericPrinter::set_fan_speed() across all five printer kinds ... Same override pattern as connect(): required, no default body, five completely different bodies. - BambuGenericPrinter::set_fan_speed_impl() is shared by BambuV1Printer and BambuV2Printer (composition reuse, same as connect_impl) - both speak the same MQTT gcode-injection mechanism. - PrusaLinkPrinter and PrusaSerialPrinter both send the same M106 gcode but over different transports (HTTP command injection vs. raw serial bytes) - they share the percent->PWM conversion despite having unrelated connect() implementations. - KlipperPrinter uses a hypothetical Moonraker-native endpoint that takes a percentage directly - no PWM conversion at all, since that math only applies to the gcode-speaking vendors. percent_to_pwm() lives in mod.rs as a private free function rather than a trait default: it's genuine shared logic, but only for the subset of vendors that need it, which is exactly the case a trait default can't express cleanly. Visible to bambu.rs/prusa.rs via super:: because Rust's module privacy reaches into child modules. Verified with cargo check --all-targets and a full run of printer_polymorphism: 50% converges on the same PWM value (127) across all three gcode-based printers, Klipper's native path takes 0.50 directly.	2026-08-28 21:40:11 +00:00