0.88: Persons, Command line auth and event subscriptions

pergola.fabio · February 20, 2019, 9:00pm

ah, that makes sense

finity · February 20, 2019, 9:03pm

If you don’t track the new releases but the component automatically gets added then how will you ever know that the component is available for you to use?

Updates are traumatic enough sometimes without HA adding components without telling you.

sirvictory444 · February 20, 2019, 9:17pm

Thanks for everyones hard work!

What is the deal with the new “person” component?
How is it different than using a group of devicer_trackers?

Right now for everyone in household I have a group composed each of a device_tracker.ping and device_tracker.bt If atleast one is ‘home’ then the group.person_one is ‘home’. It works flawlessly for tracking, sensor, stats, automations, etc.

I’d prefer to keep things simple by just using core-level components, unless this offers some new advantage.

Silicon_Avatar · February 20, 2019, 9:31pm

Right now? Probably not much, other than that it can be linked to a user account.

However, in the future, with multiple user accounts with individual permission levels and device trackers tied to them, the new area’s component with the ability to have a “person” in an “area”, etc, there will likely be many differences.

With the initial introduction of this component there is not much difference, but it might make sense to migrate to it where possible so when more advanced features are added the transition is smoother.

berniebl · February 20, 2019, 9:54pm

Maybe I am off base with this question, but if I want to keep a separate file for persons named (ex.) person.yaml , (splitting my configurations) I would have normally made a reference in my configuration.yaml file like this: “person: !include include/person.yaml”
If I add default_config: instead, will this not cause a conflict by seeing 2 entries named “person:” in my configuration.yaml? One for the default_config: and one that has the include statement.
I would really like to use default_config so that I am always up to date on the new components, but I have to say that I love splitting my configuration to keep it easy to locate.

aneisch · February 20, 2019, 10:17pm

Echo Devices (Alexa) as Media Player - Testers Needed use latest.

simpat1zq · February 20, 2019, 10:40pm

So I installed this component and it totally hosed the machine. When I started it, about 5 minutes later HA stopped responding. So I SSH into it, and that took like a solid minute just to get in, after that, running hassio help causes an out of memory error. I had to restart the computer. Not sure why that happened.

jncanches · February 20, 2019, 11:54pm

CustomUI seems to be broken since the update. Things like this

cover.garage_door:
friendly_name: Porte du garage
device_class: garage_door
alternative_friendly_names:
- Porte de garage
templates:
icon_color: >
if (state === ‘closed’) {
return ‘#34a853’;
} else {
return ‘#ea4335’;
}

does not work anymore. I mean the icon does not change its color. It’s always its default blue color.

Someone else noticed that ?

finity · February 21, 2019, 12:03am

I’ve seen a couple of other threads in which custom_components are beginning to give warnings that they need the directories to be restructured or they will soon fail.

It’s fairly easy enough to make the switch (unless you have a ton of them, I guess…) but when/where was this change announced?

the good news is you can switch to the new file structure now to beat the rush and your stuff will still work. the bad news is it also breaks the custom resource tracker card once you switch to the new folder structure unless the dev catches that change and updates their code.

EDIT: I just re-read the post and saw this:

That’s a pretty nonchalant statement for something that could end up breaking a significant portion of peoples set ups in the near future.

anon43302295 · February 21, 2019, 12:18am

Thanks

Agreed, won’t be using this here.

MichaelSchemmer · February 21, 2019, 12:20am

Hi all,
I’m receiving the following error when updating HASSOS to 0.88.
Any ideas?
19-02-21 00:18:22 INFO (SyncWorker_6) [hassio.docker.interface] Pull image homeassistant/raspberrypi3-64-homeassistant tag 0.88.0. 19-02-21 00:18:25 ERROR (SyncWorker_6) [hassio.docker.interface] Can’t install homeassistant/raspberrypi3-64-homeassistant:0.88.0 -> 500 Server Error: Internal Server Error (“readlink /mnt/data/docker/overlay2/l: invalid argument”). 19-02-21 00:18:25 WARNING (MainThread) [hassio.homeassistant] Home Assistant is already running!

techwithjake · February 21, 2019, 12:31am

Not normally one to complain but ZHA seems completely broken now with 0.88. I had to revert back to 0.87.1 to have it working again.

Entities in the ZHA dashboard have lost all their names, which makes it darn near impossible to know what device you’re looking at there without guessing and drilling down.#21242

Half of the device stops working but not all of it. I.e. the ZHA and Temp Sensor still works but the Binary Sensor doesn’t? #21243

Parts of the ZHA device that were shown as entities are no longer present. 21245

GraysonPeddie · February 21, 2019, 12:48am

CoolMasterNet sounds like a very cool component, but it does not look like I can buy one as a home automation enthusiast since I can only get a quote. It’s more for integrators and installers. Oh, well. But hey! It’s nice having Ethernet! No need for Wi-Fi, which is nice!

