One of the recent introductions to the already versatile Home Assistant ecosystem is the Condition Selector for blueprints. At its core, this feature seems simple, but its implications for blueprint flexibility are profound.
My usecase
I’ve personally used this to update my smart lighting setup. I have one blueprint that I re-use for every room in the house. It follows a brightness and color temperature curve throughout the day, and allows me to set min and max lux levels to automate the lights going on and off, as well as how long it should take for the lights to turn off after no motion has been detected. But in some situations, you might want to adapt this. A simple example is my home office which doubles as a guest room, and now, when guest mode is on I can completely disable the lights from coming on based on motion. In another room, I might use it to prevent the lights from being turned off as long as the tv is on, or while I am in a meeting. Lots of options, and I can stick with a single blueprint.
Understanding the Condition Selector
The Condition Selector, as the name suggests, lets blueprint authors define a section where users can input one or more conditions. On the UI side, users will interact with the familiar condition part of the automation editor.
In its raw form in YAML, it’s as simple as:
selector:
condition:Code language: YAML (yaml)Its output provides a list of conditions. Here’s an illustrative example:
- condition: numeric_state
entity_id: "sensor.outside_temperature"
below: 20Code language: YAML (yaml)Why This Matters
Prior to this feature, blueprints had rigid conditions set by the blueprint creator. Now, the end-user has a way to provide custom conditions while leveraging the convenience of blueprints. This adaptability serves two crucial purposes:
- Granular Control: Advanced users can now tailor automations more closely to their specific needs.
- Simplification for New Users: Newcomers don’t have to grasp the entire YAML syntax right away; they can input conditions via the UI.
A complete example
Below is an example of how this can be implemented. As you can see, I added a default, which makes sure that the blueprint is backwards compatible with the automations I’ve already created.
conditions_for_enabling:
name: Trigger conditions
description: Conditions to be met for the action to occur
default: []
selector:
condition:Code language: YAML (yaml)Integrating Conditions into Actions
The true prowess of this selector emerges when it gets incorporated into the action sequences of a blueprint:
1. Direct Embedding
You can insert the user-defined conditions directly within the actions.
action:
- condition: !input 'conditions_for_enabling'Code language: YAML (yaml)However, without conditions, this can lead to potential errors.
2. ‘Choose’ for Greater Stability
A more resilient method utilizes the choose structure, ensuring smooth automation regardless of the conditions.
action:
- choose:
- conditions: !input 'conditions_for_enabling'
sequence:
# actions to be executedCode language: YAML (yaml)
