How to change the visibility of a card via an automation?

Configuration Frontend
1

I know how to modify the visibility of cards via the appropriate tab in the UI, but is there a way to modify it via an automation?

Thanks!

2

I think the closest you can get as a general matter is with the conditional card.

3

Use a state condition on something like an input_boolean, and toggle the input_boolean in an automation.

1 Like
4

Thanks for the ideas, much appreciated.

I am currently using the input_boolean approach, but it has a drawback - everyone looking at the dashboard sees the changed visibility. Iā€™m hoping to make it per user, so that when I toggle the input_boolean, only I see the newly visible cards, and when my partner toggles it, then she also sees the cards.

I can make the cards visibility conditioned on a per user basis, but i need to be able to change the user visibility from an automation.

6

If youā€™re willing to create an input_boolean for each user, you could display only a given userā€™s input_boolean using the condition cardā€™s user condition.

Then you can make a second use of the conditional card in conjunction with the cards you actually want to be controlling using the AND condition: for each user, AND (1) a user condition and (2) a state condition for the userā€™s corresponding input_boolean entity.

Itā€™s a lot, but itā€™s one possibility if youā€™re sufficiently committed.

7

Yeah, thatā€™s something Iā€™d like to avoid - no duplication of elements. I already have a bunch of input_boolean helpers for each of the items in the dashboard that has an optional ā€œshow moreā€ aspect, I donā€™t want to make those things per userā€¦

8

Unfortunately, principled adherence to avoiding duplication of elements or code in many cases limits what you can do with Home Assistant as it is implemented today. Thatā€™s especially true in the UI, where most of the time you canā€™t rely on Jinja templates for anything.

1 Like
9

Is it possible to create per- user input_boolean helpers from an automation?

If I can automate the process of creating and maintaining them, then I wouldnā€™t be averse to the duplicationā€¦

10

I wish the answer were yes. But itā€™s no.

A much more complicated solution is to stick a dictionary into an attribute of a trigger-based template sensor. You could then maintain a per-user state without adding or removing entities every time the user list changes. But to be honest, for something like this, itā€™s almost certainly not worth it as an alternative to the statically configured input_booleans.

11

Yeah, that makes sense.

I have an idea, though. Instead of using an input_boolean, Iā€™m going to switch to an input_number, which will be used as a bitmap, where bit 0 is me, bit 1 is my partner, etc.

Then I need to figure out how to make the visibility conditioned in whether or not the userā€™s per user bit is set. The automation can set and clear the bit based on a button tapā€¦

It may take me a few days to find time to play with this idea. Iā€™ll let you know if I can make it workā€¦

12

The main challenge I see with this approach is that the conditional card doesnā€™t let you use a template in any of its conditions. It has a very basic numeric_state condition. So the maintenance ease you get for not having to maintain separate booleans just gets deferred to exponentially more complex logic in the state condition (e.g., if itā€™s 1, itā€™s me, if itā€™s 2 itā€™s them, if itā€™s 3 itā€™s both, etc.).

13

Yeah, it looks like the visibility conditions arenā€™t as flexible as Iā€™d hopedā€¦I was kind of hoping that I could call a scriptā€¦

14

And I can actually see that I donā€™t think the attribute-based approach I alluded to would work either, since this card doesnā€™t seem to allow the state condition to be based on an attribute, let alone one with a dictionary.

Maybe there is a third-party card out there that allows templates in conditions. Iā€™m no UI expert.

1 Like
15

The concept of a ā€˜userā€™ in HA is very limited in the dash.

In fact to the point I do not bother separate user stuff on single dash. User specific dash yes. User component on dash beyond a sensor or markdownā€¦ No.

Theres also no Role based access controls

16

I disagree. I have a tablet in my office in the basement that only shows a todo list when the wife adds something to it that needs brought upstairs. We store overflow dry products down here.

Same dashboard that we use on other tablets. But specific user in the office.

The card is ā€¦

type: conditional
conditions:
  - condition: user
    users:
      - xxx
  - condition: state
    entity: todo.bring_upstairs
    state_not: "0"
card:
  type: todo-list
  entity: todo.bring_upstairs
  hide_completed: true

The rest of the card follows ā€¦

So, tablet user on all other tablets. And, officetablet user on the tablet in the office.