`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.
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.
- 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).
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.
Certs:
- Vendor Bambu's shared LAN-mode root CA (certs/bambu_ca2.pem, verified
self-signed CA:TRUE, see certs/README.md for provenance/fingerprint).
- Config gains bambu_ca_cert_path (per-printer override) and
bambu_require_valid_cert (the allow/reject flag); printer::bambu::BambuTls
turns those into BundledCa/Custom/Insecure. connect() doesn't perform a
real handshake yet (no TLS-capable MQTT client wired in), just reports
which trust mode it would use.
Also reconciles a rename in flight (Printer -> GenericPrinter trait) and
finishes the PrusaPrinter -> PrusaLinkPrinter/PrusaSerialPrinter split:
added the missing GenericPrinter impl for PrusaSerialPrinter, fixed
PrinterHandle's variant payload types, updated mod.rs's pub use list and
doc comments, and updated the example to the new 5-variant shape.
Verified with cargo check --all-targets (0 errors) and a full run of
cargo run --example printer_polymorphism.
Drop reqwest, RPITIT+Send signature, and multi-variant error enum from the
teaching example so the only new idea per file is the trait override itself.
Real networking stays in adapters/, unaffected.
octoturge