bambu p1s almost there... | Friends of the Crustacean 🦞🤝 | Page 1

old martenBOT Feb 19, 2026, 7:06 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

modern gardenBOT Feb 19, 2026, 7:08 AM

#

If the printer is in LAN Only mode, a couple things change:

Bambu Handy (phone app) won’t let you start prints in LAN mode — you generally need Bambu Studio / OrcaSlicer on the same local network to actually hit Print.
If you are in Studio and it’s connected (you can see/send files) but Print is greyed out / won’t click, the two most common gotchas are:
1. No microSD card in the printer (LAN printing uses the SD for the job)
2. “Developer Mode” is OFF in the printer’s LAN-only settings (required for some third-party/control flows)

Can you tell me what you’re trying to press Print in (Bambu Studio on PC, OrcaSlicer, phone app, or something else), and ideally drop a screenshot of the screen where the Print button won’t work? That’ll make it obvious which of the above you’re hitting.

ashen zephyr Feb 19, 2026, 7:11 AM

#

I want the agent o hi print, are you saying I need developer mode on or off?

modern gardenBOT Feb 19, 2026, 7:11 AM

#

If you’re using Bambu Studio (official) to print in LAN Only mode: Developer Mode should be OFF.
Developer Mode is basically “allow third‑party control” — only turn it ON if you’re trying to print/control via non‑Bambu software (e.g., OrcaSlicer/3rd-party integrations).

So for your case (“I want to hit print”):

Bambu Handy app: won’t start prints in LAN-only mode (you need Studio on the same LAN).
In Bambu Studio: leave Developer Mode OFF, but make sure:
1. You’ve entered the LAN access code for that printer in Studio (lock icon printer)
2. The printer is Idle/Ready (not paused / in error)
3. A microSD card is inserted (missing SD can block starting jobs in some LAN flows)

If you tell me what app you’re in (Bambu Studio vs phone app vs Orca) and what exactly happens when you try to print (button greyed out? error toast?), I can narrow it to the one fix.

ashen zephyr Feb 19, 2026, 7:12 AM

#

I think the AI is creating it in blender and just sending it somewhere?

modern gardenBOT Feb 19, 2026, 7:13 AM

#

Yeah — that’s very likely what’s happening.

A Blender file / STL / OBJ is just geometry. A Bambu printer can’t print that directly. It needs a sliced toolpath (G-code), which normally comes from Bambu Studio / OrcaSlicer.

So if your “AI agent” is:

generating a model in Blender
exporting an .stl (or .obj)
“sending it to the printer”

…then you’ll see “files coming in”, but you still won’t be able to actually Print, because the printer can’t slice.

Quick checks:

In the printer’s file list / Studio device tab, what are the file extensions you see? .stl/.obj = not directly printable. .gcode/.3mf = printable.
If you open the model in Bambu Studio → Prepare, do Slice plate first, then you should get Print plate / Send & Print.

If you tell me what files you’re seeing on the printer (just the extensions) and what app the agent is using to “send”, I can tell you the exact missing step.

#

Yep — what you have right now is “upload succeeded”, not “print started.” FTP only puts the file on the SD card; the Print action is a separate MQTT command (that’s what Bambu Studio does behind the scenes).

1) Developer Mode: ON (for your setup)

Since you’re using third-party control (bambu-js), you generally want Developer Mode / “Enable 3rd-party control” = ON in the printer’s LAN settings.
(If you were only using Bambu Studio, you’d leave it off.)

2) Actually start the job via MQTT

With bambu-js, you’ll need a PrinterController connection and then send a print command. The command you’re looking for is usually:

print → command: "gcode_file"
param: "<absolute path on printer>" (commonly /sdcard/<file>.gcode)

Conceptually:

import { PrinterController } from "bambu-js";

#


const printer = PrinterController.create({
  model: "P1S",
  host: "192.168.2.192",
  accessCode: "78919951",
  serial: "YOUR_DEVICE_ID_OR_SERIAL", // important for MQTT topics
});

await printer.connect();

await printer.sendCommand({
  print: {
    sequence_id: "0",
    command: "gcode_file",
    param: "/sdcard/openclaw_1771483637935.gcode",

#

  },
});

Two gotchas that bite people:

You need the correct serial/device-id for MQTT (FTP doesn’t need it, which is why upload works but print doesn’t).
The path must match where you uploaded (if you uploaded to a subfolder, use that exact /sdcard/... path).

Quick sanity test

Can you start that same openclaw_....gcode from the printer screen (Files → select → Print)?
If it prints from the screen, your file is good and it’s just the missing MQTT “start” step / wrong path / missing serial.

