New Community Node: Bambu Lab 3D Printer 🖨️

Built with n8n
, , ,
1

I built an n8n community node for Bambu Lab 3D printers that communicates directly over your local network — no Bambu Cloud required.

What it does:

  • Get Status — pull a full snapshot of your printer: temperatures, progress, layer count, filament, state, and more

  • Trigger node — poll the printer on an interval and emit events when something changes, e.g. when a print finishes or an error occurs

The trigger node is the main reason I built this. Combined with n8n’s existing integrations, you can do things like:

  • Get a Telegram/Slack/email notification when a print completes

  • Alert on printer errors

  • Log print history to a spreadsheet

  • Trigger automations when the printer goes idle

Why local-only? Bambu’s MQTT broker is point-to-point — the printer only responds to the client that requests it, so passive cloud listening doesn’t work. This node handles the request/response flow for you.

Install: @hanna84/n8n-nodes-bambulab
npm: https://www.npmjs.com/package/@hanna84/n8n-nodes-bambulab

2 Likes
2

going local-only makes sense, bambu’s cloud layer drops way more than youd expect. curious whether the trigger handles reconnects automatically or if the workflow needs restarting when the printer goes offline?

3

Good question!

I’m testing it now. It seems I got an event from the printer when I turned it back on. But then I changed the lights from off to on, and that event doesn’t seem to have been registered.

Not sure how that happens. I will investigate. :stuck_out_tongue:

Edit: Due to the printer sending idle/finish states every other time, I previously added a check to verify whether there was an actual change, or it would spam “finish” statuses. It works, but it means it doesn’t detect changes in the lights’ on/off status when the overall status hasn’t changed.

Adding a fix now. :slight_smile:

4

Investigation completed!

Reconnects are handled automatically by the underlying MQTT client library — it will keep retrying if the printer goes offline or drops the connection, so the workflow doesn’t need restarting. The poll interval also helps: every N seconds it publishes a PUSH_ALL request, and client.connected is checked before sending so it won’t error on a dropped connection.

That said, if the printer is offline for an extended period and MQTT gives up entirely, n8n would need the workflow deactivated and reactivated to re-establish.

In practice with a local P1S/X1C this hasn’t been an issue — the printer reconnects to the local network quickly and the MQTT client catches back up.

5

Thanks for diving deep into this! The auto-reconnect behavior sounds perfect — means workflows won’t get stuck if the printer drops the connection. This is exactly the kind of reliability you’d want for automation workflows.

6

A slightly more complex but more resilient solution is to host an MQTT broker, such as Mosquitto, and use it to allow clients to subscribe to topics.

I don’t mention it in the docs because I don’t want users to assume it is somehow related to the custom node. But it does work (I’ve tried it in my home setup), and is probably a more scalable solution for a setup with multiple consumers of the 3d printer’s data. :slight_smile: