I’m trying to create an automation with below blueprint, and it doesn’t get saved. I don’t get an error, it just won’t show up in the automations list
blueprint:
name: Turn ON OFF at certain times
description: Turn a light on at a certain time and off at another time
domain: automation
input:
time_on:
name: Time to turn ON
selector:
time:
actions_on:
name: Actions
selector:
action: {}
time_off:
name: Time to turn OFF
selector:
time:
actions_off:
name: Actions when OFF
selector:
action: {}
trigger:
- platform: time
at: !input time_on
- platform: time
at: !input time_off
action:
- choose:
- conditions:
- condition: time
after: !input time_on
before: !input time_on
sequence:
- !input actions_on
- conditions:
- condition: time
after: !input time_off
before: !input time_off
sequence:
- !input actions_off
default: []
mode: single
They aren’t caught by Check Config nor by Reload Automations but they are invalid. When you use the blueprint to create an automation, the moment you try to save the automation is when the problem is caught. That’s when it produces an error message in Logs. It’s a long-winded message but the relevant part is at the very end:
When using the !input directive, it’s designed to be placeholder for data. The data is assigned to a key. In other words, like this (key on the left, data on the right):
entity_id: !input whatever
The solution is very simple. Change those two sequence statements to this:
sequence: !input actions_on
sequence: !input actions_off
I tested it with the suggested changes and it works (the automation is saved).
I can’t figure out how to do that, not even in a normal automation where I don’t have !input. This is where I’m at
blueprint:
name: Actions - Time vs Time
description: Turn a light on at a certain time and off at another time
domain: automation
input:
time_on:
name: Time to turn ON
selector:
time:
actions_on:
name: Actions
selector:
action: {}
time_off:
name: Time to turn OFF
selector:
time:
actions_off:
name: Actions when OFF
selector:
action: {}
trigger:
- platform: time
at: !input time_on
- platform: time
at: !input time_off
action:
- choose:
- conditions:
- condition: time
after: !input time_on
before: !input time_on
sequence: !input actions_on
- conditions:
- condition: time
after: !input time_off
before: !input time_off
sequence: !input actions_off
default: []
mode: single
If you don’t have a functional automation, I suggest you create it first and then convert it to a blueprint.
Currently, you don’t appear to be comfortable with the basics of creating an automation (such as composing templates) but have already added the complexity and challenge of creating it as a blueprint.
If you do have a working automation, post it and I’ll help you convert it to a blueprint.
Hi @123, I’ve got the same problem as KKO, however, my sequence of actions is an array, of which only one of the elements is meant to be an input to the blueprint:
This is in the context of creating a blueprint out of automations I have to act on “double-clicks” for my lutron pico remotes. They all do the same thing, where if the “double-click” timer is active, it cancels the timer, and then executes some additional actions.
I could change it as you suggested to sequence: !input double_click_action, but that would require me to include the timer.cancel as the first action for all the automations I create. Given that the timer.cancel service call is the same for all of my double-click automations, ideally I’d like to include it as part of the blueprint.
The issue here is that an !input is meant to be a placeholder for a value and that value is assigned to a key. In your example, entity_id is a key and its value (which can be a block of code) will be provided by the placeholder !input double_click_timer.
The problem with !input double_click_action is that it is a placeholder without a key.
The current workaround for this isn’t pretty but it works. We need a key that accepts a block of code (but it can’t be sequence in this situation) so the workaround is to use the default key that is part of choose. It’s a stripped down choose with no choices, just default.
Thanks for the quick reply! I finally got around to trying the workaround and it worked as expected.
Like you said, not the prettiest solution, but at least if I go this way with Blueprints, when there’s a better way to implement it, it should just be the one blueprint for me to refactor.