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

[nickrout]

OTOH I can see value if an error message tells you something about why your template fails.

[sparkydave (🇦🇺 Dave)]

Definitely. That info should just be shown on the template editor window though

[Holdestmade]

Definitely. That info should just be shown on the template editor window though

I think this would be very helpful

[DavidFW1960 (David)]

@sparkydave

That info should just be shown on the template editor window though

Yep. That’s the only place it’s even useful…

[lindsayward]

I’d like to add my vote of thanks for everyone who contributed to this release.
In particular:
@Frenk - I know a few people didn’t read the breaking changes but I found the use of
"Instead of … use …"
a really good way to show what and how to change. I updated my Broadlink with no problems thanks to this. Thanks!

@pnbruckner - Before this release, I had a “simple” time trigger based on an input_datetime:

# BEFORE
  trigger:
  - platform: template
    value_template: '{{ states.sensor.time.state == (states.input_datetime.coffee_start_time.attributes.timestamp | int | timestamp_custom("%H:%M", False)) }}'

# AFTER
  trigger:
  - platform: time
    at: input_datetime.coffee_start_time 

SO much nicer!

[klogg]

@Coolie1101

why does HA log it as an error

It is actually even more annoying than that.
Just try typing slowly in the Telmplate Editor and watch your logs…

Bug/annoyance in new Template Editor

First off I love the new functional Template Editor so don’t take this the wrong way but there is a bug/annoyance which might have been overlooked. Go to the editor and start typing e.g. {{ states('sensor. pause while the editor does it’s magic and updates giving: [image] …and then check your log. You’ll find that error is also logged there. Type slowly or use the editor a lot and you can get tons of errors. Couldn’t errors from the template editor be supressed in the log?

[Coolie1101 (Coolie)]

That’s what caught my attention.

[BeardedConti (BeardedTinker)]

@acortesm

- id: Telegram test
  alias: Telegram - test
  trigger:
  - platform: event
    event_type: telegram_callback
    event_data:
      data: /test_1
  action:
  - service: notify.telegram_id_{{ trigger.event.data.user_id }}
    data:
      message: 'Test'
  - service: notify.telegram_id_{{ trigger.event.data.user_id }}
    data:
      message: 'Trigger event info: {{ trigger.event }}'   
  - service: notify.telegram_id_{{ trigger.event.data.user_id }}
    data:
      message: 'Data: {{ trigger.event.data.data }}' 

Did you try to add target?

for ex.

  action:
  - service: notify.telegram_id_{{ trigger.event.data.user_id }}
    data:
      message: 'Test'
      target: CHANNEL_ID

I think that before you didn’t need to specify it and it used first from the list, but now you have to add it.

[Mariusthvdb (Marius)]

in the ongoing process of rewriting templates and automations triggers and conditions to replace templates, I was wondering if rewriting below condition without template

condition:
  - condition: template
    value_template: >
      {{states('device_tracker.life360_marijn') != 'home'}}

would need to be done like:

condition:
  condition: not
  conditions:
    - condition: state
      entity_id: device_tracker.life360_marijn
      state: 'home'

we cant leave out ‘conditions:’ can we? even if this would be the only one?

and if this set of Not conditions were to be part of the larger set of conditions, write it like this:

    condition:
      - condition: state
        entity_id: input_boolean.espresso_notified
        state: 'off'
      - condition: time
        after: '06:00:00'
        before: '22:00:00'
      - condition: not
        conditions:
          - condition: state
            entity_id: device_tracker.life360_marijn
            state: 'home'

?
though that still seems a bit more complex than

condition:
  - condition: >
      {{states('device_tracker.life360_marijn') != 'home'}}

which if I understand it correctly is now possible too… suppose that won’t be less efficient for the system.

[tom_l]

@Mariusthvdb

we cant leave out ‘conditions:’ can we? even if this would be the only one?

No, you cant. Neither for the next example. Think of it like the AND and OR condition logic.

@Mariusthvdb

though that still seems a bit more complex than

Only if you understand jinja.

[Mariusthvdb (Marius)]

@tom_l

Think of it like the AND and OR condition logic.

ok thanks and yes, was confused there because conditions are being AND’ed by default so don’t need that kind of attention.
still if the single line

conditions:

were to be taken out, it would still be clear to be a set of conditions under the condition: not block?
sorry my bad: this is wrong:

@Mariusthvdb

condition:
  - condition: >
      {{states('device_tracker.life360_marijn') != 'home'}}

needs to be:

      - >
          {{states('device_tracker.life360_marijn') != 'home'}}

or on 1 line:

      - "{{states('device_tracker.life360_marijn') != 'home'}}"

@tom_l

Only if you understand jinja.

well, yes, I guess you’re right there.

hope we can soon use the shorthand way for templates in triggers too! and the expand() on state.

[klogg]

Leading on from that (and I think this just exposes a lack of understanding on my part with the way things are expressed) does this work?

  condition:
      - condition: not
        conditions:
          - condition: state
            entity_id: trigger.to_state
            state: 'home'

[tom_l]

Not sure, trigger.to_state is a state object not an entity. I’m going to say probably not. Try it and see.

[HouseOfCards]

Same here. Just filed a bug. Log is filled with errors about Pillow and PIL, and all sorts of nonsense. Had to roll back to a snapshot to recover.

It died on the same day as it’s birthday…

[Mariusthvdb (Marius)]

another one please…:

   # trigger:
   # -----
    condition:
      >
        {{trigger.to_state.state|int in [0,1]}}
    action:
      - service: notify.notify
        data:
          title: All ok
          message: Still fine
      - condition: # <----    why is this wrong?
          >
            {{trigger.to_state.state|int == 0}}

The first condition (the condition block) works fine (that is, config check ok’s it). But when I try to use the same syntax in the action block, it wont go.

Only this works:

- condition: template
  value_template: >
    {{trigger.to_state.state|int == 0}}

I’ve also tried:

- >
    {{trigger.to_state.state|int == 0}}

and

      - condition: '{{trigger.to_state.state|int == 0}}'

doesnt the shorthand yet work in the listed action block?

[anon43302295]

- "{{trigger.to_state.state|int == 0}}"

(I had the same problem further up the thread, or maybe in a different thread)

[yonny24]

Glad I’ve managed to get upgraded now smoothly after initial issues with broadlink and history stats. History stats is still in my custom components folder with just the unit_percentage changed to percentage nothing else.

But still unsure whether that is a custom component anymore and can get rid of it.

[ptdalen]

I apologize if this has been asked, I skimmed and searched but not find any answers. Prior to 115, Any cameras i displayed in lovelace using a picture entity card, could grow to full size by doing a long hold on my phone, or a click/hold on my browser. I notice that is not working anymore. I have two instances of HA running, but with the same cameras and same lovelace. 114.x works as before 115.2 does not. Is there a new option/feature/breaking change I need to read up on? Any assistance is appreciated

[sparkydave (🇦🇺 Dave)]

Is anyone else having trouble with the Xiaomi Vacuum component since 0.115?

2020-09-24 08:25:53 WARNING (SyncWorker_19) [homeassistant.components.xiaomi_miio.vacuum] Got exception while fetching the state: Unable to discover the device 192.168.0.152

[finity]

I just updated to v115.

Does anyone know if the update breaks the custom variable component (rogro82/hass-variables)?