0.113: Automations & Scripts, and even more performance!

Blog
184

That ship has sailed. :stuck_out_tongue_winking_eye:

If you want them to work in queued mode you’ll need to modify them to select that mode.

Also in case you didn’t see when it was discussed above: issue #3801

1 Like
185

Yes, I did. After removing hue integration, restarting and adding it once more, it seems like the hue groups are working. However, those groups are not listed as entities managed by the Hue integration like before, when I had the integration configured in yaml.

186

Tried all kinds of stuff, removed HACS, still no joy. Downgrading back to .112.5 results in everything working again.

187

On the first boot after the upgrade I had the same Hue messages in my log. I rebooted a second time and the Hue integration is now OK.

188

Wow, what a huge improvement in the automations via yaml.

I have been rewriting many of my automations and reduced the number of individual automations by more than 100. Each of my Zigbee remotes had 2-8 automations each and I have quite many of them so that alone was a huge simplification.

If anyone wants to see the new syntax in automations then feel free to visit by Home Assistant Config on github.

The thing the documentation does not describe well is how to use the new “choose” syntax with events. All examples show state triggered automations.

For event this is how I implemented it. Full example on my github but here is the first part of a Hue Dimmer related automations

- alias: 'Bedroom Dimmer'
  initial_state: 'on'
  trigger:
    platform: event
    event_type: deconz_event
    event_data:
      id: bedroom_switch
  action:
    - choose:
      # Normal ON dimmed
      - conditions:
          - condition: template
            value_template: "{{ trigger.event.data.event == 1002 }}"
        sequence:
          - service: light.turn_on
            data:
              entity_id:
                - light.bedroom
              brightness_pct: 50
      # Long press full brightness
      - conditions:
          - condition: template
            value_template: "{{ trigger.event.data.event == 1001 }}"
        sequence:
            - service: light.turn_on
              data:
                entity_id:
                  - light.bedroom
                brightness_pct: 100

Rest of the automation in this example is in automations/bedroom_dimmer.yaml on my github

I also have an example where I use MQTT based automation from OpenMQTTGateway in the file automations/openmqttgateway.yaml

I hope these examples can help some less experienced in yaml automations

Thanks for this great release. What an improvement!

9 Likes
189

Yup; @mchangsp trick with a restart solved the issue. Thanks.

190

I too would love a list of variable names, I have tried searching for a list several times with no luck. My theme currently uses these paper entries and I will need to replace them at some point.

paper-card-header-color: ‘var(–primary-color)’
#paper-card-background-color: “rgba(0, 0, 0, 0.8)”*
ha-card-background: “rgba(0, 0, 0, 0.8)”**
card-background-color: “rgba(0, 0, 0, 0.8)”**

paper-dialog-background-color: ‘var(–primary-background-color)’
paper-item-icon-color: ‘var(–primary-color)’
paper-item-icon-active-color: ‘Gold’
paper-item-icon_-color: ‘Gold’
paper-item-selected-_background-color: ‘#282C34’
paper-tabs-selection-bar-color: ‘Gold’

Labels

#label-badge-red: ‘var(–primary-color)’
label-badge-text-color: ‘var(–primary-text-color)’
label-badge-background-color: ‘var(–paper-card-background-color)’

Switches

paper-toggle-button-checked-button-color: ‘var(–primary-color)’
paper-toggle-button-checked-bar-color: ‘var(–primary-color)’
paper-toggle-button-checked-ink-color: ‘var(–primary-color)’
paper-toggle-button-unchecked-button-color: ‘var(–disabled-text-color)’
paper-toggle-button-unchecked-bar-color: ‘var(–disabled-text-color)’
paper-toggle-button-unchecked-ink-color: ‘var(–disabled-text-color)’

Sliders

paper-slider-knob-color: ‘var(–primary-color)’
paper-slider-knob-start-color: ‘var(–primary-color)’
paper-slider-pin-color: ‘var(–primary-color)’
paper-slider-active-color: ‘var(–primary-color)’
paper-slider-container-color: ‘linear-gradient(var(–primary-background-color), var(–secondary-background-color)) no-repeat’
paper-slider-secondary-color: ‘var(–secondary-background-color)’
paper-slider-disabled-active-color: ‘var(–disabled-text-color)’
paper-slider-disabled-secondary-color: ‘var(–disabled-text-color)’

3 Likes
191

I seem to have the same problem. What gives?

I upgrade to 113 and then it seems to auto downrgade to 112.4.

192

My update does rollback as well. No clue why.

193

Likely out of disk space.

194

60 gb free.

195

What’s the log say?

196

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

197

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?

198

This update broke the Samsung TV integration. It now reports all my Samsung TV’s as on, regardless of true status.

199

It could be one of these:


200

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
201

Why did you not use data_template to handle these? Could simply them much more by doing that?

1 Like
202

I’m glad you’re finding the new automation features useful! :smiley:

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
203

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