I upgraded to 2021.4 yesterday and wanted to play with the new automation debugging feature. When I go to Configuration --> Automations, I get a list of my automations as expected. However, if I click the pencil icon on any of the entries, I receive an error that says “Error loading automation (500).” I can’t say whether this worked before 2021.4 or not, but it’s definitely not working now.
No, but I just opened an incognito tab, logged in, and got the same error message. Is there a particular log file I should be looking at for details around this error?
Although I doubt things are shared between normal and incognito you could just reload the normal page. If that does not help, I would do a system reboot.
Here’s what I have in my automations.yaml file for this:
- id: disarm_when_brian_returns_home
alias: "Disarm when Brian returns home"
trigger:
- platform: state
entity_id: device_tracker.brians_iphone_12_pro
from: not_home
to: home
action:
service: alarm_control_panel.alarm_disarm
entity_id: alarm_control_panel.house_alarm
data:
# code: !secret alarm_code
entity_id: alarm_control_panel.house_alarm
The problem is the line that I’ve commented out. I believe that this is a result of the 2021.4 upgrade where secrets are not allowed in other yaml files.
At this moment, we are unsure if this is a breaking change or not, so we list it, just to be sure.
We are now explicitly only supporting secrets inside your Home Assistant Core and Lovelace configuration files (and anything included from there). Secrets are no longer supported in other loaded YAML files.
This change should not affect regular users of Home Assistant, however, we have been made aware that some custom integrations may cause problems. If you are a user of Dwains theme, the HomeKit Infused theme or lovelace_gen, please make sure to update those or check with the upstream project.
Any idea how to have an alternative. I use the secrets file in my automation to stop having to change the same things in multiple automations. For example I have many different automations checking various sensor states. When I add or change which sensors need to be checked I just change it once in my secrets file. Here is the code showing the commented out line before the use of secrets and the uncommented line showing the use of secrets. Is there an alternative way of doing this?:
- id: '1609452279387'
alias: Check Beam Offline - any
description: Notify if the beam sensor goes offline
trigger:
- platform: state
# entity_id: binary_sensor.set_input,binary_sensor.beam_input_2,binary_sensor.beam_input_3,binary_sensor.beam_input_4,binary_sensor.beam_input,binary_sensor.cowshed_beam,binary_sensor.alarm_input
entity_id: !secret all_sensors
to: unavailable
condition: []
action:
- service: notify.all_devices
data:
message: '{{ trigger.to_state.attributes.friendly_name }} disconnected - possible
tamper??'
title: Offline Warning
- service: persistent_notification.create
data:
message: '{{ trigger.to_state.attributes.friendly_name }} disconnected - possible
tamper??'
title: Offline Warning
mode: single
I’m late to the party. I just uploaded to 2021.4 and tried implementing the Alarm Panel using !secrets. Obviously I got the same (500) error.
If I read this thread correctly am I to understand that if I want to use !secrets to hide my alarm code used in an automation I cannot have the Automations code in a separate automations.yaml file?
If so, can anyone explain the logic behind this decision? Or is it simply a bug that will be fixed at some stage?
I agree - anyone found a solution yet?
Most of my sensitive data from my automations that are created within several .yaml files are saved in the secret file.
It seems like the !include function is causing this issue - not just the secrets inclusion. I broke apart my scenes.yaml file and created multiple scene files such as “scenes-kitchen.yaml”, “scenes-bedroom.yaml”, etc. These files work as expected, but you can’t use the GUI to edit them. Editing can only be accomplished within the text editor. Although I am running the latest install, I am surprise this bug hasn’t been fixed yet - it’s only been 2.5 years since the first reporting of it.