0.115: B-Day release! Media browser, tags, automations & WTH

Blog
13

Happy birthday and great work!
Thanks for everyone involved. :slight_smile:

1 Like
14

Docs are all updated as Iā€™ve been following them in the beta, so it seems a lot of work being done on that side that is really appreciated.

3 Likes
15

The code editor in the UI is now theme-able, so make them look nice!

Is there a list of theme-able options for this (or should I just use the browser inspector)?

And does it work on the addon configuration code editor as well (I have a text visibility issue with my dark theme)?

plugins:
  - petrslavotinek-carpetplot-panel
env_vars: []
ssl: true
certfile: fullchain.pem
keyfile: privkey.pem

Untitled

Note the invisible colons and dashes.

2 Likes
16

Wow! Just reading the release notes alone takes an awful lot of time - hard to image how long itā€™ll take to adapt to all those good changes and enhancements.

This morning I was restling with using input_datetime in automations - only to now read that you have made this extremely simple. Complaint: why didnā€™t you tell me yesterday :wink:

Congrats to the team, this is awesome.

3 Likes
17

Incredible job everyone, so inspiring to see what a highly motivated, highly skilled team can do with OS collabs. Happy birthday too!

2 Likes
18

@tom_l, found them here.

  # Code editor
  #code-editor-background-color: grey
  codemirror-keyword: "#C792EA"
  codemirror-operator: "#89DDFF"
  codemirror-variable: "#f07178"
  codemirror-variable-2: "#EEFFFF"
  codemirror-variable-3: "#DECB6B"
  codemirror-builtin: "#FFCB6B"
  codemirror-atom: "#F78C6C"
  codemirror-number: "#FF5370"
  codemirror-def: "#82AAFF"
  codemirror-string: "#C3E88D"
  codemirror-string-2: "#f07178"
  codemirror-comment: "#545454"
  codemirror-tag: "#FF5370"
  codemirror-meta: "#FFCB6B"
  codemirror-attribute: "#C792EA"
  codemirror-property: "#C792EA"
  codemirror-qualifier: "#DECB6B"
  codemirror-type: "#DECB6B"

Auswahl_391

7 Likes
19

Fantastic release. Thanks to everyone committing their time to this project
One day I will know enough Python to help out

Happy birthday Home Assistant! :cake: :cake: :cake: :cake:

2 Likes
20

VESync finally supports the Levoit Air Purifiers! My life is now complete. Been waiting FOREVER for that to come along.

So, after running 0.115 for about 15 minutes, I have to say, Iā€™m REALLY impressed with this build so far. So many QOL changesā€¦ Thank you DEVS for the amazing amount of work you guys put into this build.

1 Like
21

Superb release!
Imā€™ in HA from early this year and i must say, truly amazing ! Keep it up !
Thx guys

1 Like
22

Great Job!

I see now Shelly has an official integration: does anyone know how to migrate to it from ShellyForHass?

3 Likes
23

The yr sensor is removed, but available as a custom component here:

Adax heaters are now available as a custom component:

6 Likes
24

Iā€™m going to have to go back and finish reading that whole post, but my big question is: ā€œCan we use templates in the variables sectionā€? i.e., set a variable to a templated value?

Iā€™ll be able to shorten so many of my automations because every service call has to set the same jinja2 variables.

25

Special thanks to Frenck for composing a well-organized blog post for this release. :+1:

Despite 0.115 having a boatload of enhancements, the post presented all the major improvements, and breaking changes, clearly and concisely. Undoubtedly, it was a daunting task to distill all of that material down to an easily digestible form.

20 Likes
26

Am I looking in the wrong place? I went to https://www.home-assistant.io/docs/automation/trigger/ to look for the new wait_for_trigger functionality and did not see it.

27

@James_Huang Itā€™s mentioned here: https://www.home-assistant.io/docs/scripts/#wait-for-trigger

28

If I understood the changes correctly, I believe you can template variables. However, I didnā€™t get the impression they are global so a variable defined in one automation is not accessible to another. I plan to experiment with this, and much more, in the near future (my test system is upgrading itself at this very moment).

1 Like
29

No, I meant in the same automation: example:

automation:
  alias: do_stuff
  trigger: whatever
  variables: 
    var1: "{{ some state-related thing }}"
  action:
    - service: my.service
      data:
        parameters: "{{ var1 }}"
    - service: my.otherservice
      data:
        another_parameter: "{{ var1 }}"

Previously, you would have to define var1 in EVERY template you wanted to use it in, even if they were in the same service call! Just having a variable that is valid for the current automation or script is HUGE.

2 Likes
30

Ah, I misunderstood; yes, I believe that should work.

Another useful enhancement is the new way the expand function is handled in a Template Trigger and Template Sensor. Itā€™s a seemingly inauspicious improvement but it has the potential to dramatically simplify the way we currently compose certain templates. Itā€™s an improvement Iā€™ve been looking forward to since it was first introduced (albeit unsuccessfully) in version 0.110.

31

I got the same impression, but donā€™t know for sure, yet.

32

That is also my impression, but Iā€™m totally OK with that. I think if you want to use something across different automations, it should be an input type (notwithstanding the 255 character state limit, of course :stuck_out_tongue: )