Confused on how to configure Areas

[petro]

That still won’t fix existing components…

[petro]

great response

[petro]

@AhmadK

Well, do you still believe in magic? Who will change all those existing components overnight?

That’s my point. That’s the flaw in your o-so-insightful curt response

@AhmadK

@jjross, @Burningstone but HA can come up some guidelines for developers so they know what they can implement. no need to force

@AhmadK

And even if you are ready to do that on your own - it’s up to HA devs eventually if they’re happy with such changes (a recent example - display_option of sensor.date_time platform will stay as it is despite the option having no impact on the sensor’s visibility, they just see no reason for a “cosmetic change”).

wtf does this have to do with anything. Are you implying that any small change will require the person to implement it into integrations? If so, bugs would never get fixed. And that still doesn’t account for components that have not upgraded in years.

[jjross]

That’s effectively what I meant. Force was far too harsh a word.

[mamoulian]

I suspect things are going to get worse before they get better as groups are now being deprecated.

Don’t delete/regen your UI config, folks!

[Burningstone]

@mamoulian

groups are now being deprecated.

This is not true, groups are not being deprecated. Groups are only deprecated as a frontend construct.

See this post from the founder of Home Assistant:

[mamoulian]

Frontend is my problem with areas. When Lovelace auto generates it currently uses areas and groups. As discussed above areas are only currently useful with Platforms that have been updated to be Integrations, so the now-deprecated groups are the only way (I think?) to tell it to put all the otherwise-unrelated kitchen stuff in a card called Kitchen.

[AhmadK (akasma74)]

@mamoulian

When Lovelace auto generates it currently uses areas and groups.

Maybe you could do it yourself rather than rely upon auto generation?

[hagak (Jeff)]

This may be true but in the same post they have this:
Group Deprecated - Group configurations options, services and service options related to the old states UI are now deprecated and pending for removal in Home Assistant 0.107.0.

That is not specific to the frontend, and read at face value means they are going away.

[Burningstone]

@hagak

related to the old states UI

Read carefully

[petro]

Yeah, they aren’t going away. You read that wrong. Not your fault though, it’s a shit sentence.

[hagak (Jeff)]

Very poorly written. They also wrote about services and service options which are NOT tied to the states UI. So which is it?

[petro]

• Groups are staying.
• view and control configuration options are not staying.
• the service group.set_visibility is not staying.
• the configuration options control, visible, and view for group.set service are not staying.

The options in the group section inside configuration.yaml only affect the States UI (view and control)
The service group.set_visibility only affects the states UI.
The configuration options for group.set only affects the states UI (control, visible, and view).

None of these things affected lovelace. So they are just saying that these are getting removed.

[anon3881519]

So, we’re a year on from when Areas were introduced and I’m still not sure what they are used for or will be used for. Meanwhile groups is just slightly more useful as you can (maybe) affect a group together depending on how different the group items are from each other and groups don’t make a difference to lovelace layout that it once did in the states UI.

So… Do we know where either of these two constructs are headed?

[petro]

@anon3881519

So, we’re a year on from when Areas were introduced and I’m still not sure what they are used for or will be used for.

It’s pretty clear that areas are going to drive the auto-generated interface.

Groups are staying the same… Nothing has changed with groups other than removing the deprecated states UI links, which should have come to no surprise to anyone when the announced that lovelace was taking over.

[jaburges (jamieB)]

jut revisiting areas - as i’ve installed Dwains theme
The layout is pretty interesting as it puts things in ‘Rooms’ which is the same as Area in this context. So you can see a Room and all its entities in a single view
I’m assuming eventually other integrations, voice assistants etc will be able to leverage this.
If a command is issued to the bedroom alexa “turn off the TV” then turn off the bedroom TV, and speak the result through the bedroom sonos one? etc

It feels like area has got as far as it can in preparation, now other things probably need to begin using it a little more?

[jjross]

That’s how the default theme works now too. Everything is automatically grouped by area.

[Fiendir]

The documentation overall on what areas are intended to be used for is so incredibly vague that I can’t help but laugh. I’ve gotta come here to this years-old forums thread to discover nobody else really seems to have a solid understanding hahahah

You can’t even call an area like you can a group if you’re doing an automation or script, which kind of defeats the majority of (at least my own) use cases, when it comes to grouping together devices. Thought Areas was gonna be the new, YAML-less way of quickly configuring groups, but nope, I just wasted my own time hoping that was the case

[petro]

Areas is a WIP and it’s only for the frontend.

[ptdalen]

After months of ignoring areas, I finally had some free time and decided to play around with it. I created two area’s even restarted HA, and after an hour or so, still cannot figure out how to add an entity or an integration to an area. Does this require yaml? Not sure I have a use for it, but wanted to see what it could do. I have zwave, zigbee, homekit, echos, ecobee, hue and have not seen anywhere for any of these as to where I would add the area. Any help is appreciated