"I originally had this compiling the printable objects into a Todo List sensor. The user could click the todos as "completed" and that would cancel them."

We're looking into how to combine the existing ha-bambulab-cards repo into this one so that this integration installs its own cards. That's all looking promising. I'd then want to try and build a card for this that has the more complex visual UI and hopefully can trigger the service call itself. But all of that's new to me so even assuming we don't hit blockers I expect it'll take a while to build that.

What did the todo list experience look like?

What did the todo list experience look like?

Honestly, not great — in it's most basic form. There's no way to customise the active / completed state labels, and you can't add a confirmation before an item is marked as completed.

So for the model in the PR example, ticking "[416] ..." would immediately send the skip command, and render as:

A more advanced option might be to combine it with @ichisaur's suggestion, whereby checking an object as "completed" would flag it as "ready to skip" and re-generate the pick image with the flagged objects highlighted. We'd have a separate button entity that'd use the flagged objects and send the command. I'm just not sure how intuitive an experience it is.

Just an idea could we use text labels? So in Orca Slicer each object is named and you check the names you want against a checklist and hit an "Exclude" cta? May be an easier V1 and I can add it to the printwatch card pretty easily?

No, object names aren't unique and that implementation would still require some confirmation step for checking which object is selected.

For what it's worth, the current BBL Handy app implementation has I believe both a touch UI for selecting the object directly, as well as a check list with objects names. The check list highlights the objects as red before you click the cancel button to confirm. I think that's very similar to the approach I described. The only issue with HA is making sure users are aware of needing to hit a confirm button.

Maybe calling the preview,select list, and cancel button: Selection Preview, Select Object, and Cancel Selected Objects could help users work out the process?

I don't know if it's possible to add dashboard components with an add on, but a prebuilt vertical stack with the image, check list, and confirm button would also help.

Did this real quick as example?

Did this real quick as example?

Yeah the problem is you can have 64 objects named cube and not know which one you need to cancel.

Cube_1, cube_2 etc is also not very helpful without a visual reference since the default orca plater does not organize parts in any logical order.

The idea behind this PR was purely to provide the data. I think for something interactive like this, where the action of cancelling an object involves several entities having to work together (reference image, list of selected objects, button) we really need a separate card feeding off the data the integration provides.

Just an idea could we use text labels?

The IDs and object names are in the Printable Objects sensor's attributes, so in the printwatch card, loop through each of those. If that's not as accessible they could be added in a single attribute as a list — or maybe two attributes, one with identify_ids, one with object_names? That might make it easier to loop:

{% for identify_id, object_name in zip(state_attr('sensor.abc_printable_objects', 'identify_ids'), state_attr('sensor.abc_printable_objects', 'object_names')) %}
...

I think the only somewhat good experience we can have for this will require a card where we have the freedom to craft a similar UX to that in the Bambu software. I am confident the visuals could be built (although if I'm doing it, it'll take me a while to learn javascript/css :)) but I don't know yet if the card can then trigger service calls. I assume and believe it can but I'd also have to work out how to do that at the end once the user's choices have been made. The recent migration of cards into this repo so we have a single atomic release is to pave the way for more complex UI experiences like that.

Skipped objects are provided in the pushall MQTT statement as s_obj list.

Thanks. I thought I recalled seeing something like that.