Print farm

Choose a quantity; the workflow can arrange copies, slice and match loaded filament.
Start in the app and preview each plate before confirming.
The H2S screen is repaired (owner, 2026-10-25). Bambu Studio or Connect still sends the final Print.
Direct printing from the app needs a verified control route; LAN Developer Mode is now possible from the printer's screen.
People still load filament, clear the bed and inspect finished parts.

Status: proposal — research checked 2026-10-04; planning only.

Recommendation: start with the app tab and the owner's working Bambu Studio cloud workflow. Add automatic preparation using an existing slicer. The screen is repaired (2026-10-25); trial an existing queue/API service before building local automation. Preserve “every task starts in the app” from embeddedera-app and company-operating-system-strategy.

Numbered owner decisions — proposed, awaiting a decision

1. Start with phases 0–1: select the part/build in the app, then open the prepared job on the desktop for final printing. Accept that this first delivery is not phone-only printing.
2. ~~Screen repair~~ done 2026-10-25 (owner). Decide on LAN Developer Mode for direct app printing if saved handling time justifies the cost; accept losing Bambu Handy/cloud features in that mode.
3. Confirm Cricket's released enclosure revision from the latest no-accelerometer work, material, colour and first build quantity. Approve one fit trial before batch production.
4. Keep ERP as the stock authority; use EE-K filament consumables measured in grams initially. Add Spoolman only if managing individual spools becomes worthwhile.
5. Trial Printago's free slot/API after LAN is available; verify commercial/API entitlement. Use a maintained local connector if the hosted service or its terms do not fit. No paid service is recommended now.
6. Require Preview → Confirm for print starts, and an operator's bed-clear confirmation between plates. Creating a build may propose demand; it must not start the printer automatically.

What is known, and what changes from September

Owner-reported baseline: Bambu H2S (touchscreen repaired 2026-10-25; damaged before), bound to the owner's Bambu account; Studio already prints through cloud. Installed firmware, account region, AMS configuration and present connectivity were not inspected. This research accessed no printer or account.

The September cloud-control decision is superseded by this proposal. A working official cloud client does not establish third-party write access. Switching to LAN is a setup and acceptance exercise, not merely changing one configuration value.

Keep the house starting profile: 0.2 mm layers, 4 walls, 5 top/bottom layers, 40% infill, automatic tree supports. Release validated per-part overrides; the enclosure's small snap features may require different support settings.

Printer control: four routes

A — Unofficial cloud API/MQTT: monitoring candidate, not the production start path. Bambu introduced Authorization Control in January 2025, protecting critical commands including starting prints through cloud or LAN. Connect is its supported third-party hand-off. Bambu announcement.

The ha-bambulab maintainers report that sensor reads continue on restricted firmware while most writes fail in cloud mode. Its login/device-discovery/MQTT client is useful reference code for status and AMS data; this is not a supported public Bambu API-key contract. Do not assume an account token authorizes print-start commands. Maintainer compatibility notes.

Login verification, token expiry, rate limits and private endpoint changes add maintenance. In May 2026 Bambu explicitly opposed clients impersonating Studio and said cloud access is governed separately from the AGPL code licence. Blocking or account restrictions are a risk; this research found no basis for predicting a ban for ordinary ha-bambulab monitoring. Avoid spoofed client identities or signing bypasses. Bambu's 2026 position.

B — Studio/Connect hand-off: safest first route. Prepare a project 3MF for Studio, or a validated sliced plate package for Connect; the operator checks printer/AMS mapping and presses Print in official software. Bambu documents third-party slicing followed by Connect. This retains the existing account workflow without putting its password in Home. Official integration explanation.

Initially offer Download job / Continue on desktop, using Studio already installed by the owner. A phone webpage cannot launch a desktop program remotely. A later installed desktop handler could open the exact job; it would still require final confirmation. Do not assume a supported headless Connect API or a Linux Connect build; verify the chosen desktop version during the pilot.

C — Repair → LAN-only + Developer Mode: preferred direct-control route. Standard LAN mode still applies authorization; Developer Mode exposes the local interfaces for third-party integration. Plan a maintained MQTT/TLS client for commands/status and FTPS for file upload, using the printer IP, serial and access code. H2S explicitly advertises Developer Mode/MQTT support. Bambu LAN explanation, H2S product specification.

Screen blocker (resolved 2026-10-25: screen repaired): published setup requires enabling LAN-only and Developer Mode on the printer. No supported way to enable both from Handy or Studio with an unusable touchscreen was established. Studio may expose an access code; knowing it does not enable Developer Mode. Budget for repair or a manufacturer-confirmed service procedure, not a presumed remote toggle. Current setup instructions.

