After upgrading to 0.97, the ROKU platform is creating the following error:
2019-08-08 07:29:45 ERROR (MainThread) [homeassistant.setup] Error during setup of component roku
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/setup.py", line 172, in _async_setup_component
component.setup, hass, processed_config # type: ignore
File "/usr/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/roku/__init__.py", line 56, in setup
_setup_roku(hass, config, conf)
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/roku/__init__.py", line 97, in _setup_roku
from roku import Roku
File "/srv/homeassistant/lib/python3.7/site-packages/roku/__init__.py", line 1, in <module>
from roku.core import Roku, Application, Channel, RokuException, __version__
File "/srv/homeassistant/lib/python3.7/site-packages/roku/core.py", line 4, in <module>
from lxml import etree as ET
ImportError: libxslt.so.1: cannot open shared object file: No such file or directory
My setup is: Hassbian (Buster), Python 3.7
Under Beta Fixes I see @pvizeli made a change
Agreed 100%. And I think it goes beyond the upgrade examples. The HA documentation in general is more like a programmers reference guide, often showing the minimum amount necessary to get the idea across (i.e. assuming that someone is quite knowledgeable about HA, it’s syntax, etc).
I’ve been running HA for over a year and still struggle considerably with even simple stuff - usually relying on finding other forums discussions, or digging through github to find example configurations.
With 1.0 quickly approaching, the massive publicity will draw massive numbers of new people, and the forums are going to be flooded with simple questions that could have been answered via more complete examples in the documentation.
in config yaml and restarted and got a notification about setting up calendars, copied the code and it went to google to authorise the connection. No idea why it stopped working but works now
I have the same issue, in the logging I see the following:
2019-08-08 18:05:19 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 400, in _async_add_entity
await entity.async_added_to_hass()
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/filter/sensor.py", line 258, in async_added_to_hass
for state in filter_history[self._entity]
KeyError: 'sensor.power_consumption1'
I don’t understand the UniFi presence detection changes. After upgrade, devices on my unifi network all show as away. What needs to be changed in my config for this latest update?
EDIT: Looks like it just adds all the devices by name on the router so I will have to change the names of some of my entities that I had pre-configured.
I wonder if this renaming only occur if you have a UniFi router?
I have a couple of UniFi access points and UniFi switches and use pfSense as the edge router that hands out DHCP leases to clients. Tracking these devices by MAC address has worked really well for some time, I hope that continues to be the case.
I have a USG and that is the integration that gets all the names and other connection info. The change is that all items in that router now show as device trackers along with the name I assigned that device in the USG.
Good for you. I’m restarting it now for 3rd time…
That part of the configuration is same as it was before. Only thing I removed was password part for Google Maps tracking (as per breaking change in 0.97), but… calendar is still not working.
2019-08-08 21:08:53 ERROR (MainThread) [homeassistant.components.calendar] Error while setting up platform google
Traceback (most recent call last):
File "/usr/src/app/homeassistant/helpers/entity_platform.py", line 149, in _async_setup_platform
await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, in wait_for
return fut.result()
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/google/calendar.py", line 34, in setup_platform
for data in disc_info[CONF_ENTITIES] if data[CONF_TRACK]])
File "/config/custom_components/google/calendar.py", line 34, in <listcomp>
for data in disc_info[CONF_ENTITIES] if data[CONF_TRACK]])
File "/config/custom_components/google/calendar.py", line 47, in __init__
super().__init__(hass, data)
TypeError: object.__init__() takes exactly one argument (the instance to initialize)
Didn’t find anywhere that cookie or authentication or whatever have to be delated and re-authenticated…
Just updated to 0.97
Getting lots of errors for some (not all) of my media in helpers/entity.py complaining about missing entity-id for my media’s various switches such as “repeat switch”, “do not disturb switch”.
Here is an example:
2019-08-08 15:12:03 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/opt/homeassistant/venv_3.6/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 243, in async_update_ha_state
"No entity id specified for entity {}".format(self.name)
homeassistant.exceptions.NoEntitySpecifiedError: No entity id specified for entity MY Fire TV Stick repeat switch
Yes, you are right, but I’m using generic Google calendar for component and custom component is just for visualisation (you have to have generic one working for it).
For presence detection with the UniFi component (or any presence component…), defaulting to creating device trackers for every single discovered device on your network doesn’t seem like the correct default behavior. At least with the old UniFi device_tracker, you could tell it to no track by default, and it only polluted a single file with all the new devices that appeared over time on your network.
If we’re heading towards a 1.0 release that’s going to appeal to a new segment of “non-early adopter” users, I would imagine the only device_trackers they (and others) would likely be interested in are those associated with “personal devices” like mobile phones, tablets and maybe a laptop. Or maybe your wi-fi connected car.
I wouldn’t think most people would care about all the other random devices on your network as a default choice. Isn’t this a pretty big regression as compared to the previous component?