Yeah, to keep compatibility with both X1C and P1P then in my altered list I already have 2 nlist’s, one for root one for cache (X1C’s saved prints go to root, and sends to cache). Then it joins them. For the P1P compatibility all I will do is remove the “*.3mf” bit, then filter the joined lists.
Filenames will have /cache in front of them if they are in the cache hence why the fetch should still work. But I need to maintain compatibility for non /cache files. So that looks fine to me!
Hello,
I am sorry, i am kinda new to Bambu and dont know how integration with HA works. I can see that in order to connect HA to Bambu Lab printer you need to enter serial nr, LAN IP and access code. Unfortunately I dont have a printer at my home, but at parent’s house. I’ve managed to connect it to father’s HA, but i would like to connect it to mine HA. is this possible? so it would NOT be a LAN connection, but I would open some ports ( which ? ) to the printer and I would connect it via my HA.
I hope I’ve explained it well enough 
thanks for help!
Are you using the hacs integration or the nodered flow approach? If using the nodered flow approach then all you need to do is find a way to bridge/connect the MQTT broker in the second HA instance to yours, so you both have the same sensors.
As for the hacs approach, I’m not sure. I highly highly advise not to open any ports from the printer to the internet given how easy it is to mess with it then.
I might suggest looking around the internet for solutions for “sharing devices/entities between homeassistant instances” or similar, as it seems like there would likely be some solution out there for that, which could be generically applied to anything, not just the printer.
Hey there. I’ve been playing with the MQTT and Advanced Bed Leveling Node-Red flows for the past couple days – they’re fantastic! Thanks @WolfwithSword, greatly appreciate all of the work you’ve obviously put into this.
One thing I’m curious about – why is the set_bed_temp entity capped at 110? I changed the Node-Red function to use 120, and changed the max attribute of the HA entity to 120, and things work fine, but wondered if you were working around some other problem.
One thing I’m sad about – the ~0.7mm min-to-max variation in my print bed. Sad trombone…
Thanks! I capped it at that so as it prevent a user accidentally setting too high of a number. I thought 110 was the cap the printer was spec’d for so set it as that for safety, but yeah it can be changed. My thought process was mostly “if the user wants to risk it higher, they probably would do it from the printer itself, slicer, or app, rather than HA”. I could increase the cap to 120c if I was mistaken on the max spec from bambu though.
I did a similar cap to 300c for the nozzle I believe.
It’s 110°C using 220v power and 120°C using 120v power:
Ah strange, for some reason I thought it was 100/110 for 240/120 volt, respectively. I’ll up it for an updating large update/overhaul. Cleaning up the nodes and variables used, as well as prepping for potentially new firmware.
One more question – should I expect something reported in the “last calibrated PA” sensor? I haven’t seen anything there yet. It seems to go from “Unknown” to “Unavailable” (this is when the printer is off.)
Oh, now that I look a bit further back, I see it was reported once a few days ago. However… not since then, and I have run extrusion calibration a few times. (mostly to see if this value popped out.)
I sure hope this didn’t get nailed by the last firmware update…
I haven’t had time to test the new firmware update yet, probably not until the weekend. But for the PA calibration if it reports nothing or can’t come up with a value (too much or too little light, textured plated, silk or transparent or shiny filament etc) it won’t get a value.
Someone else has messaged me that their bed mesh calibration seems to not be working (something regarding credentials maybe but unsure until I try myself).
When I get a chance I will update and check - worst case scenario, they culled the short-misc messaged which I use to parse AMS humidity, PA value, and bed mesh data. So if all 3 of those stop updated together then we got an issue 
I’ve also noticed if the calibrated value matches what is currently set for the filament, it won’t always send it either.
So I haven’t yet updated my firmware, however I’m receiving enough reports that the mc_print messages (containing data used for AMS Humidity %, PA Calibration value, and Bed Mesh data, among other unused messages) is no longer being sent on latest firmware. So to use these, may need to rollback.
I’ll try looking into it this weekend to see if anything can be done, or what I might end up doing is setting certain sensors to be disabled for specific incompatible firmware releases. I’m unsure at the moment.
Hey Guys can you help me ? Actually trying to connect to my Bambulab printer with MQTT But its says: Connecting
Think I’ve responded to you on discord already but just in case others come into this thread for similar issues, it was just due to outdated information (current requires 8883 port and auth/credentials for example).
So I’m using the HACs integration. There were quite a few changes from the yaml files I downloaded from @WolfwithSword (awesome site by the way). But I’ve mostly got things going. However, on my printer control yaml…the power, start, pause cancel icons aren’t there/working. I’m not getting any errors, so I’m not sure where to go from here. Any suggestions. Attached is a picture as well as the full yaml.
type: vertical-stack
view_layout:
column: 3
cards:
- type: horizontal-stack
cards:
- type: custom:button-card
show_name: false
show_icon: true
tap_action:
action: toggle
entity: switch.bambu_printer
icon: mdi:printer-3d
state:
- value: 'on'
icon: mdi:power
color: green
- value: 'off'
icon: mdi:power
color: grey
aspect_ratio: 2
style: |
ha-card {
box-shadow: none !important;
background: rgba(0,0,0,0);
border: none;
}
- type: custom:mushroom-title-card
title: RodelaClan 3d Printer
alignment: center
- type: custom:gap-card
- type: custom:gap-card
height: 25
- type: custom:hui-element
card_type: horizontal-stack
cards:
- type: custom:hui-element
card_type: button
entity: select.x1c_00m00a282501551_printing_speed
name: Silent
icon: mdi:speedometer-slow
tap_action:
action: call-service
service: select.select_option
data:
option: Silent
target:
entity_id: select.x1c_00m00a282501551_printing_speed
style: |
ha-card {
box-shadow: none !important;
background-color: rgba(0,0,0,0);
border: none;
--pbs-button-color: {% if is_state('select.x1c_00m00a282501551_printing_speed', 'Silent') %} yellow; {% else %} grey; {% endif %}
--paper-item-icon-color: {% if is_state('select.x1c_00m00a282501551_printing_speed', 'Silent') %} yellow; {% else %} grey; {% endif %}
}
- type: custom:hui-element
card_type: button
entity: select.x1c_00m00a282501551_printing_speed
name: Standard
icon: mdi:speedometer-medium
tap_action:
action: call-service
service: select.select_option
data:
option: Standard
target:
entity_id: select.x1c_00m00a282501551_printing_speed
style: |
ha-card {
box-shadow: none !important;
background-color: rgba(0,0,0,0);
border: none;
--paper-item-icon-color: {% if is_state('select.x1c_00m00a282501551_printing_speed', 'Standard') %} yellow; {% else %} grey; {% endif %}
}
- type: custom:hui-element
card_type: button
entity: select.x1c_00m00a282501551_printing_speed
name: Sport
icon: mdi:speedometer
tap_action:
action: call-service
service: select.select_option
data:
option: Sport
target:
entity_id: select.x1c_00m00a282501551_printing_speed
style: |
ha-card {
box-shadow: none !important;
background-color: rgba(0,0,0,0);
border: none;
--paper-item-icon-color: {% if is_state('select.x1c_00m00a282501551_printing_speed', 'Sport') %} yellow; {% else %} grey; {% endif %}
}
- type: custom:hui-element
card_type: button
entity: select.x1c_00m00a282501551_printing_speed
name: Ludicrous
icon: mdi:speedometer
tap_action:
action: call-service
service: select.select_option
data:
option: Ludicrous
target:
entity_id: select.x1c_00m00a282501551_printing_speed
style: |
ha-card {
box-shadow: none !important;
background-color: rgba(0,0,0,0);
border: none;
--paper-item-icon-color: {% if is_state('select.x1c_00m00a282501551_printing_speed', 'Ludicrous') %} yellow; {% else %} grey; {% endif %}
}
- type: custom:gap-card
height: 25
- type: custom:hui-element
card_type: horizontal-stack
cards:
- type: custom:button-card
variables:
pause_entity: button.x1c_00m00a282501551_pause_printing
start_entity: button.x1c_00m00a282501551_resume_printing
entity: sensor.x1c_00m00a282501551_print_status
name: |
[[[ if (entity.state == 'RUNNING') return "Pause";
else if (entity.state =='PAUSE') return "Resume";
else return ''; ]]]
state:
- value: RUNNING
icon: mdi:pause
color: orange
- value: PAUSE
icon: mdi:play
color: orange
- value: OFFLINE
icon: mdi:void
color: grey
- value: IDLE
icon: mdi:void
color: grey
- value: FAILED
icon: mdi:void
color: grey
- value: FINISH
icon: mdi:void
color: grey
tap_action:
action: >
[[[ if (entity.state == 'RUNNING' || entity.state == 'PAUSE') return
"call-service";
else return "none";
]]]
service: button.press
service_data:
entity_id: >
[[[ if (states['sensor.x1c_00m00a282501551_print_status'].state ==
'RUNNING')
return variables.pause_entity;
if (states['sensor.x1c_00m00a282501551_print_status'].state == 'PAUSE')
return variables.start_entity;
else return "";
]]]
style: |
ha-card {
box-shadow: none !important;
background-color: rgba(0,0,0,0);
border: none;
--paper-item-icon-color: {% if is_state('sensor.x1c_00m00a282501551_print_status', 'RUNNING') or is_state('sensor.x1c_00m00a282501551_print_status', 'PAUSE') %} orange; {% else %} grey; {% endif %}
}
- type: custom:gap-card
- type: custom:button-card
entity: sensor.x1c_00m00a282501551_print_status
name: |
[[[ if (entity.state == 'RUNNING') return "Cancel";
else if (entity.state =='PAUSE') return "Cancel";
else return ''; ]]]
confirmation:
text: Cancel Print?
state:
- value: RUNNING
icon: mdi:cancel
color: red
- value: PAUSE
icon: mdi:cancel
color: red
- value: OFFLINE
icon: mdi:void
color: grey
- value: IDLE
icon: mdi:void
color: grey
- value: FAILED
icon: mdi:void
color: grey
- value: FINISH
icon: mdi:void
color: grey
tap_action:
action: >
[[[ if (entity.state == 'RUNNING' || entity.state == 'PAUSE') return
"call-service"; else return "none"; ]]]
service: button.press
service_data:
entity_id: button.x1c_00m00a282501551_stop_printing
style: |
ha-card {
box-shadow: none !important;
background-color: rgba(0,0,0,0);
border: none;
--paper-item-icon-color: {% if is_state('sensor.x1c_00m00a282501551_print_status', 'RUNNING') or is_state('sensor.x1c_00m00a282501551_print_status', 'PAUSE') %} red; {% else %} grey; {% endif %}
}
- type: custom:mushroom-title-card
title: ''
subtitle: Print Details
alignment: center
- type: horizontal-stack
cards:
- type: custom:mushroom-entity-card
entity: sensor.x1c_00m00a282501551_print_status
name: Details
- type: custom:mushroom-entity-card
entity: sensor.x1c_00m00a282501551_print_progress
name: Progress
- type: custom:mushroom-template-card
primary: Layer
icon_color: var(--rgb-state-entity)
secondary: >-
{{states('sensor.x1c_00m00a282501551_current_layer')}} /
{{states('sensor.x1c_00m00a282501551_total_layer_count')}}
icon: mdi:layers
- type: vertical-stack
cards:
- type: entities
entities:
- entity: sensor.x1c_00m00a282501551_current_stage
name: Stage
- entity: binary_sensor.x1c_00m00a282501551_hms_errors
name: HMS Errors
- entity: sensor.x1c_00m00a282501551_start_time
name: Start Time
attribute: start_time
- entity: sensor.x1c_00m00a282501551_end_time
name: End Time
attribute: end_time
- entity: sensor.x1c_00m00a282501551_remaining_time
name: Remaining Time
The power button is controlled via the “switch.bambu_printer” entity which is not on the printer, and you need a dedicated smart plug integrated into homeassistant for that (just rename all instances of switch.bambu_printer to switch.<your_plug>)
Start/Pause/Cancel will only be active during a print. As far as I remember, the HACS integration differs from my nodered/mqtt integration when it comes to control options and states. The states for FINISH FAILED RUNNING and IDLE are not the same. You can see in the yaml some rudimentary code that is based off comparing these state values. You can see easily that “FAILED” is actually “Failed” in the HACS integration, so you’d need to change the states appropriately to what is there.
For example
name: |
[[[ if (entity.state == 'RUNNING') return "Pause";
else if (entity.state =='PAUSE') return "Resume";
else return ''; ]]]
state:
- value: RUNNING
icon: mdi:pause
color: orange
- value: PAUSE
icon: mdi:play
color: orange
- value: OFFLINE
icon: mdi:void
color: grey
- value: IDLE
icon: mdi:void
color: grey
- value: FAILED
icon: mdi:void
color: grey
- value: FINISH
icon: mdi:void
color: grey
tap_action:
action: >
[[[ if (entity.state == 'RUNNING' || entity.state == 'PAUSE') return
"call-service";
else return "none";
]]]
Would need “RUNNING”, “PAUSE”, “FINISH”, “FAILED”, “IDLE”, “OFFLINE” changed. Though the HACs integration if I remember correctly turns “FINISH” into “IDLE”, and may not have “OFFLINE” (before they transform it, like they did “FAILED” to “Failed”).
Additionally I don’t know if your speed control will work, since I’m not sure if the HACS integration integrated it as a select sensor or not, been a while since I last worked on it and had a local build running. I would expect if it were working and had it, one of them should be highlighted as it’s supposed to compare the select state to highlight the active speed.
Thank you sir. You put me on the right path. So, I forgot your documentation stated the need to add the external switch. I have one around here somewhere. I can deal with that.
Is there a (easy) way for me to see all the “states” available for an entity? I thought creating an automation with the trigger being a state of an entity the “from” and “to” would list all the states. But when I put in my “print status” entity, it only lists “unavailable” and “unknown”, but the current state in developer tools is “failed”…so I’m confused. I intended to make the states match the integration, but can’t verify what states are available.
Lastly, speed control. The select_printing_speed sensor is indeed there, and it appears that “silent” “sport” ludicrous" and “standard” are all there. I did notice that those options are “attributes” and not states under the entity. Would I need to change them to sensors via a template sensor?
I may be in over my head. I chose to go the HACs route because I haven’t taken the dive into Node Red and it seemed intimidating, so I opted for the “easier” route…Like I said, maybe I’m over my head. Thank you for the time in trying to help me. I’ll keep chipping away at it.
No problem! For the speed sensor you can either make a template sensor or adjust the yaml code to compare the attribute instead of the state (a bit trickier but do-able). Though I’m not sure that’s necessary as you should be able to get a “current state” from a select entity, and the attributes are likely just options. Though since it didn’t highlight I suppose that it isn’t working. Maybe the current speed profile is stored as a different entity? If so you can swap to that.
For the list of all states for that I took a look into the repo and it seems they just Title-case the state, so all possible values are: Offline, Idle, Running, Failed, Pause, and Prepare (but this one is only for a few ms or a second when you are uploading a print to start).
I am a Bambu Beta Tester and since last firmware update (beta 1.05.06.19) hole Node Red/ MQTT seams to be no longer working. Any idea or experiance with the new beta firmware?
I was wondering when this would happen. I think that there has been a lot of talk around network security and Bambu have locked down a lot of the functionality because of this. I remember seeing an announcement from them recently somewhere that they have listened to the security concerns and locked things down.
The security bit was much earlier in the year and it was just to add authentication to FTP and MQTT really. Something that was asked for. As for any beta-related things, they should not be shared of course, if I recall that’s part of the beta agreement (I’m not in the beta), so the most I know about it is from snooping around bambu studio’s git code to see what was added.
The most I can say though is the new beta firmware hasn’t broken for others I know using the beta firmware, and for this case it was just me asking if they had a newer version of my flows which fixed a few logic issues from a long time ago.
So flows still work just fine, but I am planning when this releases to spend a bit of time going over it since I am planning some relatively big updates to it all.
Oh this is great to hear!