Blueprint UI: Conditional visibility / disabling of inputs based on other selections

[hedegaard1]

Describe the feature

Blueprints become increasingly powerful, but also increasingly complex, as more optional features and modes are added.

Currently, all Blueprint inputs are always visible in the UI, regardless of whether they are relevant to the user’s selected options. This makes Blueprint configuration long, cluttered, and harder to understand—especially for users who only want basic functionality.

There is no supported way to:

• Hide inputs unless a specific option is selected
• Disable (grey out) inputs that are not applicable
• Dynamically simplify the Blueprint configuration UI

I would like to add conditional visibility and/or disabling of Blueprint inputs, based on the value of other inputs.

For example:

• Show “Advanced options” only when an “Enable advanced features” toggle is enabled
• Show additional configuration fields only when a specific mode is selected
• Disable inputs that are not relevant for the current configuration

This would allow Blueprint authors to create cleaner, more user-friendly configurations without changing the underlying automation logic.

Use cases

Advanced Blueprints with optional features
Blueprints that support snapshots, delays, notifications, or extra conditions often require many inputs that are only relevant in certain modes.

Basic vs Advanced configuration
Users who only want basic functionality should not need to scroll past many unused options meant for advanced use.

Multiple operation modes
Blueprints that support different modes (e.g. “Simple” / “Advanced”, “Auto” / “Manual”) could dynamically show only the relevant inputs for the selected mode.

Reducing user error
Hiding or disabling irrelevant inputs reduces confusion and the risk of misconfiguration.

Current workarounds

Currently, Blueprint authors must rely on:

• “Enable X” boolean inputs combined with choose: logic
• Long descriptions explaining that certain inputs are ignored unless another option is enabled
• Splitting Blueprints into separate “Basic” and “Advanced” versions purely for UI reasons

These approaches work functionally, but they are UI compromises and make Blueprints harder to maintain and understand.

Anything else?

Other automation and configuration systems support conditional UI elements, allowing interfaces to adapt dynamically based on user choices.

Even a simple mechanism such as:

• visible_if
• enabled_if
  (declared in the Blueprint input definition)

would significantly improve Blueprint usability and encourage more advanced, yet approachable, Blueprint designs.

[rumblefishi]

I would love to see this feature implemented!

As a frequent user of blueprints from the Home Assistant exchange, I regularly encounter complex blueprints with numerous input fields. Many of these fields include descriptions like "Only relevant if Option A was selected above" or "Only applicable when Option B is enabled."

From a user experience perspective, this makes the configuration interface unnecessarily cluttered and confusing, as I'm presented with many fields that aren't actually relevant to my specific use case.

The ideal solution would be to dynamically hide irrelevant fields based on previous selections. This would make complex blueprints much more approachable and user-friendly.

This feature would significantly improve the usability of advanced blueprints while maintaining their powerful flexibility.

[hedegaard1]

totally agreeing. :-)

[SirGoodenough]

This has been available for years already...
https://www.home-assistant.io/docs/blueprint/schema/#blueprint-input-sections
example:
https://github.com/SirGoodenough/HA_Blueprints/blob/2c8a5d942a24a4f00611f4d04f9ca6cb0832508c/Automations/Zigbee2MQTT-Aqara-Magic-Cube-T1-Pro-CTP-R01-Xiaomi-Lumi.yaml#L106

[kramttocs]

I saw you say the same in a forum thread but I don't think it's really correct
Yes, collapsible sections are available but I am not seeing how to make them collapse or expand based on input.
And that isn't really even what is being asked for since adding a single optional field in a section doesn't make much sense. What's is being asked for is to hide/show fields (nothing to do with sections) based on other inputs.

Let me know if I am mistaken.

[hedegaard1]

Hi,
It is correct.
I am asking to make options only being visible (available), if another option is choosen.
This would give a way better solution in the blueprint, if something is only showed when needed/choosen or else, not shown.
Thanks in advance.

[rumblefishi]

Thank you for clarifying! I'm glad we're all on the same page.

Just to highlight the difference for anyone reading:

collapsed (what we have now):

• Section headers are always visible
• Can be set to collapsed: true to hide content by default
• Users can manually expand to see the fields
• Requires all inputs to have defaults
• Great for organizing optional/advanced features

visible_if (what we're requesting):

• Fields/sections completely disappear when condition isn't met
• Dynamic based on other input values: visible_if: "{{ input.mode == 'preset' }}"
• No manual interaction needed - UI adapts automatically
• Only shows relevant options based on user's choices

Both features are useful, but they solve different problems. collapsed helps organize optional sections, while conditional visibility would eliminate irrelevant options entirely.

This would really help make advanced blueprints more approachable for everyone! 🙂

[kramttocs]

Hi, It is correct.

My 'not correct ' comment was to the poster saying it was already available

[nielsrowinbik]

We are tracking making creating blueprints more approachable on our roadmap: OpenHomeFoundation/roadmap#39. I've now explicitly called out this feature request in there!

[rumblefishi]

Nice 👍🏼