Add support for Area and Device registries

[Kane610]

To continue with being on par with Home assistants API there should be support in Appdaemon for the Area and Device registries.

[Odianosen25]

@Kane610,

Thanks for this. Can you kindly explain more on what you mean?

Regards

[Kane610]

Devices is the physical representation of one or more entities in home assistant.
Areas are physical representation of placement of a device.

Would be nice to be able to have helper functions that can be used with areas and devices

[ReneTode]

areas has been merged 3 days ago.
it isnt even in the latest version. and i cant even find a trace from it in the docs.
i am sure that at some point there will come helper functions for it, but its very hard to implement something that we dont even work with.

i think that when people are actually working with them, there will be suggestions on how to use and what kind of helper functions could be usefull. thats about the time to work on implementing it.

[acockburn]

I agree with Rene - when it's clear what we can add that will help in this area we can look into it.

[Kane610]

There is nothing wrong with MVP support. First implementation would purely be to be able to resolve from registries; areas -> devices -> entities.

[ReneTode]

i dont know what MVP support means, but i am sure Andrew is willing to look at a PR from you if you think it is that important.

[Kane610]

Minimum viable product, something to start with to evaluate further use cases

[ReneTode]

ah, ok. thanks for explaining.

I think that in case from something as new as this in HA, its always wise to let it go on HA for a while.
let people see what to do with it, if it is buggy and if HA will make breaking changes (as they almost always do)

at this moment we are preparing AD for beta release for AD 4.0 and then its not wise to add something new from HA, that they didnt even release (and from experience its in general not wise to support something new from HA when its not at least 2 releases old) ;)

but like Andrew said, he will add it at some point and he marked it as enhancement.

[Kane610]

These are really simple registries, create, read, update, delete. No notifications or anything since they're outside the state machine. They all share the same design as entity registry and would probably not be changed due to their simple nature. There has been no breaking changes in device registry since it was created, and I don't expect it to be with areas either.

Areas will be out with 0.87 so it is nearly released ;)

[unconfigured]

Nice to see there is already a request for it. I would like to use areas to represent rooms and I have just searched for a way to lookup to which area/room a motion sensor belongs to than query other devices in that area/room (lights, media_player, ...) and react accordingly. This would be much nicer than maintaining groups with all devices for all rooms. Cycling through entities and do some magic is very powerfull and convenient in appdaemon - thanks for this! I would love to see area support and just wanted to signal, that there is a demand an use-cases for that :)

[ReneTode]

whats the advantage from an area called livingroom over a group called livingroom?
in both cases you need to ad the devices that belong to livingroom.

i have groups like that since 2 years, i like to know what advantage it would give to change to areas?

[Kane610]

Areas are connected to devices so one benefit is that you tie all entities belonging to a device to an area. This will simplify contextual automations like turn on all lights in an area

[ReneTode]

This will simplify contextual automations like turn on all lights in an area

maybe this is a wrong example, because it was already simple to automate turn on all lights in a group.

so i am still wondering:
what is the difference between when i connect a device to an area called livingroom and when i connect a device to a group called livingroom.

maybe an example what i can do with area that i couldnt do with group?

[vigonotion]

Take a look here: home-assistant/architecture#94

This one is why home assistant added areas

[vigonotion]

It's now the recommended way of sorting devices into "rooms".

I have an app that goes through all entities and finds the ones that have a battery_level attribute. If the battery is low, I'll get a notification. I want add the area to the notification, so I know in which room the sensor is placed.
Would really appreciate areas in appdaemon

[acockburn]

Can you explain what you would need AppDaemon to actually do for you?

[vigonotion]

a function that returns AREA for given ENTITY_ID
(the areas name would be sufficient for me, if it has an uuid maybe that one too)

[ReneTode]

but how do you see if an entity belongs to an area?
is that given as an attribute from the entity?

i dont think so. i can hardly find anything back in the docs on how to configure areas, or anything else about it. (could be my lack of searching)
but i think the only way to find out to what area an entity belongs is to look to all devices, see if an entity belongs to a device and then look at all areas and look at if the device belongs to an area.

[Kane610]

The entity id belongs to a device which belongs to a group. That is how it is resolved.

You configure it mainly through the frontend.

[ReneTode]

nice that its configured through the frontend, but if there is no real connection we can hardly implement it.
an entity can! belong to a device, but how can i find a device in the rest API?
and how do i find an area in the rest API? and how can we find out to which area an entity belongs?

if i cant find any docs on how its used or setup, what services can be used with it, etc. how are we supposed to add support for it?

you asked for support for it in AD, and i know you were part of the development.
so please point us to information about area and device. how its used in the REST API and how we could use it in AD.

