continuum-proxy/src/printer/bambu_commands/mod.rs

//! Bambu's raw MQTT command/report structs - plain hand-written Rust +
//! serde, no protobuf. This data only ever needs to be understood by this
//! crate (raw vendor wire format, never crosses into TypeScript), and the
//! actual wire format is JSON over MQTT, not binary protobuf - protobuf's
//! codegen tooling kept fighting us for a payoff (cross-language codegen,
//! binary wire efficiency) that doesn't apply here at all. Proto stays in
//! continuum-schemas for continuum.v1, which is a schema we designed
//! ourselves and that both TS and Rust genuinely need.
//!
//! One file per Bambu *category* (`get_version.rs` for "info",
//! `pushall.rs` + `print.rs` for "pushing"/"print" - see below for why
//! those are two files, not one). Copy `get_version.rs`'s shape for your
//! next command.
//!
//! Mirrors continuum-schemas' `schemas/bambulab/` JSON Schemas - same
//! category split, same "print vs pushing" correction (see that
//! directory's README for the full explanation): a `pushall` *request*
//! goes to the "pushing" key, but the ongoing state-push stream it
//! triggers arrives under a different key, "print" - so `PushallRequest`
//! lives in `pushall.rs` and the thing it triggers, `PrintReport`, gets
//! its own file, `print.rs`, rather than living together as if one were
//! simply "the response to" the other.

mod get_version;
mod print;
mod pushall;

pub use get_version::{GetVersionRequest, GetVersionResponse, ModuleInfo};
pub use print::{
    AmsState, AmsTray, AmsUnit, EmptyTray, Ipcam, LightReport, LoadedTray, PrintReport, VtTray,
    XcamSettings,
};
pub use pushall::PushallRequest;

/// Fields every Bambu command/response shares. This is the "inheritance"
/// replacement for these structs - composition, not extension: every
/// command below *has* one of these, embedded via `#[serde(flatten)]`
/// (which unwraps it onto the parent object at serialize/deserialize
/// time, so the JSON stays flat - no extra nesting), rather than
/// *extending* a base class. Exactly the same idea as `BambuGenericPrinter`
/// in `../bambu.rs`, just expressed with a struct field instead of a
/// struct-holding-a-struct in `impl` blocks.
#[derive(serde::Serialize, serde::Deserialize, Debug, Clone)]
pub struct CommandEnvelope {
    pub sequence_id: String,
    pub command: String,
}

/// One request you can send to a Bambu printer, keyed by Bambu's top-level
/// JSON category ("info", "pushing", ...). NOTE: that top-level key is a
/// *category*, not the specific command - `CommandEnvelope::command` is
/// what actually says which one ("get_version", "pushall", ...). A
/// category can have more than one possible request shape - if that ever
/// happens here, that variant's payload becomes its own small
/// `#[serde(tag = "command")]` enum instead of a single struct.
///
/// The "print" category isn't a variant here at all: unlike `info`/
/// `pushing`, it has many possible request shapes (`gcode_line`, `pause`,
/// `resume`, ...) in continuum-schemas' own `oneOf`, so
/// `bambu.rs`'s `send_gcode_line_impl` builds that one directly via
/// `continuum-schema-instance` instead of adding it here.
#[derive(serde::Serialize, Debug)]
#[serde(rename_all = "snake_case")]
pub enum BambuRequest {
    Info(GetVersionRequest),
    Pushing(PushallRequest),
}

/// Same idea, the response direction - note "print", not "pushing" (see
/// this module's doc comment).
#[derive(serde::Deserialize, Debug)]
#[serde(rename_all = "snake_case")]
pub enum BambuReport {
    Info(GetVersionResponse),
    Print(PrintReport),
}