0.113: Automations & Scripts, and even more performance!

Correct. I added it to my sidebar as a test and it generated the error. Will probably be fixed with the next VScode update as mentioned.

You can ask the author of the extension to update the schema to include the new features.

Here: https://github.com/keesschollaart81/vscode-home-assistant/issues

Or you can do it yourself locally: https://github.com/keesschollaart81/vscode-home-assistant/wiki/HowTo:-Update-the-schema's

Hey guys,

I noticed some strange German translations within the “Server Management”-Page:

“Reload Input Booleans”
“Reload Input Numbers”
“Reload Input DateTime”
etc.

They’re called
“Eingabe-Booleans neu laden”
“Eingabenummern neu laden”
“Eingabe-Datums- und Zeitfelder neu laden”
etc…

In my opinion this is a strange german wording:

My suggestion here is:

“Umschalt-Helfer neu laden”
“Nummern-Helfer neu laden”
“Text-Helfer neu laden”
“Datum & Uhrzeit-Helfer neu laden”
“Dropdown-Helfer neu laden”

The functions are already translated within the "Helpers-Menu, the current translation kind of differs from these “Helpers-Menu”-translations in strange ways.

Am I the only one? :slight_smile:

New :bug: bug :tada: introduced in this release. I would post it on github but I was blocked (by @balloob) because of my last feature request for the android app to make it accesible :wheelchair: for more people - sad but true. Wonder what the Code of Conduct is actually for… :man_shrugging:

The bug is the following (reproduced on two different hass servers and various clients, mobile & desktop as well with various browsers and the android app Libre Assistant)

Opening any entity in lovelace, for example this one:

image

And clicking the wheel :wheel_of_dharma: up right:

followed by a click on the tab “related” will give you this nice list of related entities:

they are clickable and in the past (prior to this release 0.113) they opened the entity directly.

The new behavior is that it’s not presented in front of this modal but behind - which is quite useless :wink:

1 Like

Just tried it out. It opens indeed behind the modal. Tested on 0.113.1.

Or just this:

            value_template: "{{ trigger.to_state.state  == 'Button B' }}"
1 Like

Thank’s for confirming… hope some one will see this one day…

Just to be clear; this means a few idiots willing to break their test instances (with alpha code)
And does not refer to the quality of those testers
:rofl:

2 Likes

Thank you @123 , that works great!

the more-info pop-ups on AirVisual card no longer work. Anyone else seeing this?

IKEA integrations - Any body else having isues with the ikea integration? in 0.113 i need to re-integrate my two ikea gateways to have connection to the lights. this has to be done again after a while.

A couple of quick optimizations:

  trigger:
  - entity_id: sensor.remote2
    platform: state
  - entity_id: sensor.remote4
    platform: state

can be:

  trigger:
  - entity_id:
    - sensor.remote2
    - sensor.remote4
    platform: state
          - condition: template
            value_template: "{{ states[trigger.to_state.domain][trigger.to_state.object_id].state  == 'Button A' }}"

can be:

          - condition: template
            value_template: "{{ trigger.to_state.state == 'Button A' }}"
1 Like

Partial echo. :wink:

1 Like

Probably a better way to implement this is:

- trigger:
  - platform: state
    entity_id: binary_sensor.laundry_door_sensor
    to: 'on'
  action:
  - service: light.turn_on
    entity_id: light.laundry_lights
- trigger:
  - platform: state
    entity_id: binary_sensor.laundry_door_sensor
    to: 'on'
    for: '00:05'
  - platform: state
    entity_id: binary_sensor.laundry_door_sensor
    to: 'off'
  action:
  - service: light.turn_off
    entity_id: light.laundry_lights
1 Like

Thank you, I appreciate the feedback.

That’s the first time I’ve seen multiple triggers defined that way. That’s always been available? How have missed this?!? :man_facepalming: I’m going to have to experiment with it.

No, those are two automations.

Great tip!!

Well OK then. At least I didn’t sleep through some major enhancement.

If that’s two separate automations, why are the trigger options hyphenated?

To clarify, by hyphenating the two trigger statements, it gives me the impression I can have a single automation that supports multiple “sub-automations” where each has its own set of trigger/condition/action.

The assumption was the original code snippet (and hence my suggested change) was in the default automations.yaml file, which must contain a list of automations, where the start of each automation begins with a dash, which delineates a new list element.

I could have suggested this:

automation:
- trigger:
  ...
- trigger:
  ...

to try and make it clearer, but then people try putting the first line (automation:) into automations.yaml, too, and of course, that doesn’t work.

You can’t win here! :wink: