Feedback welcome - Bambu Labs Printer Integration [P1S]

⚙️ Custom Apps and Drivers
, ,
21

@jc1 question for you - do you have your printer in lan only mode ?

I ask because it looks like there was a VERY recent Bambu firmware update that finally closed off all locally submitted command submissions to printers that are not in LAN mode. LAN mode is not something I'm wanting to activate as it just breaks too much stuff. I do wish the Bambu cloud wasn't required but just too much of the functionality I paid for doesn't work without it.

So the state the driver is in right now will read printer status very reliably. If I start a print or toggle the light on/off from an "approved" app, those state changes are reflected in Hubitat quickly and correctly. But executing commands like ledcontrol from Hubitat doesn't work. And that's by (their) design :cry:

22

I applied your latest changes, the light on/off commands are working fine for me? I'm not sure the P2S is limited to one connection either :person_shrugging: I seem to be able to use bambu studio, multiple instances, pausing and resuming and seeing the Hubitat state change immediately.

No I'm not using LAN Only, like you I want to keep remote connectivity.

I asked Claude yesterday why I can control the lights but not pause/resume/stop, it said:

Bambu's newer firmware specifically requires authentication for print control commands (pause/resume/stop) when the printer is in cloud-connected mode, but allows other commands like LED control without it.

If the printer has active cloud connectivity, Bambu's firmware verifies print control commands against the cloud even when they arrive over local MQTT. The fix in that case is one of:

  • Block the printer from internet access at your router (assign a firewall rule to the printer's IP) — forces pure local operation and disables the cloud verification check
  • Or add cloud credentials to the driver — the cloud MQTT uses u_{USER_ID} as the username and your access token as the password, so we'd need to add those as optional preferences and use them when present

But yeah not sure if it's correct on that last point or it's worth implementing. I myself am happy to receive the state, I don't want to control the printer from Hubitat.

23

Here's some debug logs of turning the light off:

dev:1692026-04-26 08:29:50.054 PM debug [BambuPrinter] System response: command=ledctrl, result=success
dev:1692026-04-26 08:29:50.053 PM debug [BambuPrinter] Payload: {"system":{"command":"ledctrl","interval_time":0,"led_mode":"off","led_node":"chamber_light","led_off_time":500,"led_on_time":500,"loop_times":0,"reason":"","result":"success","sequence_id":"30"}}
dev:1692026-04-26 08:29:50.052 PM debug [BambuPrinter] Message received on device/22E8BJ620200769/report
dev:1692026-04-26 08:29:50.012 PM info  [BambuPrinter] Publishing to device/22E8BJ620200769/request: {"system":{"sequence_id":"30","command":"ledctrl","led_node":"chamber_light","led_mode":"off","led_on_time":500,"led_off_time":500,"loop_times":0,"interval_time":0}}

And here's what I see when I try to pause:

dev:1692026-04-26 08:32:26.117 PM debug [BambuPrinter] Payload: {"print":{"command":"pause","err_code":84033543,"is_from_mqtt":true,"param":"","reason":"mqtt message verify failed","result":"failed","sequence_id":"34","user_id":"0"}}
dev:1692026-04-26 08:32:26.116 PM debug [BambuPrinter] Message received on device/22E8BJ620200769/report
dev:1692026-04-26 08:32:26.080 PM info  [BambuPrinter] Publishing to device/22E8BJ620200769/request: {"print":{"sequence_id":"34","command":"pause","param":"","user_id":"0"}}

I told Claude that you have problems with the lights, it thinks that there's a problem with the params in the lightOn and lightOff methods. Try making this change?

-            loop_times:    0,
-            interval_time: 0
+            loop_times:    1,
+            interval_time: 1000
24

Thanks for sharing - I got the same suggestions from Claude w/r/t shutting off external internet access, which isn't really a solution (and didn't work anyway)

What firmware are you running on the printer? I don't think it will be apples to apples number-wise with mine, since I have the P1S but mine is the latest version. And I know the light control was working when I first pushed this driver, and also that it has done a firmware update in the background since then. I could try reverting it to the prior version but thought I'd ask if you were on the latest first. The release notes for the firmware weren't 100% clear but it included some "local security fixes" that could have meant anything, including continuing to lock down functions like these.

