Small typo in release notes under the “Notion” section, it refers to “Flu Near You” - copy paste error 
What happened with fonts, now it is notably smaller? Also, does anyone consider that colours in standard dark theme are mismating and look quite ugly? Maybe it is up to someone taste, but the new UI doesn’t look clean.
Does those people who work on Shelly aware of https://github.com/StyraHem/ShellyForHASS ? I’ve been using it for more than year and seems it quite stable
4 Likes
updated, all working fine, except for the new feature for synology dsm
i think this new PR: https://github.com/home-assistant/core/pull/42378
get error below
2020-11-18 21:47:51 ERROR (MainThread) [homeassistant.components.binary_sensor] Error adding entities for domain binary_sensor with platform synology_dsm
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 316, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 507, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 531, in add_to_platform_finish
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 296, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 320, in _async_write_ha_state
sstate = self.state
File "/usr/src/homeassistant/homeassistant/components/binary_sensor/__init__.py", line 158, in state
return STATE_ON if self.is_on else STATE_OFF
File "/usr/src/homeassistant/homeassistant/components/synology_dsm/binary_sensor.py", line 87, in is_on
return getattr(self._api.upgrade, self.entity_type)
File "/usr/local/lib/python3.8/site-packages/synology_dsm/api/core/upgrade.py", line 23, in update_available
return self._data["update"].get("available")
KeyError: 'update'
2020-11-18 21:47:51 ERROR (MainThread) [homeassistant.components.binary_sensor] Error while setting up synology_dsm platform for binary_sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 207, in _async_setup_platform
await asyncio.gather(*pending)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 316, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 507, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 531, in add_to_platform_finish
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 296, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 320, in _async_write_ha_state
sstate = self.state
File "/usr/src/homeassistant/homeassistant/components/binary_sensor/__init__.py", line 158, in state
return STATE_ON if self.is_on else STATE_OFF
File "/usr/src/homeassistant/homeassistant/components/synology_dsm/binary_sensor.py", line 87, in is_on
return getattr(self._api.upgrade, self.entity_type)
File "/usr/local/lib/python3.8/site-packages/synology_dsm/api/core/upgrade.py", line 23, in update_available
return self._data["update"].get("available")
KeyError: 'update'
- 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?
4 Likes
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) ```
8 Likes
Update HACS
Edit: You can manually reinstall using https://hacs.xyz/docs/installation/manual
2 Likes
Since it doesn’t load, there is no link to that. How do I upgrade with no link.
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).
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.
1 Like
exactly the same situation in my system!
There is news regarding coffe machine shiscare by xiaomi in miio library.
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:
- SSH into HA or open a terminal.
- Run the command here in the same directory as your configuration.yaml: https://hacs.xyz/docs/installation/manual_cli
7 Likes
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
1 Like
.118 contains upgrades to the integration, including fixing the update issue that was not working in .117.
To buy a ticket to the conference.
I don’t have a creditcard, would it be posible to make payments with paypall?
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
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.
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 
Looking good! Nothing broken!
Can’t wait to try out the new grid card with all my cameras.
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_localconverts an UNIX timestamp to its string representation as date/time in your local timezone. - Filter
timestamp_utcconverts 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!