Ability to hide a group from the default view

AceoStar · January 15, 2017, 2:25pm

Currently, we have the ability to change your default view and manually specify which groups and components show up on the default view. This is handy, but once you manually define your starting view new components stop automatically showing up, obviously because you didn’t specify that it should be there.

I think it would be useful if we could define which groups we want to exclude from the default view and have everything else continue to work as is. For example, on of the first groups I created was my RaspPi card. Next thing I did was create a new tab for my “device information”. Now I have two raspi panels, one on default and one on my device information tab. Ideally, I could modify the group config so that it would not show up on the default view unless I manually specifed it in a default view config.

TL;DR - Override default tab view with default_view: no

pi:
name: Raspberry Pi
entities:
- sensor.cpu
- sensor.cpu_use
- sensor.disk_use_
default_view: no

Danielhiversen · January 15, 2017, 2:30pm

You can do that by setting hidden: True

AceoStar · January 15, 2017, 4:38pm

If I do the following, the panel disappears all together and the sensors I had grouped into Pi get dumped on the screen. I’d like it to appear in Devices tab, but not home, without having to manually select all of the tiles that appear in default view.

customize.yaml

 group.pi:
    hidden: true

groups.yaml

status_view:
name: Devices
view: yes
entities:
- group.pi

pi:
name: Raspberry Pi
entities:
- sensor.cpu
- sensor.cpu_use

rpitera · January 15, 2017, 4:38pm

I’m going to move this to Configuration as it is already a feature but may not be well known by some users.

AceoStar · January 15, 2017, 9:07pm

Thanks As best I can tell, I still cant do what is described in OP but Im sure someone will correct me eventually

clueo8 · May 16, 2017, 1:10pm

I’m struggling to do this as well… It does not appear there is a way to hide things from the Home tab (default view) without manually defining what you want to see on that view… I wish it was easier to move something to a tab (view) and have it not show up on the Home tab anymore…

TheCrey · May 16, 2017, 8:58pm

Hi,

i woud like to see that.

Especially in the beginning.
I am still a noob regarding the Home Assistant universe and i created some groups to organise and work with some other automation.
Those groups are now shown, but i would not mind if they would not be seen, as i need them just to work with them in the background.

DPB61 · July 2, 2017, 7:07am

I am also voting for this as an update request.

At the moment it appears I have 2 choices:

Home tab which shows literally everything - which is far too messy.
Home tab which only shows what I specify EXACTLY. Which is pointless because I can do that with another named tab anyway. And has a big disadvantage in that any new items don’t show up in the Home tab.

What I really want is a Home tab which only shows me items that I haven’t specified elsewhere and/or specifically excluded.

rpitera · July 2, 2017, 1:55pm

Or a filter for the dev states panel that would show only entities that aren’t already a part of a group…

bbrendon · July 4, 2017, 11:47pm

Can this thread be moved back to the feature requests?

anon43302295 · July 5, 2017, 12:48am

Done

(note that the vote count is zero, don’t know what it was before it was moved, so people need to vote again)

fredrike · January 19, 2018, 9:51am

There exist a patch for this (but it were unfortunately rejected): https://github.com/home-assistant/home-assistant/pull/11592

kinchyle · January 29, 2018, 12:40am

It was rejected with the point “you can override default view”. The problem with this is the logic that DPB61 expressed above.

I’m running into this where I’m new and need “auto discovery” to show me new things but I have media players popping on it from the roku, tv and plex. I don’t care about those for a “home status” so want to put them on a Tab. If I move to tab as a group they are still on home. If I hide in customization they go away from the tab… If I static set what I want to see on home I loose “new discovery”. Maybe allow for a home/default-view that you can make static but allow for a “group” that is the auto-discovery items that haven’t been “managed”.

metbril · March 2, 2018, 6:51am

Actually, if you really like/need/want this feature, you should probably add to that discussion at GitHub to make the devs aware of us.

kinchyle · March 5, 2018, 6:29am

They locked it I guess it creates some logic bombs against some of the core principles. colliding universes.

metbril · March 5, 2018, 3:42pm

Well, not really, the discussion is moved elsewhere:

github.com/home-assistant/architecture

Rethinking the States panel in the frontend

opened 06:16AM - 22 Feb 18 UTC

closed 06:46AM - 24 Jul 18 UTC

balloob

The current States panel has a major flaw: it tries to do things magically at ru…ntime. It takes all the available states and will organize all the things according to groups, hidden attributes and by domain (for ungrouped entities). By doing things magically and at runtime, we've opened a can of worms: - All entities will be shown on the first tab unless a user defines a default view. - With a default view defined, new entities will not be shown anywhere unless explicitly added by the user to a view - All configuration for the runtime layout engine ended up in the state machine: views, groups, hidden attributes, custom UI overrides. By adding it to the state machine, you ended up having to pick 1 way for entities to be shown in every view where you wanted them to be. - The domain of an entity defines how it will be displayed. - Groups can show a toggle for entities. However, this is not always desirable so a config option was added to the group component to control this. This config option is stored in the state machine. We can do better. Let's stop conflating concerns. Let the frontend be the frontend. The backend be the backend. The backend should provide the minimal information to the frontend: the entity id, name, state and attributes of an entity. No groups, no views. For the frontend to figure it out, it should get its own configuration. This configuration will be loaded from the frontend component when the page is loaded and will be used to layout the entities. So let's talk about the building blocks for a frontend configuration: # Views A view's purpose is the same as today: view a subset of the states in Home Assistant. It would however no longer be "hacked" into the group component. It would only live _inside_ the frontend component. It will not have a state in the state machine. - A user will need to have a minimum of 1 view - One of the views will need to be marked as "default". - Views can be ordered. - Views can either show an icon or a name for the tab. Whenever a new state is added to Home Assistant, the frontend will check if it has seen this entity ID before. If not, it will add it to the default view. This will only happen **once** for each entity. The user can just choose to remove the entity from the view if he doesn't want to see it. # Cards & Badges A view will consist of cards and badges, just like today. The biggest difference is that this will no longer be based on the group component. Instead, the user can configure cards to show things and this will be stored inside the frontend config. The most important card is the entities card. It will, just like today, show a bunch of entities in a card. If a user doesn't like the climate, camera or media player card, they can now decide to add that entity to the entities card and remove the other card for an entity. A user can also pick to show the same entity 3 times if they feel like. Other examples of cards: ([all already exist today](https://github.com/home-assistant/home-assistant-polymer/tree/master/src/cards)) - Group card: show the entities of a group as an entities card - Camera - Media Player - Climate - Plant - Weather - Persistent Notification (I probably will kill this and make notifications it's own section in frontend) This will also allow us to make custom UI cards first class citizens and have their config be stored as part of the config for the view. Pretty much all problems that users are facing today are solved by doing the auto layouting of entities when they are added to the default view instead of at runtime. At runtime we will just render the stored config for the view. # Conclusion The biggest difference is that this setup will allow the user to take control of what is shown on each view without any surprises. It knows what is happening on each view ahead of time and can add new entities to a view of choice. By still adding new entities to the default view, we will still have a great experience for users that are new to Home Assistant and don't want to dig into configuring views just yet. It also allows us to relieve the state machine of configuration and will make custom UI first class citizens of our ecosystem.

iantrich · July 2, 2020, 9:10pm

Solved with introduction of Lovelace