Currently I am using my own blueprints.
How should I “reload” blueprints if some of them were changed by me in yaml editor or some new blueprints were added?
Shall I use “Reload automation” button?
Or these blueprints are updated automatically as soon as I change their files?
Yes, reloading automations also reloads blueprints.
You can automate this somewhat too:
3 Likes
Reloading Blueprints worked out fine, either by just switcing to the Script tab or by actually running the Server Reload Automations.
But what never worked for me is to get the the created automation showing up in the GUI, the only alternative while playing around so far has been to edit the automations.yaml file, but that is not what is supposed to happen if I understand the documentation correctly - the instanced blueprint automation should be visible together with all other… Or?
4th paragraph in the Using Blueprint guide:
Using Blueprints
1 Like
@marieper i can confirm same strange behaviour - automations created from blueprints not visible. but even if i modify the automations file, i still can’t see them… will dig further…
Do you have automations.yaml file in the config dir?
Whenever I create a new automation based on a blueprint from UI, the new automation then is shown in the “Automations” list and is added to the <config>/automations.yaml.
(Then I move the added automation to the appropriate package like “<config>/conf/air_xiaomi_cleargrass_1_automations.yaml” but it is another story)
The automations.yaml is in config, and as stated above the file is updated when the blueprint is saved.
The GUI is not updated, regardless of reload of automations or restart of server.
I have yet not started with splitting the automations into separate packages, might do so inte future…
Snippet of automations.yaml, where the blueprint is added to the end:
id: '1606772732691'
alias: Dimma upp långsamt
description: ''
trigger:
- platform: time
at: '23:09'
condition: []
action:
- service: light.turn_on
data_template:
brightness_pct: 10
transition: '{{ as_timestamp(now().strftime("%Y-%m-%d " ~ ''{0:0=2d}:{1:0=2d}''.format(23,12)
~ '':00'')) - as_timestamp(now())}}'
entity_id: light.vagglampa_trappa
mode: single
- id: '1608157386619'
alias: Mall Släcka dumma lampor kväll
description: ''
use_blueprint:
path: villa_lundborg/mall_slack_dum_lampa_kvall.yaml
input:
turn_off_time: '23:37:00'
target_light:
area_id:
- cf45aa36406c44348d839e0c7d74fbfa
- d6cee87f740841b1afde0a768b5788f6
- 1bd9d7c93e3a4525b1f042fec392c0e8
- b4aefe6c2eba4347bb2f0398a00276df
- 8470943405384a708324180fab2c7a58
- f511c1ace84644e089c291bda38828bc
Do you have any automations in your UI? If so, are those automations in this same file?
Considering all users are different I shouldn’t say “naturally”, but never the less:
Yes they are visible in the GUI. I have no issue with any automations apart from those created by blueprints. All manually written automations work as expected across the yaml-file and the GUI, and I can optionally manage them from either interface.
Blueprint automations are limited to the yaml-file only.
I am expectin the blueprint automation from the yaml-file to show up alphabetically in the GUI:
As long as “Dimma upp långsamt” is also showing up in your automations UI list, then either something is quite broken, you have a browser caching issue (try a hard refresh?), or the automations aren’t actually reloading. If restarting the server also doesn’t make it show up (as you indicated) then it’s got to be one of the first two.
As the native app and the Windows browser has the same lack of automations, I do not think that it is a caching problem.
I’m about to install the 20.12.1 patch, it might shake things around so that it comes out right in this regard.
2020.12.1 made no improvement 
Edit: host reboot, and creation of dummy automation from blueprint, still no change in the GUI. ýaml-file updated as expected.
Automations containing the keyword use_blueprint do not show up.
Cloning an non-blueprint automation in the yaml-file, and reloading automations from the Configration > Sever works as expected.
Although not related directly but slightly contributing to the problem is the fact validation of the blueprint is somehow buggy in the file editor - i get red ! mark in the editor also on the sample blueprints.
I created a blueprint that was somehow wrong (missing the target tag on the target entity), and then i used it in an automation.
Automation failed to execute, actually it failed to be loaded - to the point that I could not see anymore the Reload Automations button in the Configuration > Server Controls. All this while validation was valid.
Then i fixed this issue and all was ok.
Check also that the blueprint in indeed saved as .yaml file, along the sample ones
1 Like
Additional, desparate, attempt by creating the automation from a blueprint, this time from within the automation UI dialogue. There is no obvious reason for why this should have any impact on the end result, but I am grabbing for straws here:
This time it works!
But the difference is not how the automation is created, but that the source was one of the default/example blueprints, so the error is presumably in the blueprint file, and as @alexciurea pointed out there seems to be some issues with the parsing, or lack of.
blueprint:
name: Mall Släcka lampor kväll
description: Släck lampa på kvällen, typ 23:30
domain: automation
input:
turn_off_time:
name: Släcktid
selector:
time:
target_light_smart:
name: Lampa/Lampor
selector:
target:
entity:
domain: light
target_light:
name: Lampa/Lampor
selector:
target:
entity:
domain: switch
trigger:
- at: !input turn_off_time
platform: time
condition:
- condition: state
entity_id: input_boolean.gaster_hemma
state: 'off'
action:
- type: turn_off
entity_id: !input target_light
domain: switch
action:
- type: turn_off
entity_id: !input target_light_smart
domain: light
mode: single
I am okay with that the resulting automation might not work as expected due to possible syntax errors, but I do believe that HA should be robust with regards to creating a editable instance inte the automation config UI.
I am having the exact same issue when testing the blueprint that I created.
I’ve found that invalid automations don’t show in the gui, which can be deeply inconvenient. There are a number of reasons I’ve found for the automation to be invalid. I’ve no idea whether they’re relevant to the difficulties discussed above.
- I’ve written it by hand (badly!), in which case, I can just edit the automations.yaml again.
- It can be based on a blueprint, which produces an invalid automation. In which case, as Alex mentions above, it doesn’t show in the UI. If it was a previously existing automation, that’s inconvenient (to say the least). If it’s a brand new automation, and it doesn’t show up, then, from the UI, I can’t even tell if I’ve created it. So I can try to create it again. And it still fails to show up. My worst case was suddenly finding 3 broken automations in automations.yaml, which I’d simply forgotten about. I can then manually edit them out.
- If I add an extra non-default input to a blueprint, then all the automations disappear from the UI, rather than allowing me to edit each one to add the extra input. That’s a pity: the edit function does actually work, if I grab the URL before changing the blueprint; it’s just that the automation isn’t listed on the UI page to offer me the edtiting URL.
- If I delete a blueprint file, then, obviously, all the dependent automations break, and they disappear from the UI as well, so need manual deletion from automations.yaml.
In all those cases, the config checker reports that everything is ok.
So far, I’ve learned to.
- Visit the blueprints page. Blueprints with invalid yaml will show up there, not as their name, but with the parser error message.
- tail -f homeassistant.log whilst checking config, opening the blueprints page, or reloading the automations.
(one problem with that is that the same error can be reported repeatedly, because it’s coming from each automation based on the blueprint, rather than the blueprint itself. I understand why, but it’s still inconvenient!)
It would be nice if the automations UI could include broken automations, so they can be edited or deleted. It might have helped with some of Per’s initial problems, at least to show that an automation existed, albeit with problems.
1 Like
My automation works as an automation itself, but when I try to create it as a blueprint it does not work. I’ve created a new topic with the automation and the error(s) I receive when I try to create an automation from the blueprint.
It would be nice to get some more information about the instantiation process of blueprint automations.
Instatiated information is cached somewhere other than in the automation.yaml.
If you modify a blueprint file … it appears you NEED TO RESTART the core for already instantiated blueprint automations to see the change.
Here is my test scenario:
- Modify a blueprint file (that I have already instantiated some automation instances with)
- Reload automations
- “Run Actions” on an already instantiated automation for this blueprint.
- From Logbook … Trace the previous Run Actions.
Upon inspecting the trace, you can verify that the changes were NOT reflected. - Create a NEW instance from the blueprint.
- “Run Actions” on the new instance.
- From Logbook … Trace the previous Run Actions.
Upon inspecting the trace, you can verify that the changes ARE reflected for the NEW instance. - Restart the core.
- “Run Actions” on the same automation as in step 3
- From Logbook … Trace the previous Run Actions.
Upon inspecting the trace, you can verify that the changes ARE NOW reflected.
I have problem to reload blueprint after I made changes in my github.
I have tryed restart ha, restart core, restart host
It only worked if I removed blueprint and add it again. (but this is bad solution)
2 Likes