LAN-only disconnects Bambu Cloud/Handy. A server on the printer's LAN can still serve Home remotely through the existing access gate; never expose printer ports publicly. Confirm firmware/storage requirements and command support on this H2S. Third-party protocols remain unsupported by Bambu; keep a working official-software fallback. H2S integration requirements.

D — Existing tools: evaluate before custom control. (The damaged-screen blocker they could not remove is gone since the 2026-10-25 repair.)

• OctoPrint-BambuPrinter: free AGPL plugin, explicitly a work in progress. Could reuse OctoPrint's API ecosystem, but H2S print-start/AMS compatibility needs proof. Adds an OctoPrint service; not the first choice for one printer. Maintainer repository.
• Obico: open-source/self-hosting option for monitoring and failure detection; its documented Bambu route uses the OctoPrint plugin above. It is not an ERP quantity-to-plate engine and inherits connector restrictions. Defer unless its monitoring solves a demonstrated need. Obico's Bambu guide.
• BambuBoard: dashboard/streaming tool, not our production queue. Current v3 focuses on one printer; v2 offered fleet management. Its maintainer marks H2S support unverified and maps it to H2D capabilities, so do not trust that hardware model blindly. Repository and limitations.
• Bambu Farm Manager: official free local fleet software with queues, batch control and file management; the old note incorrectly grouped it with status-only dashboards. Its launch supported Windows 10+. Current H2S compatibility, OS coverage and public API were not established; verify before choosing it. Official launch/features.
• SimplyPrint: managed queues, slicing and filament tools; H2S uses an always-on LAN bridge plus Developer Mode. Free service does not include API access; write/upload API requires its Enhanced tier (Print Farm or above). Defer paid integration while free routes meet the need. H2S setup, API tiers.
• Printago: strongest existing workflow candidate: quantity/SKU builds, plate merging, slicing, material matching and REST/events. Current pricing includes one free concurrent production slot; H2S is listed as LAN-supported. Trial before duplicating these engines. Confirm API/commercial entitlement because pricing and overview wording differ. Pricing, compatibility, build API, overview.

Slicing: reuse an engine, prove the output

Latest stable releases returned by official release pages during this research: Bambu Studio 2.8.2.61 and OrcaSlicer 2.4.2. Pin a tested binary, bundled profiles and checksums; do not follow nightly or silently update production profiles. Studio release, Orca release.

Both contain an H2S 0.4 mm profile; choose the actual fitted nozzle/hotend variant, not that example by default. H2S's nominal volume is 340 × 320 × 340 mm; usable plate capacity also depends on brim/support/clearance and process settings. Orca H2S profile, Studio H2S profile.

Both expose CLI arrangement/orientation, cloning, slicing and profile loading. Use --arrange 1 and per-input --clone-objects counts; --repetitions concerns the whole model and has single-plate restrictions. Verify count semantics in the pinned build using one part, several copies and an overflow case; never infer the requested quantity from a successful exit code. Orca transforms, object/profile options, Studio CLI definitions.

Load machine/process JSON with --load-settings and filament JSON with --load-filaments; supports come from the process/per-object settings. --orient 1 can propose an orientation, but production uses a reviewed orientation and support policy. Freeze inherited profile dependencies so the same release remains reproducible. Orca CLI settings.

When N does not fit, retain exactly N instances across numbered plates. Use the slicer's arrangement and, if necessary, bounded batching around it; do not write a nesting algorithm. Validate every plate's part counts and detect unplaced/oversized objects. --slice 0 slices all plates; individual plate selection is available. One plate is one separately confirmed printer job. Slicing/export options.

Distinguish geometry 3MF, project 3MF with settings, and sliced G-code/plate package. The printer does not slice an STL. A file ending in .3mf is not necessarily printable. Export sliced H2S toolpaths plus required plate metadata/previews; check package contents and import it through the intended sender. Renaming a project to .gcode.3mf does not convert it.

Bambu Studio is not the only permitted slicer: Bambu explicitly documents sending third-party sliced Bambu-compatible G-code/3MF through Connect. Compatibility depends on the target machine and package, not just the originating brand. Prefer Studio for the first pilot; validate Orca's output on the actual H2S before substitution. Bambu file hand-off.

