0.118: Grid and logbook cards, quick navigation, native template types

[stigvi]

• Date pickers in entity cards have been replaced with a modern, good looking version. Thanks, @thomasloven!

Nice. Is it possible to have weeks start with monday?

[mostlychris (Chris)]

Just upgraded to .118 and HACS broke:

Logger: homeassistant.setup
Source: setup.py:138
First occurred: 3:01:34 PM (1 occurrences)
Last logged: 3:01:34 PM
Setup failed for hacs: Unable to import component: cannot import name 'system_health_info' from 'homeassistant.components.lovelace' (/usr/src/homeassistant/homeassistant/components/lovelace/__init__.py) ```

[bdraco (J. Nick Koston)]

Update HACS

Edit: You can manually reinstall using https://hacs.xyz/docs/installation/manual

[mostlychris (Chris)]

Since it doesn’t load, there is no link to that. How do I upgrade with no link.

[123 (Taras)]

Be advised that there’s an Issue that had been reported for 0.118 beta that is present in the release version (0.118.0).

input_datetime is in UTC and not local time zone in 0.118b3

You are likely to be affected if you have templates that employ an input_datetime’s timestamp attribute. For example, paste this into Template Editor (and change the entity’s name):

{{ states('input_datetime.test') }}
{{ state_attr('input_datetime.test', 'timestamp') | timestamp_local() }}

If you are using 0.117.X, the two times will be identical.

Here’s what it reports in 0.118.0:

The 5-hour discrepancy corresponds to the offset between my local time and UTC. The two times are no longer identical.

What this means is that an input_datetime’s state shows the time you set (either via the UI or a service call) and corresponds to local time. However, attempting to get this time via the timetamp will now result in UTC time and not the local time. This is not how it worked in the past so it’s either a bug or an undocumented Breaking Change.

[Sonnstein (Albert Sommer)]

exactly the same situation in my system!

[matteos1 (Matteo)]

There is news regarding coffe machine shiscare by xiaomi in miio library.

[mostlychris (Chris)]

I am watching the release stream and basically all of us that haven’t updated HACS in a few weeks got schooled, lol.

I did this to upgrade:

1. SSH into HA or open a terminal.
2. Run the command here in the same directory as your configuration.yaml: https://hacs.xyz/docs/installation/manual_cli

[pergola.fabio]

Seems now i have a camera in the Google NEST integration? i dont see it in the release notes? when was it added? its the camera from my google hub

dont remember seeing it in 117.x

[mostlychris (Chris)]

.118 contains upgrades to the integration, including fixing the update issue that was not working in .117.

[Cadster]

To buy a ticket to the conference.
I don’t have a creditcard, would it be posible to make payments with paypall?

[Mariusthvdb (Marius)]

@123

If you are using 0.117.X, the two times will be identical.

hmm, not here (117.6):

guess the date is because it has no date set, but I was referring mostly to the +1 hour time difference

[123 (Taras)]

If you check the Issue’s comments you’ll see that even balloob reported different results (for 0.117.X) and indicated the code is a “bit of a mess”.

The example I provided is an input_datetime with both time and date. If it only includes time (like in your example) then the timestamp backdates to the 1st of January 1970. Try the test with an input_datetime that includes both time and date.

[Mariusthvdb (Marius)]

yeah, see my comment in the edited post.

have only one other date_time, which is created thus:

  - alias: Last Template Reload
    trigger:
      platform: event
      event_type: event_template_reloaded
    action:
      service: input_datetime.set_datetime
      data:
        entity_id: input_datetime.template_reloaded
        timestamp: >
          {{as_timestamp(trigger.event.time_fired)}}

hence maybe another discrepancy:

guess I am safe to update, my sleeptime is way beyond this anyway

[DarthSebulba04 (Chris)]

Looking good! Nothing broken!

Can’t wait to try out the new grid card with all my cameras.

[123 (Taras)]

FWIW, it appears that the behavior of input_datetime, that handles time but not date, is unchanged between 0.118.0 and previous versions: I get this for both 0.117.5 and 0.118.0

The 5-hour difference corresponds to the offset between my local time and UTC.

The problem here is that the template uses timestamp_local() and not timestamp_utc() yet is reporting a UTC time. That means the “wires are crossed” somewhere because when you ask for local time you shouldn’t get UTC time.

• Filter timestamp_local converts an UNIX timestamp to its string representation as date/time in your local timezone.
• Filter timestamp_utc converts a UNIX timestamp to its string representation representation as date/time in UTC timezone.

---

EDIT

Guess what happens when you use timestamp_utc()?

It means it handles the time you enter, in an input_datetime, as being in UTC time and not your local time. So the timestamp is literally the time you entered and is not converted from local to UTC.

My guess is most people who set an input_datetime to something like 08:30 assume it represents their local time and not UTC. Big surprise if you set an automation to trigger based on the input_datetime’s timestamp and convert to local time!

[DavidFW1960 (David)]

Really good release. Thanks!

[pollinolas]

Justo update it,its solved with the v.0.014

[kanga_who (Jason)]

Smooth update, no issues to report so far on 4 different installs.

[nick2525]

Header & Footer Editor > you should add a slider for distance in pixels below and above, since sometimes the distance to the graph is too large. But better to make overlay of graph to entities