If you paste what you’re using for printerPath (the remote path you upload to) + whether Developer Mode is currently enabled, I can tell you the exact param you should use.

ashen zephyr Feb 19, 2026, 7:23 AM

#

ok is there a better way to do this and not use developer mode?

#

⚠️ 🛠️ Exec: cd ~/.openclaw/workspace/projects/bambu-printing && ./send_to_bambu.sh test_trimesh.stl 2>&1 failed: 🔧 Slicing with BambuStudio...

modern gardenBOT Feb 19, 2026, 7:28 AM

#

That “failed: 🔧 Slicing with BambuStudio…” line is just your script’s status label — the useful part is usually the next ~10–30 lines (the actual BambuStudio error).

Can you paste the output after that line (or rerun and paste the full block)?

In the meantime, the 2 most common reasons this exact step fails:

BambuStudio binary not found / not executable
- Your script might be calling BambuStudio / bambu-studio / an AppImage path that doesn’t exist.
- Telltale error: command not found or No such file or directory.
Headless / no display available (very common on servers)
- Bambu Studio is a GUI app (Qt). On a headless machine it often dies with something like:
  qt.qpa.xcb: could not connect to display
- Fix is either:
  - run it via xvfb-run (virtual display), or
  - switch the pipeline to a slicer that supports true headless CLI (PrusaSlicer/OrcaSlicer CLI), since you’re already successfully producing .gcode with PrusaSlicer.

#

Also: if you paste the relevant part of send_to_bambu.sh where it invokes BambuStudio (the exact command line), I can tell you precisely what to change (path vs headless wrapper vs flags).

ashen zephyr Feb 19, 2026, 7:36 AM

#

None of the slicers have CLI commands to send to printer over network. They're all designed for:

GUI workflow: Slice → Click Send button
CLI workflow: Just slice to G-code (no sending)

The MQTT print trigger is blocked even in LAN Only Mode (we're getting "Not authorized" now).

───

modern gardenBOT Feb 19, 2026, 7:37 AM

#

“Not authorized” there usually means your MQTT topic device id (“serial” in bambu-js) doesn’t match what the printer expects, or 3rd‑party control / Developer Mode is off.

A couple concrete points given your setup:

1) Slicers: you’re right

PrusaSlicer/Orca/Bambu Studio CLIs are basically “slice/export”, not “send+start” over LAN. The normal LAN automation path is exactly what you’re doing:
slice → FTP upload → MQTT start command.

2) bambu-js is VERY strict about `serial`

In bambu-js, PrinterController publishes/subscribes to:

device/${serial}/report
device/${serial}/request

If serial is wrong, the broker/printer can respond with Not authorized on subscribe/publish.

So make sure serial is the printer’s device ID used in MQTT topics (often shown as the printer SN/device id), not just a friendly name.

#

Fast way to discover the correct one:

Connect with an MQTT client and subscribe to device/+/report (or even #) and see what topic messages come in on. The middle part is the correct id.
- Broker: mqtts://<printer-ip>:8883
- Username: bblp
- Password: LAN access code
- TLS: allow self-signed (rejectUnauthorized: false)

3) Developer Mode / 3rd‑party control

If you can monitor but publishing “start print” gets rejected, double-check on the printer:

LAN Only mode enabled
Developer Mode / 3rd‑party control enabled (this is the “allow third-party software to control print jobs” toggle)

4) Start the uploaded `.gcode`

Once MQTT is authorized, the start command is typically:

#

{"print":{"sequence_id":"1","command":"gcode_file","param":"/sdcard/openclaw_1771483637935.gcode"}}

(Exact param must match where FTP put the file.)

If you paste where the “Not authorized” is happening (during MQTT connect vs during publish), and what you’re passing as serial, I can tell you which of the two (wrong serial vs dev-mode) is the blocker in your case.

ashen zephyr Feb 19, 2026, 7:39 AM

#

Id like to avoid developer mode in these early stages, the agent is about to control other things, like light, on or off etc in the printer..

modern gardenBOT Feb 19, 2026, 7:40 AM

#

If you keep Developer Mode / 3rd‑party control OFF, you should assume:

FTP upload can still work (you can “send” files onto the SD)
Most MQTT “do something” commands will be rejected with exactly what you’re seeing: “Not authorized”
- That includes starting a print (print.gcode_file / project_file)
- And usually also “harmless” controls like lights (system.ledctrl), because they’re still remote control commands

So if your goal is “early stages, least power possible”, that’s totally reasonable — but it means your automation can only go up to:

Safe early-stage workflow (no dev mode)

Slice → produce .gcode
FTP upload .gcode to /sdcard/...
Start the print manually on the printer screen (or via Bambu Studio UI)

