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. 
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.
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 
)
it isn’t global, this is the first step. As mentioned in the release notes, the WTH isn’t resolved fully yet.
4 Likes
WTH 
Big thanks to everyone involved 
1 Like
Yes they do, they also are processed in order, so the variable (template) first listed, can be used in the second listed variable (template)
As an example / personal playground I’ve been playing with variables and some of the new automations features. This script shows a bit of what it is capable off:
6 Likes
That is one damn fine example of the power of the new local variables feature. Attempting to do that without variables would be a lot messier. I also like the rarely seen (at least on this forum) usage of supported_features. Thanks for that.
1 Like
I would appreciate if there are more use cases/real-world examples included in docs as well.
2 Likes
If I understood correctly we can replace data_template by data, data_service by service but we keep the data_value as is?
service_template can now be abbreviated as service
data_template as data
Where have you seen the other options you mentioned?