Scripts not working since 2023.6

c0ntax · June 8, 2023, 6:48am

Has anyone else got an issue with script errors since 2023.6 upgrade?

I’m seeing the below in the script in entities for some reason:

And, when I check the logs, as to why the script didn’t execute I get the below, which strangely has an extra script. in front of the entity, so it shows script.script.. Maybe it’s always been like that but I don’t think so.

Logger: homeassistant.components.automation
Source: components/automation/config.py:207 
Integration: Automation (documentation, issues) 
First occurred: 6:32:19 AM (6 occurrences) 
Last logged: 7:35:04 AM

Automation with alias 'Close Blinds' could not be validated and has been disabled: Service script.script.close_master_bedroom_blinds does not match format <domain>.<name> for dictionary value @ data['action'][1]['service']. Got 'script.script.close_master_bedroom_blinds'
Blueprint 'Philips Hue v2 Smart Dimmer Switch and Remote' generated invalid automation with inputs {'zha_device': 'bdd35051b552c9f46f2a42165e6fbab3', 'Power_Press': [{'service': 'light.turn_on', 'data': {'transition': 2, 'rgb_color': [247, 187, 84], 'brightness': 180}, 'target': {'entity_id': 'light.kitchen_lights_all'}}, {'service': 'switch.turn_off', 'data': [], 'target': {'entity_id': 'switch.kitchen_sensor_motion'}}], 'Power_Press2x': [{'service': 'light.turn_on', 'data': {'transition': 2, 'rgb_color': [247, 187, 84], 'brightness': 170}, 'target': {'entity_id': 'light.kitchen_lights_all'}}], 'Power_Press3x': [{'service': 'light.turn_on', 'data': {'transition': 2, 'rgb_color': [252, 252, 252], 'brightness': 231}, 'target': {'entity_id': 'light.kitchen_lights_all'}}], 'Power_Press4x': [{'service': 'light.turn_on', 'data': {'transition': 2, 'rgb_color': [252, 252, 252], 'brightness': 255}, 'target': {'entity_id': 'light.kitchen_lights_all'}}], 'Up_Press': [{'service': 'light.turn_on', 'data': {'transition': 0, 'brightness_step_pct': 1}, 'target': {'entity_id': 'light.kitchen_lights_all'}}], 'Down_Press': [{'service': 'light.turn_on', 'data': {'transition': 0, 'brightness_step': -1}, 'target': {'entity_id': 'light.kitchen_lights_all'}}], 'Hue_Press': [{'service': 'light.turn_off', 'data': {'transition': 4}, 'target': {'entity_id': 'light.kitchen_lights_all'}}, {'service': 'switch.turn_on', 'data': [], 'target': {'entity_id': 'switch.kitchen_sensor_motion'}}]}: template value should be a string for dictionary value @ data['action'][5]['choose'][0]['sequence'][1]['data']. Got []

Nick4 · June 8, 2023, 7:07am

Hi Martin, just a guess what you could try:

check your integrations (I had problems too after upgrading, another restart solved that)
try to run the sequences from the script separately
check if there is an update for that blueprint and if not, check/redo the the action part

c0ntax · June 8, 2023, 7:35am

Thanks Nick. The Close Blinds script runs fine when executed manually and I’ve restarted and even rebooted several times.

However, I hadn’t even spotted the reference to the blueprint until you mentioned it and that makes it even more curious because that particular blueprint has no relevance to the Close Blinds script.

I’ve just checked my automations.yaml and scripts.yaml and there is no link between the script and blueprint.

Nick4 · June 8, 2023, 8:18am

Can you post the automation ‘Close Blinds’

c0ntax · June 8, 2023, 9:06am

I spotted it. I added a new script to the actions yesterday and must have entered script.script accidentally. But, the automation calls 2 services and the error was in the second service call so the first one,service: script.close_downstairs_blinds should have run, shouldn’t it, then failed with the last one, or does it fail all actions?

Also, I still don’t get how the blueprint is being referenced when it is not linked to the automation.

This is my automation (corrected to remove the extra script. in front of the last action service):

- alias: Close Blinds
  id: close_blinds
  mode: single
  trigger:
    platform: numeric_state
    entity_id: sun.sun
    attribute: elevation
    below: -0.4
  condition:
  - condition: state
    entity_id: sun.sun
    attribute: rising
    state: false
  action:
  - service: script.close_downstairs_blinds
  - service: script.close_master_bedroom_blinds

Nick4 · June 8, 2023, 10:43am

Forget the blueprint, that was a mistake from me.

The log also shows that the automation had been disabled because of that error.
Since you removed that and activate the automation again, it should work.

c0ntax · June 8, 2023, 12:26pm

Thanks Nick.

finity · June 8, 2023, 1:30pm

Yes, that is a fairly recent and huge user-unfriendly regression in the way the syntax checker works.

the older behavior was that it would give you a notification in the sidebar that there was a problem and that you needed to check the logs for the error.

now it just silently fails and disables the automation without telling you unless you happen to notice the automation not triggering and happen to see the logbook entry.

it’s unfortunate that the devs have decided that this is the desired behavior for something as important for a home automation system as automations and claiming to be user friendly that new users need know to open the logbook to even know there is an issue that needs addressed.

I really don’t get it.

petro · June 8, 2023, 1:59pm

The automation editor does not let you save with those types of mistakes. And there still are errors in the logs related to these as long as you don’t restart. As soon as you restart, your previous logs are lost (Unless you look at the log history in your config folder) and the automation is already disabled (so it won’t generate the error again). The only change was the notification on the sidebar. That only affects YAML automation users who do not use the UI.

