Bambu Lab X1 X1C MQTT

Yeah in the guide I mention it in the required HACS repos, but that installation step for the config yaml is easy to miss :laughing: When I get a chance I’ll make it more clear.

Also noticing you are missing colouring of the svg’s and the blur around the circle… I think you may be missing more of the required HACs repos; card-mod, config-template-card or custom-ui, one of those.

EDIT: Updated guide to make the fontawesome step more clear + I updated the yaml’s to have the “color: #FFFFFF” for all state-labels in AMS and the X1C/P1P yamls.

EDIT 2: Just adding the list of hacs requirements here so it might be easier to check.

1 Like

Just noticed they updated X1C firmware today with a number of really good changes, such as support for setting info on the external spool holder filament (I will make a new yaml for this rather than shove it in with the existing X1C/P1P image dashboard yaml, so it is less cluttered).

This virtual spool may already work as of today if it uses the same MQTT implementation as the P1P’s VT_Tray. The only downside would be you can’t really detect if it’s been removed/emptied. Only once set on the printer/bambu studio, it will always show it and then whether or not it is in use. I might dig around to find if their “reset” command is useable to clear the vt_tray and in a custom yaml will add a button to clear it. I probably won’t do this for AMS trays since that is rather automatic.

Regarding the firmware downgrading, it is possible my flows may work anywhere between 80 and 100% for the available versions, but I cannot guarantee it. Either it’ll all work or a couple sensors won’t show up or have errors is the likely scenario with older firmwares.

MC board fan is off until the tool head is moved. It will then turn on to cool the MC board components. When the print concludes and the printer goes to power save mode, the MC board fan will again turn off. → I need to look into this ASAP :laughing: if the MC Board fan is controllable and monitorable.

I’ll be updating later and should begin working on updates later this week or next week :slight_smile:

Edit: Good news

It is implemented as VT_Tray so it will show up with current stuff! I will do some renaming of the name but not sensor name later likely, but I will also make the yaml for it.

There are also some new values I need to investigate. “queue_number” number and “filam_bak” array. If anyone has some ideas, let me know!

Also “Aux Part Fan” is true/false value, with a % currently. This is not the auxilliary fan but I believe it’s the MC Board fan which now toggles on/off by the printer automatically. I will rename it in an update and fix the unit/type. This is not the MC board fan, but it is a sensor on whether or not the aux fan is installed. I will have it renamed accordingly.

nozzle_diameter is present! But defaults to 0.4 and does not detect if you have anything else. Will need to manually change on printer.

Updated my flows for the new update!

  • Basic implementation: Renamed a few of the new sensors (External Spool) and removed some useless ones

  • Advanced Implementation: Added plate bed type fetching from 3mf file (had this in the works before surprise firmware drop). Now you can get what plate type is configured for the print you are currently printing!

  • Dashboard YAMLS:

    • Did a few css tweaks to make it cleaner if you have different themes
    • Made a new yaml for the External Spool (bottom left of image)

All pages/guides on my site are updated automatically and have an indicator at the top of each page for when it was last update.

Edit: Did a quick second update to the main flow and made a reset / clear button for the external spool settings. I might investigate a way down the road to make a configurator UI for it to set its filament params but we’ll see.

Edit 2: Another quick update - now I can get the calculated PA value from LIDAR calibration as a sensor (expires after 24 hours, resets timer on refresh of value or change of value). Only needs the basic flow. ---- Took out the expirey thing in another update because it was working fine then all of a sudden didn’t work at all. MQTT Expiry stuff is always finnicky, so I took it out. Value will stay until updated.

1 Like

Just wanted to drop a note to say thanks to everyone that contributed to digging up the MQTT information. My primary home automation hub is Hubitat, but I was able to use the information here to write up a device driver for it to bring in the printer’s sensor data.

EDIT: I forgot to mention. I was having a heck of a time getting the unload sequence to run by using the gcode provided here and the gcode provided by BL in one of their GitHub repos. I don’t have an AMS and it sounded like the gcode wasn’t actuating the filament cutter. I ended up stumbling on the request command used by Bambu Studio to execute the filament unload. Turns out, it’s a file called on the printer. I suppose the upshot is that if they decide to change the sequence in a firmware update, you won’t need to update the gcode manually (until they change the file name of course).