Linux server slicing is feasible; Orca documents headless CLI use. Studio also exposes CLI actions and Linux builds. Packaging and preview rendering need a pilot: graphics/runtime dependencies may require a virtual display, and a successful slice may lack a thumbnail. Reuse slicer previews; do not build an interactive 3D editor. Orca headless mode, Studio CLI/export definitions.

Both slicers are AGPL-3.0; Bambu's networking component has separate terms. Use unmodified upstream binaries as separate processes, preserve notices, and review source-offer obligations before distributing modifications or integrating modified network services. This plan assumes no slicer fork. Orca repository/licence, Bambu's licence/cloud distinction.

Cricket files and release identity

Inspected the supplied scratch checkout under /tmp/claude-1000/-home-angel/210d14ae-2cde-48bb-8957-029baf52a5b3/scratchpad/Cricket/mechanical. Its local branch is main, commit 9cae8a7 dated September 16; only main/origin-main refs were present. The owner's latest work is on no-accelerometer; its contents were not available here. Do not treat this old checkout as the production release.

mechanical/cricket-008/ contains Base/Lid STL and 3MF, Cricket008-enclosure.FCStd, enclosure.py and README. Both 3MF archives contain only model/package XML, with no sliced G-code or process profile. They are geometry inputs.

The README says both meshes are already flat face down, open side up; do not invert the Lid again. It calls for a PLA/PETG fit trial at 0.2 mm and identifies an unproven 0.9 mm snap-shoulder overhang. Keep auto-orientation off for this candidate; inspect support placement around the flexible hooks and small gaps. CAD checks do not establish print fit or snap durability.

Store source CAD, exported meshes and approved print profile in the owning product repo. ERP print_file resolves a repo + immutable commit/release + relative path, with artifact SHA-256, just like firmware. A branch name is a development locator, never a production pin; /tmp is not an artifact store.

Each job snapshots model/profile hashes, slicer version, printer/nozzle/plate, material/colour, quantity, plate index and build ID. Keep generated plate files and previews in retained job artifacts, linked from ERP/app; a reprint chooses that release explicitly. A changed mesh or profile invalidates the prepared preview.

Material, colour and filament stock

ERP printed parts retain print_file and print_material; add colour requirement, approved filament/profile, orientation/support policy and release identity. Keep printed mechanical parts as EE-M parts on the BOM. Base ×1 + Lid ×1 means ten enclosures require ten of each, subject to the verified current BOM.

Read AMS unit/tray identity, material type and colour from fresh status; community clients expose tray type/colour fields. Match the ERP requirement to a compatible loaded slot and pass an explicit filament-to-slot mapping to the sender. A slicer filament profile is not an AMS slot number. ha-bambulab tray interface.

Non-RFID spools rely on entered metadata; reported colour is not a physical colour measurement. Require exact approved material/profile and colour/SKU, or an explicit recorded substitution. Unknown/stale/mismatched data should block automatic selection and ask the operator to check/load filament; never silently choose the nearest colour or whichever PLA is present.

Show nozzle/plate information when available, but label reported configuration separately from verified hardware. Do not preserve the old “never typed in” assumption: unknown or stale fields need operator confirmation. Recheck printer, AMS mapping and available grams at dispatch; a spool swap after slicing invalidates the confirmation.

ERP first: filament becomes an EE-K consumable per material/colour/product, with stock in grams and spool/lot identification where useful. Reserve the slicer's per-filament estimate, including supports, brim and purge; confirm consumption per completed attempt. Keep estimates visibly labelled and reconcile by weighing where accuracy matters.

Failed/cancelled jobs still consume filament; use a reviewed partial-use estimate or measured correction. Deduplicate consumption and receipt events. Avoid consuming the same grams through both a printed-part BOM and a separate job transaction. Parent assembly builds consume the received EE-M parts, not the filament again.

Spoolman alternative: free MIT, self-hosted, individual spool records, remaining weight, QR labels and REST/WebSocket APIs. Better when partial spools and frequent swaps become difficult; it does not itself slice, dispatch or magically measure Bambu usage. A connector must associate each AMS tray with a spool and post consumption. Spoolman features/licence.

Defer that extra service for one printer. If adopted, let Spoolman own operational spool remaining grams and ERP own purchasing/cost and confirmed stock transactions; map IDs and reconcile from one consumption event. Do not maintain two independently editable remaining-weight ledgers. Keep its API behind the existing private service boundary.

App workflow and authoritative records

Reuse the object-tab pattern in app-test-program-tab-plan. On a printed part → 3D print tab show approved file/revision, preview, material/colour, quantity, printer status and recent jobs. On assembly → 3D print, list printed BOM sub-parts with Print for this build and links to their part tabs.

