Blueprint error: "...generated invalid automation..."

Configuration Blueprints
1

As a newbee I’m fashinated and lured by the blueprint concept asit would allow me to work with templates for my home automation rather then copy-paste…

But, albeit I have triedto follow the template blueprints bundled with 2020.12, the online documentation as well as Barret’s video, I still fail with even the simplest attempt, resulting in

  • the automation not being visible in the UI, although created in the automation.yaml
  • the server log throwing an error that makes me non the wiser:

Blueprint Mall - slack dumma lamport generated invalid automation with inputs OrderedDict([(‘turn_off_time’, ‘22:00:00’), (‘target_light’, ‘switch.matrum_glas_musik’)]): expected a dictionary for dictionary value @ data[‘action’][0][‘target’]. Got None

Random attempts has created entries in the automation UI, but with the entity field being unpopulated.

Blueprint:

blueprint:
  name: Mall - slack dumma lamport
  description: Slack vid ngt klockslag
  domain: automation
  input:
    turn_off_time:
      name: Tid
      selector:
        time:
    target_light:
      name: Lampa
      selector:
        entity:
          domain: switch

mode: single
trigger:
  platform: time
  at: !input turn_off_time

action:
  service: switch.turn_off
  target: !input target_light

automation.yaml:

- id: '1608379702611'
  alias: abc 201219 1308
  description: ''
  use_blueprint:
    path: homeassistant/mall_slack_dum_lampa_kvall.yaml
    input:
      turn_off_time: '22:00:00'
      target_light: switch.matrum_glas_musik

Things like the usage of preceding “-” in the action part does not make life easier for use newbies, in the two examples attached in 202.12, one of them is written with, while the other is without. Is it significant? No idea. What I do is that I take an existing working automation and try to apply the blueprint requirement on top. Does it work? no.

leaving zone blueprint example:

action:
  domain: mobile_app
  type: notify
  device_id: !input notify_device
  message: "{{ person_name }} has left {{ zone_state }}"

motion light example:

action:
  - service: light.turn_on
    target: !input light_target
  - wait_for_trigger:
      platform: state
      entity_id: !input motion_entity
      from: "on"
      to: "off"
  - delay: !input no_motion_wait
  - service: light.turn_off
    target: !input light_target
2

The leading hyphen is related to YAML syntax (and is not specific or unique to the subject of blueprints).

You need to understand YAML syntax before attempting to create blueprints, automations, scripts, etc.

The hyphen denotes an item in a multi-item list. If there’s only one item then the hyphen is optional.

The presence of a hyphen in the following example is unimportant because there’s only one action.

action:
  service: switch.turn_off
  target: !input target_light

When it comes to blueprints, we are all currently “newbies” because it’s a new concept. However, if someone is also new to YAML, automations, scripts, etc then they will have an especially difficult time with blueprints (to be honest, blueprints were designed for the use of experienced users). The documentation for blueprints is minimal and even experienced users are currently encountering difficulties (notably with target).

2 Likes
3

Hyphen - thanks for the clearification :slight_smile:

I must say that I have been able to survive quite long in the HA domain without needing an expert level in YAML thanks to the automations UI editor, and still been able to come up with compliacated and functional solutions.

Blueprints would be a very convienient way to write-once-use-many, but as is becoming evident it seems to be a hit-or-miss whether they will fly in particular cases. Maybe I shold just forget about them for the time being (just as I have descided wrt OpenZWave).

4

There’s no UI editor for creating blueprints, therefore the need to be comfortable with composing them in YAML.

FWIW, my choice of using the adjective “experienced” was to clarify the skill-level needed to compose good blueprints. It’s not just my opinion but was also expressed in the original proposal for blueprints. Here are the first two bullet-points:

  • Give advanced users the option to easily create reusable automations.
  • Super charge sharing and make it easy for expert users to use their YAML skills to help novice users automate with the UI.

The words ‘advanced’ and ‘expert’ have not appeared in more recent blueprint documentation but it’s clear that if someone isn’t handy with YAML they will not have an easy time creating blueprints. In addition, if they are unfamiliar with Script Syntax then they are less likely to create blueprints with optimized automations.

1 Like
5

Unfortunately the underlying message from the original proposal is (edit:) not carried forward into the depolyment, and you are not the only experienced Ha user to is indicating that this is not an easy thing, as discuessed by Burningstone in Blueprint error with conditions, but also ine general in Blueprints curated collection: help wanted!

So, all together, my conclusiona seems to be reinforced - as a newbee you can tinker away, and if you succedd, wle, you are fortunate and lucky, and if not, then don’t have too high expections, as the concept needs to be rolled out in order to improve, but at the same time could be said having been rolled out a wee bit too early :frowning:

6

Final(?) word on this particular entry…
It is a bit disheartingly that there has been to discussion on the actual problem/error, and how to possibly correct the blueprint, but only that blueprints are not for the fainthearted.

Ok, HA is not for the masses (yet) - those are directed to Hue, IKEA or others with similar controller products. But, surely, HA can’t only be focusing on the nerds and geeks either?
If the idea with blueprints is that the knowlegeble should provide templates for the masses I’m afraid that it won’t fly, for one thing the ration is probalby not up to it, for the second it might not be what the “experts” where envisioning when joining the journey, and lastly it feels a deviation from the core idea of an versertile solution like HA or openHAB to create dependencies between users providers…

Let’s hope this improves once v2 of the blueprint concept is deployed :pray:

7

I think you’ve missed the main goal of blueprints. They are meant for the use of knowledgeable users to create easy-to-configure automations for the use of less knowledgeable users.

In fact, they will only get more powerful, and more complicated, in V2.

If a person expects to create blueprints without a basic understanding of YAML syntax, they are mistaken. If they are waiting for something similar to the Automation Editor for blueprints (a ‘Blueprint Editor’), they are in for a long wait.

As for the problem with your blueprint, the error message is due to the action expecting a target but the input is an Entity Selector and not a Target Selector. Both must be consistent. Either change the input to a Target Selector or change the action’s target: to entity_id: .

3 Likes
8

I must confess that reading your post yesterday turned me evem more down wrt the aim and purpose of both HA and Blueprints, as thy indicated a future path forward not entirely aligned with my perception of HA, one where there is a clearer split between have’s and have not’s [senior knowledge]…
My perception has up till now been that as long as you’ve some coding skill you wil lbe supported by the tools in HA (parsers, UI’s) as well as the community.

Well, however, picking up on the dependency in the input declaration versus the keyword useage in action the blueprint now works :slight_smile:

1 Like