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

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

1 Like

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

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

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

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

2 Likes

@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

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

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

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

1 Like

Great Job!

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

3 Likes

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

Adax heaters are now available as a custom component:

6 Likes

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.

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

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.

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

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

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

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.

I got the same impression, but don’t know for sure, yet.

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: )