What’s the log say?
Before upgrading to Home Assistant 0.113.0 an automation triggers a script, they both run independent of each other. After upgrading to Home Assistant 0.113.0 an automation triggers a script, the automation is dependent upon the completion of the script for the automation to complete. This is also true for a script triggering another script. Is this an outcome of the new Automations & Scripts: Running modes? Was this supposed to change, I have not found this change noted anywhere?
Raspberry pi 3 b+
HassOS 4.11 64 bit
Home Assistant 0.113.0
Hmmm, seems my Google chromecast audio speakers and Google Home minis are no longer getting discovered by the integration. Anybody else having this problem? I have mDNS working in my network and I can check from my ubuntu box with avahi-browse --all and I get all my devices listed.
But now Home Assistant 113.0 refuses to discover them, even tho my Home Assistant is installed in a docker container with the network set to host since the beginning.
Anybody else experiencing this? Or anybody knows of a way to test from the homeassistant container for mDNS visibility?
This update broke the Samsung TV integration. It now reports all my Samsung TV’s as on, regardless of true status.
It could be one of these:
I don’t like this update and its script “repeat” features.
I have an alarm siren that I toggle on and off at a specific duty cycle for a specific duration. At the time, to get this to work I needed an automation that calls a parent script that enforced the duration and calls another child script that turns on the siren and has a delay, which then calls another script that turns off the siren and has a delay, in an infinite loop between the child scripts all while waiting for the parent script to turn off both child scripts at the end of the duration. I quite liked watching the scripts toggle each other in the UI while this is happening.
If now I can just specify a “repeat” function and consolidate into a single automation, I get no such satisfaction from having accomplished an impressive feat. I’m not upgrading.
[Edit in case sarcasm doesn’t come through well over text. Great release! Great job devs!]
8 Likes
Why did you not use data_template to handle these? Could simply them much more by doing that?
1 Like
I’m glad you’re finding the new automation features useful! 
The choose action just uses conditions, which are documented pretty well here, and specifically the trigger variable for event triggers is documented here.
BTW, your example could be seriously streamlined by using the more traditional technique of a data_template:
- alias: 'Bedroom Dimmer'
initial_state: 'on'
trigger:
platform: event
event_type: deconz_event
event_data:
id: bedroom_switch
action:
- service: light.turn_on
data_template:
entity_id: light.bedroom
brightness_pct: "{{ 50 if trigger.event.data.event == 1002 else 100 }}"
If you want to make sure it only reacts to events 1001 & 1002 (e.g., if there could be other events), then just add a condition to the automation:
condition:
- condition: template
value_template: "{{ trigger.event.data.event in (1001, 1002) }}"
5 Likes
One of the fairly bizarre and usually unexpected behaviors of “scripts” (i.e., script sequences or automation actions) was that they would “suspend” at a delay or wait_template and “return” to the “caller.” So, a script without a delay or wait_template would have to complete, whereas one with one of these did not.
Now the behavior is consistent. Scripts no longer “suspend” sometimes and not other times, depending on what actions they contain.
What is not new is that calling a script via script.NAME waits for the script to finish (or, in the past, for it to suspend at a delay or wait_template), whereas calling a script via script.turn_on does not wait. What is new is that this is now documented here.
Believe me, the old behavior caused no end of confusion.
Bottom line, if you don’t want a script or automation to wait for a called script (or multiple scripts) to finish, then call it/them like this:
- service: script.turn_on
entity_id:
- script.script_1
- script.script_2
If you want the caller to wait for each to finish, then call them like this:
- service: script.script_1
- service: script.script_2
8 Likes
jodur I’m having issues with a media player with 113. My Volumio entity renamed itself and now automations don’t control the player. You get it figured out?
You have a lot of nerve! If you don’t like the feature, well then just don’t use it!! I never!!!
1 Like
Hell no. That would be a major breaking change.
2 Likes
Please don’t default to queued. Multi-press (often accidentally) would make it run twice, terrible. Current single default is best choice.Although previous version was more like restart, but single is the preferred default.
Phil has already indicated that this will not happen.
I did not see his reply until after I had replied.
What I meant with the documentation was that the new feature had examples only using state changes and I had to spend some time putting the things together (based on the exact docs you link to).
I encourage to use more complete examples in the documentation in general. I remember how it was a year ago when I started. The fully working examples on this forum and the github configs many have shared have been a life saver for me.
So I just wanted to share a fully working example where the trigger is events.
I just posted the first two “if then” in my example. When you have the full example where the 4-button remote is used with several functions per butten then you need more than can be handled in a data_template.
I have more than 20 remotes and there is also some value in having the exact same yaml structure in all of them. If you try to be too smart, and come back in 6 months to tweak something then it becomes more difficult to maintain. Sometimes 5 lines of code is better than being smart and compact
I like the example of
{{ trigger.event.data.event in (1001, 1002) }}
instead of my “or” syntax. I will use that. The beauty of open source. You contribute something and you get even more in return.
3 Likes
Guessing it’s this problem. So no upgrades for me for a while.
In the actual example where the only difference is the brightness could be done like that.
But the other buttons have different functions and often I use completely different actions for the long press features.
My missions was to show and share how to use the new automation feature where the trigger is an event instead of a state change.
I’m having the same issue of the rollback happening 10min after 0.113 booting (looks rather successful in the frontend and logs up until then), but I’m not using tensorflow. So it’s probably another component that’s blocking my upgrade. Unfortunately the logs give me no indication which one it could be…
Try the code in this PR to enable logging to help find the integration blocking startup.
Yep, rolled back as well - all my LightwaveRF ‘Mood’ switches failed. Really don’t want to have to go through every device one by one.
Whilst I’m sure there are reasons for these changes, I can’t help but think this changes breaks more than they anticipated, or was tested in a fairly limited scope.