2020.12: Automate with Blueprints!

[stigvi]

FYI:

On my system, it took version 2020.12.0 about one hour to start the first time after the upgrade. I see in the log it was working with upgrading the database schema.

[SamKr]

I’m thinking it might be better having an automation using homeassistant.start as its trigger, with a five minute (or in your case, one) delay, to flip an input boolean. And then use that boolean as the condition.

[owie_b (Owie Baclay)]

uptime sensor in minigraph after update to 12.0, it is not showing in hours anymore

[cepxuo (Sergio Rueda)]

Hi Everyone and happy upcoming holidays!

Is there any plan to bring EZVIZ integration back to life again?

[vacar (Vanni Carletti)]

Rebooted twice and HACS still not showing up:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/setup.py", line 213, in _async_setup_component
    result = await task
  File "/config/custom_components/hacs/__init__.py", line 24, in async_setup
    return await hacs_yaml_setup(hass, config)
  File "/config/custom_components/hacs/operational/setup.py", line 83, in async_setup
    await async_startup_wrapper_for_yaml()
  File "/config/custom_components/hacs/operational/setup.py", line 120, in async_startup_wrapper_for_yaml
    async_call_later(hacs.hass, 900, async_startup_wrapper_for_yaml())
  File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1179, in async_call_later
    return async_track_point_in_utc_time(
  File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1133, in async_track_point_in_utc_time
    job = action if isinstance(action, HassJob) else HassJob(action)
  File "/usr/src/homeassistant/homeassistant/core.py", line 174, in __init__
    raise ValueError("Coroutine not allowed to be passed to HassJob")
ValueError: Coroutine not allowed to be passed to HassJob

Thanks for the update, good job ! Apart the HACS issue, it ran smoothly as usual !

[nigelc (Nigel)]

I have the same problem as Juhurus Update failed - cant find registry-1.docker.io

[tom_l]

Read the release notes.

Uptime

In order to optimize stability and performance of Home Assistant, sensors should use only absolute time values (store the date of the event) and not relative time values (seconds from event) so the value doesn’t change each second.

The Uptime integration is one leftover, so to adhere to Home Assistant architectural design rules, the sensor is now changed to a timestamp.

As a side effect of this change, the unit_of_measurement option of this integration is now deprecated and can be removed from your configuration if you used that.

Please review your Automations and Lovelace configuration to reflect this change.

(@chemelli74 - #43623) (uptime docs)

[Mariusthvdb (Marius)]

trying to rebuild the uptime hours and minutes sensors from before, using

{{ (((as_timestamp(now()) - as_timestamp(states('sensor.time_online'))) % 3600) / 60) | int  }}

based on:

sensor:
  - platform: uptime
    name: Time Online

won’t auto update in the template editor?

[owie_b (Owie Baclay)]

Already did that but still the same

[Holdestmade]

@Mariusthvdb

trying to rebuild the uptime hours and minutes sensors from before, using

{{ (((as_timestamp(now()) - as_timestamp(states('sensor.time_online'))) % 3600) / 60) | int  }}

based on:

sensor:
  - platform: uptime
    name: Time Online

won’t auto update in the template editor?

This seems to update every minute:

Uptime in days hours and minutes

Something like this ? EDIT: this doesn’t update in template editor, not sure if it will when it’s a sensor ? EDIT: yes it does, every minute EDIT 2: just added the default uptime sensor, the entity in lovelace already shows the time in hours and mins - platform: template sensors: ha_uptime: friendly_name: "Home Assistant uptime" value_template: >- {% set up_time = as_timestamp(now()) - as_timestamp(states('sensor.ha_uptime')) %} {% if up_time == 0 %} …

[tom_l]

@owie_b

Already did that but still the same

Already did what?

The entity is no longer a time (duration) since last restart it is now a time-stamp of when the last restart occurred, e.g. 2020-12-14 21:24:33.745303+11:00 You can’t graph this, it won’t change until you restart again. You need to create a template sensor that determines the time between now and that timestamp.

[Mariusthvdb (Marius)]

maybe updating in the state machine, but ive been looking at this now for 3 minutes being 15 minutes…

{{relative_time(states.sensor.uptime.last_changed)}}

note: I’ve renamed the sensor to sensor.uptime, not a different sensor, just the core sensor uptime

[owie_b (Owie Baclay)]

Sorry I mean I already edited my configuration.yaml, I thought that it would display the correct value like the image above when i create a entity card. I’m having a hard time trying to figure out a sensor for this.

[Bram (Bram van den Hout)]

This template sensor will get it back to work.
Replace hostname with yours

- platform: template

  sensors:

    cert_expiry_<hostname>:

      friendly_name: "Cert Expiry Days (<hostname>)"

      value_template: "{{ (  (as_timestamp(states.sensor.cert_expiry_timestamp_<hostname>.state) - as_timestamp(now())  ) / 86400 ) | round(0, 'floor') }}"

      unit_of_measurement: 'days'

[Bram (Bram van den Hout)]

see my post just now to get cert expiry sensor (with days left before invalid cert)

[maxym]

@Michael_Davydov

I gotta say, the versioning scheme change made me laugh When everyone was expecting it to jump into “Released” state by going 1.0, it just got changed to date based system.

Which will cause that newer version of HACS will never be released
From HACS changelog:

• This release will be the last one that has a beta, it’s just too much work to maintain.
• The next planned version (1.9.0) will have HA 1.0.0 as the minimum required version.

[Holdestmade]

Yes, same here, tried making a template sensor with that template of yours and it doesn’t update. The one I posted does though so is it the now() part that is making it update ?

[mcarty (Arturo)]

Is there any way to watch now the Home Assistant Conference? I got my ticket but had to leave after 1 hour.
Sorry for the off-topic.

[KennethLavrsen]

Making a sensor like this - as far as I cana tell - re-creates the problem that each time it updates, it gets logged. That is a lot of data to say that time has passed another minute or worse second.

When you upgrade the old Certificate sensor no longer works and can be deleted (in the entity window there is a delete button that is active)

A new sensor is created which is called sensor.cert_expiry_timestamp_domain_name where domain_name is your actual domain name. Ie the string timestamp is added.

In the front end this sensor is shown in a sensible way when shown in a standard entity card. It actually shows how much time till it expires and it shows in in a very human way like “in 5 weeks”.

That works well. What is not (yet) implemented well is showing the timestamp in a badge. The text is the time stamp and it overflows after 2020. and is useless. I don’t care. I moved from badge to entity anyway. But if someone really wants the badge I encourage you to raise a github issue. It really should show the days left as it will fit in the little circle.

I do not see any reason why one would graph a certificate expiry.

[Mariusthvdb (Marius)]

filed an issue to be sure https://github.com/home-assistant/core/issues/44214