I only used that example as it was the only one I had with one condition and I canāt copy and paste from my config currently, so if youāre saying that it goes directly in line with the condition block of an automation, where would I put the second, third etc conditions?
Also, thatās not how itās documented, its documented as where the conditions go, not the condition block of an automation.
Iām confused.
You have tried it with
condition:
condition: "{{ trigger.to_state.state != 'off' }}"
and
condition:
conditions: "{{ trigger.to_state.state != 'off' }}"
and i think you should try it with that, if you have multiple conditions:
conditions:
condition: "{{ trigger.to_state.state != 'off' }}"
But conditions isnāt a valid key for the condition block of an automation 
, would love to see someone with an actual full working example that passes the configuration check please.
I was confused as well (and not sure I grasp it 100% now), but with a little trial-and-error found out the above syntax works.
And if you have more than one templated condition you either change each of them using the same single-line syntax, or you make a list out of them, like so:
condition:
- "{{ condition1 }}"
- "{{ condition2 }}"
Standby, Iāll try thatā¦
Yeah, I missread my own config, sorry about that.^^
Can confirm that this worksā¦
condition:
- "{{ trigger.to_state.state != 'off' }}"
Or certainly passes the configuration check, will have to wait and make sure theyāre definitely applied
Not sure why the docs suggest that you need āconditions:ā in front of it
Anyway, thanks both, got there in the end 
Check Configuration fails and restart server too. Need to do a full restart to aply some changes to me to.Any solution?
I solved it deleting sonoff integration via HACS. After deleting it everything started to work. Then I used AlexxIT repository to install sonoff integration again and no problems.
Maybe you donāt have sonoff but there is some custom component failingā¦ Try this and good look!! 
First of all, thank you for the great work and lots of new features. Somewhat disappointed that the last few releases are aimed at working through the UI. An increasing number of integrations require configuration via the interface. I would like to have a free choice between yaml and UI. I donāt like these āautonamesā for entities. This is very inconvenient when you want to āstart from draftā or after reinstalling some integrations. After such cases, you open the log and try for hours to understand what is happeningā¦
That ship has sailed and itās not coming back.
Thanks.Solved.
Great Release!!! Wow!! Thanks to all for your effort 
I just have a problem with Broadlink Switchesā¦ I add my RM+ remote in the integrations menu, and change all my switch with the new yaml format, but none of them are created now.
and follow all steps in the documentation, but I really donāt know what is the problemā¦ And there isnāt any error in logs.
Anyone with this issue too?
Had to drop back to 0.114.4
all āUnavailableā.
Reloading templates didnāt help 
Thanks for your update, but a have a problem with integration of the āCustom Componentā, in the particular the component āSonoffā by peterbuga in the version 0.114.4 the component it works!, but in the version 0.115.1 the component are not works, I view the log of my home assistant are see error in install package āuuidā. I attached this line on log
Logger: homeassistant.util.package
Source: util/package.py:95
First occurred: 14:43:17 (1 occurrences)
Last logged: 14:43:17
Unable to install package uuid: ERROR: Could not find a version that satisfies the requirement uuid==1000000000.0.0 (from -c /usr/src/homeassistant/homeassistant/package_constraints.txt (line 51)) (from versions: 1.30) ERROR: No matching distribution found for uuid==1000000000.0.0 (from -c /usr/src/homeassistant/homeassistant/package_constraints.txt (line 51))
Logger: homeassistant.setup
Source: setup.py:138
First occurred: 14:43:17 (1 occurrences)
Last logged: 14:43:17
Setup failed for sonoff: Requirements for sonoff not found: ['uuid'].
Thanks for the excelent product
Indeed after removing ShellyForHass and then restarting HA, my Shelly devices were discovered and appeared on the Integrations-page.
Noticed that one of my template sensors is not updating anymore since removing the entity_id field in 0.115.
This was the template
greeting:
# entity_id: sensor.time
friendly_name: 'Begroeting'
icon_template: mdi:human-greeting
value_template: >
{% set t = now().strftime("%H")|int %}
{% if 0 <= t < 6 %}
Goedenacht
{% elif 6 <= t < 12 %}
Goedemorgen
{% elif 12 <= t < 18 %}
Goedemiddag
{% else %}
Goedenavond
{% endif %}
It works again after I changed
{% set t = now().strftime("%H")|int %}
to
{% set t = states.sensor.time.state.split(':')[0]|int %}
so it has a state change to listen to.
Apparently we are using the template sensors in some unexpected ways 
Take a look at the āWORKING WITHOUT ENTITIESā section here for some additional ideals.
You can also use the new as_local like this to replace now() in places you want the template to update when sensor.time updates:
as_local(states.sensor.time.last_changed)
You used to include sensor.time in entity_id. Now that entity_id is deprecated, simply include sensor.time in your template. Hereās an easy way to do it:
greeting:
# entity_id: sensor.time
friendly_name: 'Begroeting'
icon_template: mdi:human-greeting
value_template: >
{% set t = as_local(states.sensor.time.last_updated).hour %}
{% if 0 <= t < 6 %}
Goedenacht
{% elif 6 <= t < 12 %}
Goedemorgen
{% elif 12 <= t < 18 %}
Goedemiddag
{% else %}
Goedenavond
{% endif %}
This reports the last time sensor.time was updated.
states.sensor.time.last_updated
However, the time it reports is UTC time. We want local time so we use the new as_local() function in 0.115:
as_local(states.sensor.time.last_updated)
Now we have a datetime object reporting local time and date. For your purpose, you just need the hour and so we use the datetime objectās hour method:
as_local(states.sensor.time.last_updated).hour
I know, the solution using sensor.time is in my post as well