[Kane610]

The different paths for Areas and Devices (including how to list them) can be found under the config component
https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/config/area_registry.py
https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/config/device_registry.py

It is not only about using services, but they are also containers for different entities that should not need additional mapping logic in apps, in many ways replacing the need for groups. You can resolve all lights that belong to an area or get all lux values from sensors of an area.

[ReneTode]

i asked for docs about them and how to implement them in an outside program (like AD) (or any kind of docs) and or how they are registered in the API.

and i already did understand that its another way of grouping. (nice and confusing for newbies in my eyes) for people like me that run HA for over 2 years i see no advantage.

on this point i am not even able to use it in the latest HA. (but thats probably because my devices are configured in yaml and not through the frontend)

[Kane610]

Maybe this is better then? Most are simple endpoints that just allow a couple of different actions

https://developers.home-assistant.io/docs/en/device_registry_index.html
https://developers.home-assistant.io/docs/en/area_registry_index.html

[ReneTode]

no. it explain how to use it in HA development.
but it still doesnt tell anything about rest API.

how can i know what devices belong to an area when i only have a browser?
like: http://localhost:8123/api/states/light.some_light gives me the state from light.some_light

we need to be able to import a list with all existing areas and devices and what they contain in AD, so we need to know where that info is.

[Burningstone91]

Currently the only thing you can do is assign devices to areas.
As far as I know and read, there is currently no possibility to see which devices belong to a certain area. This has to be implemented on HA side first, before anything can be done in AppDaemon.

[Kane610]

@Burningstone91 sure you can, in the same way the frontend does. It is all there.

[Burningstone91]

@Kane610 Interesting. If I go to the area registry I only see the areas I have configured, however I don't see any of the entities that I assigned to the area. I also don't see any service calls to e.g. add/remove devices from an area. Could you please enlighten me?

[LunkwillAndFook]

Is support for Areas on the roadmap? They have been in HomeAssistant for almost a year now and I've hit a wall where things get really "hackey" without support for areas. Although my time is limited I'm happy to help implement where I can.

UPDATE: Looks like I'm asking the right question in the wrong place. There's currently no way to determine what area an entity belongs to via the HA API.

[ReneTode]

@LunkwillAndFook thats why this is still open.
we cant do anything with it.
i asked for API on kane several times (and he was involved in creating it) but still got no answers about it.

Areas are nothing more then a group that isnt called a group, but an area.
grouping can be done in any way you like. (in AD or HA) and at least for groups in HA there are services already implemented.
i use Area groups for 4 years now. i cant imagine what changing the name( from group.livingroom to area.livingroom) would add on functionality.

[VivantSenior]

config/area_registry/list over the websocket should provide a list of area's with their names and area ID's

Info from @frenck gathered on AD discord.

[alistairg]

I'm happy to take this on - the REST API I just tried to add to HASS was kicked back for being "the old way of doing things" now that everything has to be via the (bluntly harder to use) Websocket.

So, before I try and take on adding this to AppDaemon and suffer another disappointing "no thanks" - is there a particular place or practice I should follow for this code? I've only ever used AppDaemon with HA, but I know it aims to support other channels - and Area Registry is very HA specific. Do we need an abstract architecture first?....

[ReneTode]

I've only ever used AppDaemon with HA, but I know it aims to support other channels - and Area Registry is very HA specific

because of that i think it should be in the hass plugin
the only logical functions i see, because of what i know about how HA implemented it, is functions like:
get_areas(entity) and get_device(entitity)

but im no dev (anymore) so i would wait for a goahead before you create a PR.

[Matchlighter]

FWIW, I've done this in JS-land for another project. Looking at AppDaemon's code, it would be best for this to be done in the plugin - otherwise you'd need to setup another Websocket to HomeAssistant. Here's my JS snippet:

    async findRelatedEntities(entity: HassEntity): Promise<string[]> {
        const response1: any = await this.api.sendMessagePromise({ type: 'search/related', item_type: 'entity', item_id: entity.entity_id });
        const relatedDeviceIds = response1['device'];
        if (!relatedDeviceIds) return [];
        const response2: any = await this.api.sendMessagePromise({ type: 'search/related', item_type: 'device', item_id: relatedDeviceIds[0] });
        return response2['entity'] || [];
    }

[zanfur]

I created a pull request that will give access to these registries, as well as all data retrievable over the websocket api: #1583

[Kane610]

I created a pull request that will give access to these registries, as well as all data retrievable over the websocket api: #1583

Nice!

[zanfur]

#1584 should completely close this issue when merged.

[LunkwillAndFook]

Thank you @zanfur for taking this on and for everyone else who responded to and gave input on this request.