Are the spools in the background actually color matched to the filament? I.e. white/green/blue/red or is it only the foreground icon that is the filament color. I.e. yellow/red/black?/yellow. I think it’s the latter? It would be awesome to colorize the spools instead though.
Awesome. I will grab this since I am not the most artistic of people so pretty dashboards are not my thing 
1 Like
Pretty sure it’s just foreground icon, as it’s using my yaml as a base for this (as seen here), just Cryd’s modified version which used the colourized ams background - for my AMS background I made it black & white for this reason, since it’s near impossible to really make that colourize 
Also for the code for determining the tray stuff, here is the pseudocode from my nodered code:
for each AMS
for each Tray
tray_cumulative_id = tray_id + (4 * ams_id)
Where the “cumulative id” is the realistic id for multi-ams, and is used for tray_now checking.
Then if this matches the ams.tray_now (note: this is not on an individual AMS, but is in the wrapper object that also holds all AMS’s in an array), you know that tray is currently in use. For me, I set a boolean then to my “tray” object for “in_use” to true/false.
P1P also has vt_tray in the main json (not in AMS) which is a virtual tray for the external spool, unfortunately the X1 series doesn’t have this exposed as a value. But it behaves just like the other trays except its ID is something wacky (but is a single digit off of the default value when no tray is in use at all, so I recommend matching tray_now to its id to verify if it’s in use rather than state checking).
Starting to take shape. My column pixel width is smaller so the whole thing is being scaled down a little and the boxes around the pause/resume/stop buttons end overlapping and I haven’t worked out how to fix that yet. But it’s nice to have something other than a big long list of raw sensors to look at 
Looks like you didn’t use styles in those cards with boxes. I’m using card-mod to make it work “properly” without boxes.
Thanks for the tip. I’m new to making attractive dashboards. Mine have been very… functional so far
Switched from your card-mod markup to:
‘–ha-card-border-width’: 0px
And that’s working for all the top buttons - but not for the 4 status areas at the bottom oddly.
i found out the hard way that not all errors create HMS errors. I’m starting to get filament feed issues and have seen two errors; one for feeding inside the AMS and one for the toolhead. Neither error created HMS errors, nor changed print status nor changed print stage, and thus I never got notifications.
so i added the below to notify me if the print time remaining doesn’t change after a few minutes.
alias: X1 Print Time Remaining Monitor
description: if print time doesn't change, something is wrong
trigger:
- platform: template
value_template: >-
{{ as_timestamp(now()) | round -
as_timestamp(states.sensor.x1c_x1_carbon_print_remaining_time.last_changed)
| round > 180 }}
alias: Print Time Remaining Unchanged
condition:
- condition: or
conditions:
- condition: state
entity_id: sensor.x1c_x1_carbon_print_status
state: RUNNING
- condition: state
entity_id: sensor.x1c_x1_carbon_stage
state: Printing
action: ...
it is designed to catch this print job, which failed twice:
let me know if there’s a better way to handle this. hopefully this helps someone. i could not own a Bambu printer without this automation thread. Thanks again!
1 Like
That’s a good idea, especially checking that it must be in a RUNNING state for that. It’s weird currently since not all errors are HMS, or trigger HMS, yet sometimes the HMS is also used for non-error messages. Wish it were more consistent!.
Though I’m surprised the printer didn’t turn pause during then, as that’s the behaviour I’ve seen come out of it during weird errors where the HMS wasn’t triggered. Then again, two out of probably 25 times now I’ve had it “pause” but be stuck in a loop still on running for about 10m before it finally “paused” so I could hit resume. Think that part is a bug currently.
one error started with 0700 8006 and that 8000 range doesn’t seem to be covered by HMS.
i bumped the 180 time higher since my filament purges can exceed that!
i removed the OR condition and just used Print Stage. the Print Status can be RUNNING while the Stage is auto bed leveling or heating or cleaning nozzle. i think just Print Stage: Printing is good enough.
at 4:09AM, i got an HMS error notification that woke me up (not shown in the screenshot). i also got the print time remaining notification (bottom). print status and stage shows running and printing.
at 4:10am, i got notified (middle) of HMS error beause i took the toolhead front cover off (the filament was stuck inside the extruder). this error caused the print status to PAUSE which triggered another notification (top). print stage is still Printing.
i think i have all bases covered now.
this print was troublesome (first time). i’ve been printing Pokemon non-stop for my daughter’s birthday party. i just kicked off a simple Charmander print, and it uses all 8 slots of my AMS.
1 Like
@WolfwithSword I could do with some pointers since I’m hitting a brick wall on the dashboard css stuff. I’m trying to get the icon colorization working for my AMS and I’m using your gist for inspiration since my sensors are different with the HACS integration. I will need to work out the best way to expose the color (presumably as a state attribute per your gist vs a dedicated sensor value), but I’m not even to that point - I can’t get even a hardcoded style variable definition to work. This is where I’m at and I’ve tried a bunch of different tweaks to how the tray color is specified to no avail. And I’ve drawn a blank on internet searchs. Do I need card-mod for this to work? That’s not currently possible to install unless you opt into a beta build of Home Assistant. Which potentially suggests yet another breakin change to HA is coming?
type: custom:vertical-stack-in-card
cards:
- type: horizontal-stack
cards:
- type: picture-elements
title: null
image: /local/images/devices/AMS.png
style: |
ha-card {
--tray_1_color: rgb(255,0,0)
}
elements:
- type: custom:config-template-card
entities:
- sensor.p1p_<SERIAL>_ams_1_tray_1_color
element:
type: state-icon
entity: sensor.p1p_<SERIAL>_ams_1_tray_1_color
icon: mdi:tray
style:
top: 30%
left: 22%
'--paper-item-icon-color': var(--tray_1_color)
text-align: center
font-size: 1em
background-color: rgba(0,0,0,0.4)
box-shadow: 0 0 5px 5px rgba(0, 0, 0, 0.4)
border-radius: 50px
pointer-events: none
Wait, why can’t you install card-mod? It’s definitely needed for it to work (and in my gist/guide on my website, a few other HACs repos too). Should just be able to add it from HACS? I haven’t heard of breaking changes for that recently.
Oh weird. 3.2.1 & 3.2.2 requires 2023.4.0b5 :
And I thought that was true all the way back to the oldest available (3.1.4) but re-trying now I see that 3.2.0 and older are fine without a beta build of HA. Ok unblocked on getting that installed now, which will help.
Yep, working as-is with cardmod installed. One thing I’ve been struggling to understand is where normal css control ends and cardmod is needed. This was clearly one of those cases.
Now to work out how I expose state attributes for the AMS colors.
1 Like
Yeah just noticed looking now at its github there were some issues, I must have just randomly avoided it, or maybe it as HassOS specific, not sure.
And yep, even I have hard time following my own gists I had tried at least 20 different ways to do just even that one icon colouring part via attribute before I got a solution that also worked with changing icons based on a value/state.
Right now I just have everything exposed as a flat list of sensors. Part of the reason for creating a nice dashboard view for this (other than because I want it) is to work out if and how that doesn’t work for dashboard creation.
Similar methodology I did with the first versions of the nodered stuff. Didn’t like the fact that a tray can have multiple values itself and there were multiple trays, so I went with attributes for it. While they were slightly harder to work with in yaml for dashboards, I knew it was still doable. Same for automations and such. So I went with selecting what was best to have as a standalone sensor vs what could be grouped I.E. an attribute on a tray, trays on an AMS, then “link” the AMS to the printer.
Right now I just have the AMS ‘linked’ to the printer via naming convention in that I use the printer serial in the unique name for an AMS instead of the AMS serial. But I have been wondering if there’s a better way.
I haven’t yet worked of I can even use a sensor string value as the input to a card-mod style modification. Where I can see that attributes will work from your approach.
Edit:
This works:
–tray_1_color: {{ states[‘sensor.p1p_SERIAL_ams_1_tray_1_color’].state }};
(as long as you add the semi-colon before adding more colors…
There is a way to setup connected devices as well, or at least I know I can via mqtt metadata, so there must be a way via the actual integration.
1 Like
Ok, back up and running with everything converted to attributes of generic tray sensors. Need to work out how I’ve created undeletable orphaned sensors in my production HA instance though.
Adding the connected device was simple enough once I located the documentation and then searched the home assistant repo to find actual usage since the HA documentation is always close to useless but it got me the search term at least this time.
1 Like
@WolfwithSword in you gist you have variables:
Is that an actual variable or is it just a place holder for folk to find and replace with their own sensor names?