RobDYI · February 21, 2019, 1:09am

I would try rebooting your pi.

DavidFW1960 · February 21, 2019, 1:17am

It will add all default options like discovery etc, person, there is a list.

github.com

home-assistant/core/blob/dev/homeassistant/components/default_config/init.py

"""Component providing default configuration for new users."""

from homeassistant.core import HomeAssistant
from homeassistant.helpers import config_validation as cv
from homeassistant.helpers.typing import ConfigType

DOMAIN = "default_config"

CONFIG_SCHEMA = cv.empty_config_schema(DOMAIN)


async def async_setup(hass: HomeAssistant, config: ConfigType) -> bool:
    """Initialize default configuration."""
    return True

aidbish · February 21, 2019, 2:15am

If they follow the link provided it tells them what to do. HA cant be responsible for all the custom components otherwise it would never move forward.
The warning now, will give the dev o that component time to change or the end user time to inform the dev of that custom component the time to change it

DavidFW1960 · February 21, 2019, 2:20am

Or just do the simple change yourself… it’s only moving/renaming a file

DavidFW1960 · February 21, 2019, 2:21am

Only if they ignore basic instructions… so you’re right… lots of people’s configs will break…

Silicon_Avatar · February 21, 2019, 2:22am

Not that people are exactly expected to read these things, but there’s a system architecture discussion section of the Home-Assistant Github page. That’s where the discussions about these things take place, with this particular change being discussed as early as mid-december:

github.com/home-assistant/architecture

Embedded platforms and the road to packaged components

opened 02:44PM - 20 Dec 18 UTC

closed 07:30PM - 11 Jan 19 UTC

balloob

in progress

So @rytilahti had a good point in his long (and mainly off-topic 😉) [comment](ht…tps://github.com/home-assistant/architecture/issues/121#issuecomment-448439297) to my [proposal to change how we deal with discovery](https://github.com/home-assistant/architecture/issues/121). But I felt that a) it should be it's own issue and b) it should go further. And credit where credit is due, it's also something @amelchio has said before, and probably others too. @rytilahti proposed to make each platform a folder with their own metadata file. I've always shot this idea down, because it means that all our code has to be written twice, once for things based as a component and once for things based as a platform. That would be a maintenance hell and thus hinder progress. However, thinking about this, I realized that we can embed the platforms in components. That way we forget about the idea of "platforms" altogether. Instead, an entity component can load embedded platforms from other components. File structure wise, we would go from: ``` hue/__init__.py light/hue.py ``` to: ``` hue/__init__.py hue/light.py ``` **The content of the file stays exactly the same**, but now we have all code for a single component in one folder. This means a bunch of things, among others: - Only one code path, it's now all components all the way down - We can implement this backwards compatible, by just looking at both spots. Implementation wise, we just change [loader.py](https://github.com/home-assistant/home-assistant/blob/d42d8543c8d66a1ccd064bcc9b09092291ac00c3/homeassistant/loader.py#L54) to be defined as: ```python def get_platform(hass, domain, platform): return ( get_component(hass, "{}.{}".format(platform, domain) or get_component(hass, "{}.{}".format(domain, platform)) ``` - We can start having config entries for "platforms", because it's a component now. - We can now start defining a metadata file for components per https://github.com/home-assistant/architecture/issues/121#issuecomment-448439297 (but discussing that is out of scope for this issue) - Custom components will now be easier to distribute, which leads to… - Packaged components. If we have a single folder for a component and all it's platforms, we can make sure we have a file with metadata to specify requirements (so we can install requirements before loading the Python file and thus import stuff at the top of our python files), versioning, code owners, logo, name. Now this can be independently distributed and updated. Not just by us, but by others too, like Hass.io add-on repositories including updates etc. Just like Hass.io add-ons, it will ease maintenance as no longer the core team is the bottleneck of all PR reviews (this is just a future vision, not to be discussed in this issue!) - Entity components can be cleaned up and broken up into multiple files, like adding a `media_player/const.py` for the constants. This will help with circular dependencies like we're currently facing in https://github.com/home-assistant/home-assistant/pull/18700 Downsides: The only one I can think of is that once all built-in platforms are embedded and we deprecate the old pattern of `light/hue.py`, we could break some custom components that didn't update yet.

As a side note, it’s a nice repo to read through to get an idea of where this who project is headed, such as knowing about areas and persons long before any PRs were made to add code for those features lol.

sunglass_guy · February 21, 2019, 3:22am

@frenck 0.88 seems to be breaking the adb addon, the addon itself runs fine and i’m not getting any errors, but i’m getting an error that media_player.androidtv is not a valid platform, do i need to update androidtv.py file?