{"print":{"sequence_id":"2027","command":"gcode_file","param":"/usr/etc/print/filament_unload.gcode"},"user_id":"1234567890"}
1 Like

I wanted to check to see if this “integration” is still working after the 1.05.1 firmware update. The HA integration does not seem to be working (at least for me and a few others).

I just went through this NR/MQTT setup and I’m not able to connect to the mqtt broker. Do I need to be in LAN only mode?

Shouldn’t need to be in LAN mode for the NR/MQTT setup - do you have a P1P or X1(C)?

You can try connecting to the printer broker via MQTT Explorer first to debug connection details (right IP, user/pass, and did you use the right serial number etc).

Edit: So Bambu changed how the cloud mqtt works, so the workaround for that is currently a no-go but you can still use LAN MQTT while in cloud mode, so as long as in my nodered flow you’re on the latest firmware it should’ve used LAN MQTT.

I think I may have an idea for how I can “kind of” get this with my home assistant stuff (well not fully, I’m thinking to have NodeRed save it to a file, that you then open and paste in a plotter. Matrix would be too big to send in mqtt or homeassistant and can’t generate a plot in nodered for an image or download a file via HA etc, super annoying).

Do you know if there’s a particular mc_print message indicating the start and finish of bed levelling? Also curious to know if the X/Y coordinates are always consistent or if they may sometimes vary, which I doubt. Though I can’t really rely on them as you never know, Bambu may end up supporting smaller bed levelling for just print region.

Nevermind - just realized I can watch the stage sensor to determine start and end of a ABL.

So good news, I have created a new additional NodeRed → HomeAssistant flow that can help give you the Auto Bed Levelling mesh data. It’s a bit tricky as I cannot actually send the data to homeassistant due to the size, so instead it will either post it to paste bin or if the api is exceeded for a token you make, it also always pushes it to mqtt for you to copy. For visualizing, I have created a new page on my site to provide the visualization once you paste in the Z values.

Managed to get it to calibrate my bed to be nearly perfect. In fact, I think I am within the printer’s margin of error of between 0.02 and 0.04 as some points change by these amounts on there own after some time.

And an advanced version using postgres to store all bed mesh history and Grafana to visualize and compare them!

1 Like

Awesome ! Thanks for the implementation

Is there some way I can sniff traffic coming from the desktop and/or to the printer to uncover how the chamber fan speed is set? I’d like to be able to control it remotely so that I can modulate the chamber temperature.

What card are you using to set temps?

@krellboy The chamber fan is controlled via the MQTT request for sending a gcode line.

@madbuda I’m using a mushroom-number-card

bed mesh - amazing! great work! i only fear this sort of data will cause bambu to block this project

1 Like

Thanks! I doubt they would block it, it’s been discussed pretty well in the discord, seemingly as long as we aren’t doing anything about reverse engineering or firmware shenanigans we should be fine. After all, I’m sure after market bed mesh things exist and could get similar results, so this is more of a guiding thing!

@WolfwithSword Thanks, does this mean you can universally just inject random G code from MQTT during the middle of a print and it will process it?

Yep, I guess so! I’ve only tested with temp changes, fan and light control mostly, but I guess yeah any arbitrary gcode can be stringed together there.

I looked again into the mqtt output during flow calibration after someone talked about it on reddit and I found these payloads in the mc_print messages:

[BMC] M980.3:total section received:668
[BMC] Vd=[-1.524,0.172,1.810] 
[BMC] M980.3:linear_k=0.0179, M=0.00009
[BMC] M900 K0.0179, L1.00000, M0.00011
[BMC] erc para:0.01794,1.00000,0.00011 

I compared with a flow calibration in Orca for the PLA and PETG I have in the AMS, and the values seem good. Also I had to use the Bambu plates: I don’t get the messages with my smooth PEI, which probably means it silently failed?

Yeah I currently use the second last one there for K value to get the calibrated amount. If it doesn’t fire it is a silent fail. I’ve had good luck with my energetic plate on it, except recently it refused to do it with my CosPLA Version A.

If it doesn’t fire then the sensor in my nodered integration will stay as “Unknown”, but otherwise if it successfully calibrated it will provide that K value, so 0.0179.

LOL, how come I haven’t seen the sensor is already here :slight_smile:
Thanks!

1 Like

Todays firmware update for P1P brings layer counting feature and support for remote liveview through cloud. Maybe capturing liveview from camera will be now achievable.

1 Like