Confused on how to configure Areas

That’s not true at all. Devices in the same area are automatically grouped together if you are using the automatically generated front end.

Oh man, color me a liar. That’s so useful.

1 Like

It sounds like you’re being sarcastic but it’s certainly a move in the right direction if we are taking about the push to 1.0.

If you try to have a non-technical user set up HA they are going to have a really tough time if everything isn’t laid out in an effective manner.

The on boarding process makes you select the area for devices so it’s really nice to have everything logically grouped the first time you open the UI.

It might not mean much to you, but it’s probably not “for” you.

2 Likes

I never said it wasn’t. Was just simply saying that they are currently useless and serve no purpose. They were added a year ago and there hasn’t been any changes since. Until they make it so you can use these in automations/scripts, they’re still pretty useless.

It will also use the area as a room hint for Google Assistant - otherwise useless as you say.

Six months later I do a new HASS install and Google leads me back to this same place.

There is a feature request to allow non-‘Integration’ devices to be manually placed into Areas. I think that would solve it for me:

This thread alone should be a testament to how much effort they are putting into areas: “none”. I have faith. I’m hoping that they expand areas in general. I think this is the end plan because they haven’t moved groups into the UI yet. My assumption is that long term, areas will replace groups and behave the same way.

something is happening: https://github.com/home-assistant/home-assistant-polymer/pull/4597

I just want to know how we can force authors to code their integrations so they’ll allow assignment into an area.

You can’t force them to do something, most developers are volunteers that sacrifice their free time.

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

2 Likes

That still won’t fix existing components… :wink:

great response :roll_eyes:

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

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.

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

2 Likes

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!

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:

1 Like

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.

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

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.