Calculate gross demand as build quantity × BOM quantity, then show allocations/on-hand and already queued quantities before proposing the shortage. Let the owner explicitly request extra stock. Repeated clicks/build updates must reconcile the same demand, not duplicate it. Build creation initially creates a draft proposal only.

Add MAKE → 3D print queue, linked from each tab/build: Draft → Preparing → Ready → Handed off/Sent → Printing → Awaiting inspection → Received; also Failed/Cancelled. Show per-plate counts, time/grams estimates, status freshness and pending ERP updates. The queue holds execution state; ERP owns parts, BOMs, builds and confirmed stock.

Preview → Confirm → Send/hand off: plate image, copy counts, approved revision, H2S/nozzle/plate, material/colour and mapped slots. Unknown/offline/unsupported states must be visible. Handoff is not proof a print started; use an operator acknowledgement until reliable telemetry is integrated. Pause/stop appears only when the selected route supports it; otherwise open Studio.

After each plate, the operator removes parts, checks fit/appearance, records good/reject quantities and confirms the bed is clear. “Printer idle” or “100%” is not bed-clear evidence. Receive accepted printed parts through the existing ERP build process, linked to the consuming build; retain scrap/reprint history. Do not complete the electronic assembly merely because its enclosures finished.

Use linked printed-part sub-builds where appropriate; validate the deployed ERP workflow against SOP-001/SOP-006 before implementation. Stock receipt must be idempotent and ERP-confirmed. Already-started printing has no true Undo: offer supported cancel/stop and preserve the event history; queued work can be withdrawn.

Keep the existing app gate, department permissions and phone layout. If an existing queue is adopted, Home displays its jobs and invokes its API; do not introduce a second scheduler. Custom work is limited to release/build mapping, previews, common actions and ERP reconciliation.

Phases, effort and acceptance

Estimates are focused engineering days for one implementer with review, excluding repair, delivery, owner availability and physical print time. Later phases require separate implementation authorization.

• 0 — Verify the pilot, 0.5–1 day. Confirm H2S firmware/nozzle/plate/AMS, desktop software, current Cricket branch/release and repair quote. Choose one enclosure/material/colour; prepare a reviewed profile in Studio. Exit: one physically accepted Base/Lid pair and known file identity.
• 1 — Smallest useful app hand-off, 2–3 days. Part/assembly tabs, build-derived quantity request, released file/profile links, simple job list and desktop continuation; arranging/slicing remain in Studio. Reuse existing ERP receiving. Exit: one build can be followed from app request to accepted stock without losing its revision or quantities.
• 2 — Automatic preparation, 3–5 days. Pin Studio CLI first; generate exact copies, arrange/split plates, slice, preview and retain artifacts. Studio/Connect still owns final Print. Exit: 1, N, overflow and mixed Base/Lid cases produce correct counts and valid H2S packages; mismatch and oversized objects block readiness.
• 3 — Direct printing after repair, 2–4 days for an existing-service pilot. Test Printago API/free entitlement and H2S LAN mapping first. If unsuitable, allow 5–8 days instead for maintained local connector integration. Exit: confirmed dispatch, progress/failure, supported stop, reconnection and uncertain-send reconciliation; no duplicate print after timeout/retry.
• 4 — Stock/consumption automation, 2–4 days if justified. Per-attempt grams, partial acceptance, scrap and ERP reconciliation; optional Spoolman needs its own scoped estimate. Exit: partial failure/reprint and duplicate events produce the right stock exactly once.

Phases 0–1 total 2.5–4 days plus print trials; adding phase 2 gives 5.5–9 days for automatic preparation with official final hand-off. Re-estimate later phases after the pilot. A repair quote should be compared with desktop handling minutes per job × expected jobs, plus the value of restored local control.

Implementation checks: isolated data/sandbox ERP, pinned slicer repeatability, stale AMS/spool swaps, full-bed overflow, mixed quantities, rejected parts, failed uploads and ambiguous start acknowledgements. Keep one printer dispatch owner; reconcile before retrying any uncertain start. Run the app's mandatory iPhone WebKit app-ui-check and release process before deployment; record the recurring operator procedure under the existing SOP system then.

Open facts and risks

