I wanted a way to automate turning the chamber light on and off on my Bambu P1S when prints start and stop. Having the light on all the time was attracting bugs, which was making a mess around the printer. I noticed there was a nice integration for HomeAssistant but the one that was created years ago for Hubitat was no longer maintained.
That led me down the rabbit hole of creating a whole driver and app which interfaces with the printer via MQTT, reads a whole host of parameters, and allows setting a handful which are exposed by the Bambu API.
The driver requires the printer's IP, serial number and LAN access code to work. Once you load the driver and. create the device, you can install the app which allows for messaging automation, switch/device control, and natively provides you the ability to enable/disable the chamber light when a print starts or stops. That's really what I wanted in the first place!
Made a whole mess of updates to this. I discovered some issues with error handling, implemented exponential retries in the event copies of Studio or Handy are blocking direct MQTT calls to the printer, and fixed up a few things that were blocking commands from running properly.
Also, the chamber light now shows up as a child device which you can control directly through a voice assistant/homebridge/dashboard/automations/whatever.
Be sure to pull the current version if you want to give this a try!
Here are some images of what you can expect to see in the driver and app
Unfortunately, I'm not having any luck with this one. Everything installs fine, and I can control and see the status of the chamber light, so I know the connection is there. But it always lists the print status as unknown.
I should note, I do have this printer set up on Home Assistant, and working perfectly in Hubitat via HADB, but I was hoping to avoid the 2-hop with your thing here. It occurred to me that Home Assistant could be causing MQQT connection issues, but disabling that integration has no effect.
Hey bud! Thanks for trying it out. I guess I have some work to do. I am actually seeing the same thing, now, and IDK why. It worked at first! I may have broken something. I'll mess with it a bit more, appreciate the feedback.
It looks like the issue here is a bug (or design decision that is incompatible with what I'm trying to do) in the Hubitat MQTT client.
I hypothesize that the bug is in Hubitat's java SSL/TLS MQTT implementation, and that it establishes a TLS handshake to the printer successfully but silently drops all incoming data.
When I try to connect to the printer manually using python and paho-mqtt it works properly.
@rickyturner do you have an external mosquitto instance running anywhere by chance? I hate this solution but I think we can route the messages through an intermediary and get better results. But I really don't want to have to do that, it's complex and fragile.
I wonder who we can tag to bubble up the bug/question?
Great work picking this up! I've got a P2S and I plan on trying this tonight. I do have a external MQTT server though I don't use it for anything at the moment.
My use case is purely to control other devices based on the Printer Status.
I don't, sorry. I tried a few things out on my Home Assistant version, and refreshed everything on both ends, and it seems like you're onto something. --HA works fine, and on Hubitat logs, it says it's connecting with the MQTT and all is well--it just doesn't report.
I love the simplicity of this implementation, so I'll keep an eye on the thread. Happy to test any new versions. Thanks!
I pushed some updates to the driver but as yet, it hasn't worked around the bug in the MQTT client. I can confirm the calls I'm making should work, and the printer is listening/responding to them, but the way Hubitat implements SSL is causing the connection to silently fail (it looks like it connected but isn't)
@marktheknife I saw you liked this and IIRC you've been really helpful to me in other threads too! Any chance you know who to tag in for a hand on the MQTT client concern?
This is one for @gopher.ny, but if you aren't on the current platform beta, there are some changes you might want to test first. I don't know if anything with the built-in broker itself was changed, though, and that seems like your guess as to where the issue lies...
Thanks! I’m not in any platform betas - just running the latest released build. I would be open to working with someone to get logs or troubleshooting info over to you folks if it would help make things better in an upcoming release though. I’m hitting a wall as far as what I can see inside the Hubitat black box right now. I know my device works and responds, I know my calls are correct, but my python shim can execute them and the Hubitat client can’t. Any further troubleshooting and I’d need some guidance!
Super cool! Lots of exciting stuff in that release, including several named improvements to MQTT functions. However, I upgraded just now and the behavior is still the same. It looks like the SSL connection to the device is silently failing.
I use a modified version of another BambuLab driver from Ryan Elliott and I remember that they had a one time ssl setup step. I don't remember what it was but clever searching would reveal it. Also some Bambulab printers, like the A1 can only handle one incoming mqtt (like the slicer or hubitat but not both).
I've been using Claude to review the driver and fix this problem. Good news, it has fixed it. I can connect directly to my P2S and through a relay as well.
Oh, hey cool. I’ll check it out. Thanks for linking the PR too, I get so many of them this landed in the bitbucket. Can’t wait to see how it addressed the issue tbh
I merged this as it seems well written. It fixed some of the issues but created some new ones, which is pretty normal I am getting MQTT responses now, the same ones I was getting manually via paho which is v promising.
There's an unexpected end of array error when parsing them, which is probably easily fixed with some error handling when the stream closes. But I have lost control of the chamber light somewhere in this process - need to troubleshoot that
I was able to correct the end of stream error pretty quickly and that's live in main now.
Still working on the light control. I've noticed that yes, indeed, now that I have a solid persistent connection to the MQTT server on the printer it limits you quite strictly to one connection at a time. I don't know if there's ever going to be a way to work around that one - and it will definitely cause problems when you're actively working on prints since Studio/Handy consume that 1 available connection.
At a minimum, Hubitat will have trouble getting status updates while those apps are open. In a worst case scenario, Hubitat could disrupt the function of those apps during a critical time (sending a print job), though I'm not sure if that's possible/likely or not.
Probably worth retrying.