I'm testing the change you suggested now all the same :slight_smile:

25

For what it's worth, that loop_time and interval_time setting were set to 0 in order to maintain a steady state and not "flash" the light. so that isn't it... still poking

26

Looks like the HomeAssistant plugin for Bambu printers actually routes everything through their cloud MQTT service rather than staying local. The LED control commands (anything in the system namespace in fact) seem to require that in later firmware versions. I'm really wondering how old yours is @jc1 since I don't doubt you when you say you have local LED control, I just can't figure out why it works for you. Anything past 1.07 seems to have the much stricter lockdowns applied.

I'm really not loving the idea of authenticating Hubitat to the Bambu cloud just for this one little thing. I could build it as an option, but...

27

Alright, for the sake of completeness I did implement cloud authentication.

Some notes:

  • If you use SSO (Apple, Google, Facebook) to sign in to your Bambu cloud account, you don't have a password and thus this won't work for you. You can convert your account to a standard username/password one, but I certainly don't expect folks to do that.
  • If you don't authenticate the driver to the Bambu cloud, the local read-only functions of the driver should still work. This polls printer status, job completion, etc. But it can not take any actions on the printer (LED control, print job start/stop/etc)
  • I haven't tested the cloud authentication thoroughly because I myself use SSO for Bambu. So feedback is very welcome on that.
  • The driver now makes it clear in the sidebar whether you are authenticated via local auth (Read-only) or cloud auth (enabling command and control). Since there's not a good way to actually disable the commands/buttons, you can at least be informed what to expect to work.
28

I'm using 01.02.00.00(Latest version).

I don't use SSO for anything if I can help it due to security concerns. I'll give your changes a test :slight_smile:

29

Yeah it's not working, and might not be able to work..

[BambuPrinter] Bambu cloud authentication failed — HTTP 200: check username and password

This fails because it's triggering 2FA email with a code.

I'm not sure how the home assistant plugin is handling that

30

Oh interesting. I don’t have 2FA enabled here because again I use SSO. Also not sure how that works for HA. Most cloud services give you a way to obtain a separate API token that is distinct from your console logins. If Bambu had that, the SSO and 2FA would both be a nonissue, but I don’t see any way to do that.

31

Yes they definitely don't offer that. I've worked around it using 2FA enabled on the account using a 2FA key, not via email.

With this I see that the cloud mqtt connects, and I can on/off the light but still can't pause/resume/stop

32

Interesting, OK. I wonder why. This cloud stuff may be more trouble than it's worth. I was looking at the PR and there are some conflicts I need to resolve so I didn't merge it yet

33

I spent the majority of yesterday working with claude to get the cloud based mqtt commands working. With each iteration the result is the same; the mqtt payload sent comes back with a error:

{
  {
  "print":
    "command": "pause",
    "err_code": 84033545,
    "is_from_mqtt": true,
    "param": "",
    "reason": "mqtt message verify failed",
    "result": "failed",
    "sequence_id": "2"
    }
}

Claude scraped the entire internet and thought it had made a discovery about x.509 certificates and adding some signing info to the payload, it also thought that there's some certs only available on each machine. I've got some uncommitted code from this endeavour but it still doesn't solve anything.

If I may suggest, I think the main branch of your project should revert to the local-only version we had, and keep the cloud login stuff on another branch. I do believe as a community we'll be able to solve the controlling problems, just not for the time being.

1 Like
34

Yeah, honestly I think you're right. Getting data reliably from the printer is more valuable than the commands. My core problem was controlling the stupid chamber light but they've made that very hard.

Still, this is valuable for other folks without that so let me see about keeping a working branch with the fancier config for another day and getting a simpler state in place for main/the common scenarios.

35

OK, it is done. The working-cloud-control branch preserves the history for future use, maybe, though I doubt it. main is now a nice, clean, read-only local implementation. Thanks for the testing and contributions!

1 Like
36

Great stuff. I just created a PR for you to refer to, for adding this to HPM

37

Oh, cool. You're right, I've never done that before. Will consider it!

38

I just discovered https://bambuddy.cool/ which is like a proxy for your printer. You can put the printer in LAN only mode, so all the driver features should work, yet you can still use the Bambu cloud stuff through this software. I'm giving it a trial.

39

That’s pretty dope. I’ll also test it out tonight