• Owner to identify printer serial, firmware and exact H2S configuration; confirm account region/owner and desktop OS/Studio version. No password or token is needed for this planning phase; future credentials belong in the established secret store, never this note.
• ~~Screen repair~~ done 2026-10-25 (owner).
• Reconcile no-accelerometer with the inspected September geometry; confirm released Base/Lid, approved material/colour, build quantity and who accepts snap-fit samples.
• Confirm loaded spool metadata, residual grams, nozzle/plate and operator availability to clear beds. Unknown capacity means a hold, not an automatic substitution or extra copies to fill space.
• Firmware/auth changes, cloud outages, CLI/package incompatibility, profile drift and wrong AMS mapping can invalidate a job. Pin and rehearse changes; keep official desktop printing available.
• Farm Manager's current H2S/API support and Printago's exact free commercial/API scope remain gates. Some Bambu wiki/terms pages could not be retrieved; the linked official announcements and vendor setup guides support the qualified conclusions above. No hardware compatibility claim here is a bench test.

Prepared by the primary Codex session; no helper models ran. Capacity readings were missing and enforced read-only helper confinement was unavailable. Only this note was edited; the one-file restriction excludes sync, commits, memory changes and implementation.

Log

• 2026-09-16: written from Angel's ask; scout confirmed the LAN path (Developer Mode, MQTT + FTPS, Home Assistant's ha-bambulab as reference code) but hit its search budget before the H2S specifics.
• 2026-10-04: Rewritten as a researched proposal for part/assembly tabs, official desktop hand-off first, optional LAN control after repair, existing-tool trials and ERP receipt. Preserved September history; no printer/account access or implementation.

10-line summary

Start printing work in the app's 3D print tab.
Derive printed-part quantities from the selected build.
Use Studio/Connect for final Print (screen repaired 2026-10-25).
Reuse a pinned slicer for copies, arrangement and slicing.
Preview every plate and confirm material/colour mapping.
Screen repaired 2026-10-25; LAN control can now be planned.
Trial an existing queue/API before building automation.
Pin Cricket files to an approved release from current work.
Inspect prints, clear the bed and receive accepted stock.
Begin with the 2.5–4-day app hand-off pilot. - 2026-10-05: Local access verified read-only from the Plex server: H2S at 192.168.4.98 (serial 0938AC5B0400665; ~/.config/bambu/env 0600, access code fetched via a brief LAN-only toggle). MQTT 8883 (user bblp) → status + AMS (PETG HF black, PLA Matte black, PLA Wood, PLA Matte grey; AMS HT: ASA red); FTPS 990 implicit TLS with data-channel session reuse → 69 files listed. Nothing printed or changed. Owner wants to stay in cloud mode (not LAN-only) → Option A: app slices + uploads plate via FTPS, operator presses Print on the printer screen. - 2026-10-05: Owner decision: stay in normal cloud mode (no LAN-only). Route = the app slices + uploads the plate to the printer's storage (FTPS), and a person starts it from the printer screen or Bambu Handy (printer → files). Owner: "That will work also." Still to confirm: local MQTT/FTPS work with LAN-only OFF (re-run the read-only probe), and Handy shows the printer's files with a Print button on the H2S. - 2026-10-25: Owner: H2S screen repaired, everything fixed. Cloud-mode decision (2026-10-05) still stands. Adding the printer to Home Assistant (local MQTT read via ~/.config/bambu/env) in a separate session. - 2026-10-25: Home Assistant: ha-bambulab v2.2.26 (HACS) installed, config entry H2S-0938AC5B0400665 in LAN mode (IP+serial+access code from ~/.config/bambu/env), printer left in normal cloud mode (firmware 01.02.00.00, Developer LAN mode off). Works (read, live over local MQTT): print status/stage, progress %, layer x/452, time left + end time, task name, nozzle/bed/chamber temps + targets, fans, AMS 2 Pro + AMS HT trays (type, colour, remain %), AMS humidity/temp/drying, HMS errors with text, print error, door, online, Wi-Fi, cover image (print preview PNG via FTPS). Does not work in cloud mode: pause/resume/stop buttons and fan/number controls are not even created (printer requires MQTT signatures = Authorization Control); chamber light entity exists but untested (a print was running); camera unavailable because LAN Only Liveview (RTSP 322) is off — owner can enable it on the printer screen without leaving cloud mode. Alerts: script.printer_announce + automations h2s_print_done / h2s_print_problem (kitchen-hub server/, commit 73f0e32; backups *.bak-20261025-printer); simulated both 2026-10-25, all steps ran without errors; owner to confirm hearing/seeing them. - 2026-10-25: owner confirmed the H2S test alerts arrived (Echos + iPhone push with picture).