TLDR: You’ll see these errors if you use Yaml only automations in the UI, or you use the GUI UI. The errors are still in the logs but they wont be after it’s disabled and you restart.

c0ntax · June 8, 2023, 2:30pm

I was not aware of any of that, thanks @finity @petro

I rarely use the GUI to create any automations or scripts etc but I’ll keep an eye out for this in future.

finity · June 8, 2023, 2:42pm

The only thing I ever do after creating/editing an automation is to do a config check and if it says it’s valid then I just reload automations. I don’t restart.

the config check doesn’t give a warning/notification that there is a problem with the automation. the system just disables the automation and puts an entry in the homeassistant.log with no other indication at all that there is a problem with the automation.

I’ve had this happen multiple times in the last few months with just a simple config error.

I guess I don’t see the purpose of removing the sidebar notification.

petro · June 8, 2023, 2:42pm

Same here. 100% yaml. If you test your automation with logs open, you’ll catch these errors immediately. The only reason it disables is because it was a service call error. If you mess up on an entity_id or service call data, it’ll just log the error in the logs without disabling the automation. That behavior hasn’t changed.

petro · June 8, 2023, 2:44pm

The whole system was reworked, it wasn’t a “Hey lets hurt the user by not having this notification”. Contrary to your belief, many of these changes are just overlooked accidentally.

finity · June 8, 2023, 2:52pm

Here is an issue that I submitted 3 weeks ago for it if anyone is interested:

github.com/home-assistant/frontend

Config Check no longer reports some invalid configurations

opened 09:06PM - 15 May 23 UTC

finity69x2

### Checklist - [X] I have updated to the latest available Home Assistant ver…sion. - [X] I have cleared the cache of my browser. - [X] I have tried a different browser to see if it is related to my browser. ### Describe the issue you are experiencing When making yaml configuration changes the config checker fails to report some errors in the config. It's happened a few times now but the latest occurrence was with the following action: ``` action: - repeat: - service: notify.alexa_media data: target: - media_player.livingroom_dot data: type: tts message: "It's time to turn off the water in the front yard" - delay: "00:02:00" until: - condition: state entity_id: input_boolean.irr_time_to_water_front state: 'off' ``` Note there is a missing "sequence:" Instead of reporting an error in the config check window or even just reporting a persistent notification to inform of the error the automation just silently failed to load. I didn't notice it until I went to the traces to figure out why the automation didn't run and found that the automation didn't exist in the system. There was a note in the log about it that I found later but there was nothing to tell me that I even needed to look there to find the issue. At one point in the not too recent past the config check would pass but if there was an error it would at least display a persistent notification indicating there was a problem. ### Describe the behavior you expected There should at a minimum be a persistent notification with either the same info that is placed in the logs or the link to the logs as it has been in the past. ### Steps to reproduce the issue ``` action: - repeat: - service: notify.alexa_media data: target: - media_player.livingroom_dot data: type: tts message: "It's time to turn off the water in the front yard" - delay: "00:02:00" until: - condition: state entity_id: input_boolean.irr_time_to_water_front state: 'off' ``` Note there is a missing "sequence:" ### What version of Home Assistant Core has the issue? 223.5.0 ### What was the last working version of Home Assistant Core? _No response_ ### In which browser are you experiencing the issue with? Chrome ### Which operating system are you using to run this browser? Windows all versions ### State of relevant entities _No response_ ### Problem-relevant frontend configuration _No response_ ### Javascript errors shown in your browser console/inspector _No response_ ### Additional information _No response_

c0ntax · June 8, 2023, 3:16pm

It’s a bit crazy that something so integral to your smart home running efficiently does not have an ‘in your face’ warning that it’s not working (disabled).

Is there a way of creating a template to list all automations/scripts that are disabled? I have one each for devices and entities in a lovelace card but I wouldn’t know how to reference all automations/scripts. It’s not as if they are a device_class or anything.

I would prefer a warning at config check as well though.

c0ntax · June 8, 2023, 3:18pm

Ah, just found one but not yet tested it.

{{ states.automation | selectattr('state', 'eq', 'off') 
   | map(attribute='name') | list | join ('\n') }}

Much prefer a warning!

EDIT: Yes, it works. Better than nothing at this point. (credit for the automation here)

petro · June 8, 2023, 3:30pm

That’s not possible. At best the service slug can be validated, but it’s existence or not can’t be checked without the system running. This has always been a limitation of the config check. It only validates the yaml, it does not validate anything “deeper”. For that, you have to use the SSH config validation option or run the automation after reloading.

petro · June 8, 2023, 3:31pm

That’s a bit off topic though, that just seems like a bug with repeat. I looked at the code, it should be failing config check for that. I only looked at the surface though. There’s a function in there that might cause oddities.

finity · June 8, 2023, 3:33pm

I don’t think that will catch the issue with disabled automations that we are seeing.

as far as I’ve seen the disabled automation isn’t off - it’s not even included as an automation entity at all in the states list. If you look for that automation it doesn’t even exist as far the system is concerned.

That’s how I was able to know to look in the logs in the first place because the automation didn’t trigger and when I went looking for the trace the automation didn’t show up anywhere in the system. So I just looked to see if there was anything in the log and there it was.

finity · June 8, 2023, 3:37pm

I’m really sorry to have to keep adding to this thread and not addressing my points to anyone in particular…

the bug report was just an example of the failure that I was seeing. it wasn’t specifically about the repeat. it was about the error in the repeat not providing an invalid config check.

there have been many examples of this not only with the repeat. And not only from me. this thread is another example of that.

you would think that it should have given an invalid config check but it didn’t. it just failed silently with only an entry in the log and disabled the automation.

that is exactly the problem.