That’s the cleanest way to avoid giving an agent “full remote control”.

If you later want automation without giving the agent the keys

#

The printer doesn’t really do granular permissions: the LAN access code is basically full authority once dev mode is on. A good compromise is:

Turn dev mode on
Don’t give the model/agent the access code
Put a tiny local “print gateway” service in between that only exposes whitelisted actions (e.g. light_on, light_off, maybe start_print with extra checks / manual approval)

If you tell me whether you can start the uploaded openclaw_*.gcode from the printer screen right now, I can confirm you’re already 100% working and it’s just the intentionally-blocked “remote start” piece.

ashen zephyr Feb 19, 2026, 7:46 AM

#

⚠️ 🛠️ Exec: cd ~/.openclaw/workspace/projects/bambu-printing && node -e " failed: 📋 Testing MQTT connection with:

modern gardenBOT Feb 19, 2026, 7:47 AM

#

That exec error looks like it’s not even getting to MQTT yet — it’s failing because the shell is seeing an unterminated quote:

node -e " ... (starts a " string, but it never closes)

So whatever your script is building for node -e is getting cut off (usually because of nested quotes / newlines / JSON).

Fix: don’t do `node -e "..."` for this

Make it a real .js file (or a heredoc), so quoting can’t explode.

Option A: heredoc (zero quoting pain)

node <<'NODE'
const mqtt = require("mqtt");

const host = "192.168.2.192";
const accessCode = "78919951";

#

const serial = "PUT_DEVICE_ID_HERE"; // the MQTT topic id (device/<id>/...)

const client = mqtt.connect(`mqtts://${host}:8883`, {
  username: "bblp",
  password: accessCode,
  rejectUnauthorized: false,
});

client.on("connect", () => {
  console.log("connected");
  client.subscribe(`device/${serial}/report`, (err) => {
    console.log("subscribe report:", err ? err.message : "ok");
  });
});

#

client.on("error", (e) => console.error("mqtt error:", e.message));
NODE

Also: about avoiding Developer Mode

If your goal is “agent can’t control the printer yet”, keeping it OFF is sensible — but then print-start and light control will likely be blocked (that’s basically what Developer Mode is for: 3rd‑party control).

So you can still do:

slice → FTP upload → manual start on printer

…but not:

MQTT start print / toggle light (until you enable 3rd‑party control, or put a strict proxy in front of it)

Quick question to pinpoint the “Not authorized”

When you saw “Not authorized”, was it:

an MQTT client error / subscribe error (broker-level), or

#

a JSON response from the printer on .../report saying not authorized (application-level)?

If you paste the exact line where “Not authorized” appears, I can tell you which one it is and the exact fix (wrong device id vs dev-mode gating).

ashen zephyr Feb 19, 2026, 7:54 AM

#

can we delete this whole conversation and start fresh?

modern gardenBOT Feb 19, 2026, 7:54 AM

#

I can’t delete the whole Discord conversation/thread from here.

What we can do:

Start fresh right now: tell me “ignore everything above”, and I’ll reset and only use what you paste next.
You delete your own messages in Discord (hover message → … → Delete Message).
If you want the entire thread removed/cleared, that’s mod/admin territory (they can delete/lock/archive depending on server settings). You can also just create a new thread and continue there.

If you want to restart: paste just these 5 things and we’ll go from zero:

printer model (P1S?) + firmware version
are you in LAN Only? (yes/no)
do you want Developer Mode off? (yes/no)
what you want to achieve first (upload only / start print / lights)
the exact error line you’re currently seeing (one log snippet)

ashen zephyr Feb 20, 2026, 2:47 PM

#

do you recall the command to change api key, i seem to have changed in the open claw json but i dont think its remembering.

modern gardenBOT Feb 20, 2026, 2:51 PM

#

If you’re changing an LLM API key, don’t just edit openclaw.json and expect it to override everything—OpenClaw often reads keys from ~/.openclaw/.env (and config/env never overrides an already-set env var).

The “do it again” command (recommended)

OpenAI key:

openclaw onboard --openai-api-key "$OPENAI_API_KEY"
# (or interactive) openclaw onboard --auth-choice openai-api-key

Anthropic key:

openclaw onboard --anthropic-api-key "$ANTHROPIC_API_KEY"

This is nice because it stores it in a place the daemon/service will actually pick up.

The “just set it” way

#

Put the key in the daemon-read env file:

nano ~/.openclaw/.env
# add/update e.g.
OPENAI_API_KEY=sk-...
# or
ANTHROPIC_API_KEY=sk-ant-...

After changing it

Restart the gateway:

openclaw gateway restart

And verify what it’s using:

#bambu p1s almost there...