Allows you to define the visibility of entities within an entity card

Allows you to define the visibility of entities within an entity card.

I have a lot of automations and scripts.
But I don’t like to just program an automation. That’s easy to forget. I like to create panels to allow users to activate, deactivate or configure certain automations at their convenience.
In other words, my panels are not just for viewing, they are for interfering with the automations in the house.
I use the entity panel because, although it is not the prettiest, it is the most practical and makes the best use of space. However, it has a downside. I am a programmer and, when we create user interfaces, it is common to have fields or controls that only appear for filling in under certain conditions. In HA panels, this is not possible. We can create rules for visibility of an entire panel, but not of its fields, and this would be really useful.

I will give an example of how I had to deal with this limitation in a panel I created.

I use a Raspberry Pi with my HA and for months now the community has been struggling with a problem when using an SSD on the USB port: the entire system randomly crashes due to the occurrence of a “SQLAlchemyError” error (there are several forums with this discussion and it seems that it all started with Core 14).
To try to deal with this, I created a system restart routine. Initially, it restarted every day. It didn’t work. Then I created a programmable restart by day of the week and time. It works, but it didn’t work. Lastly, I created an automation that restarts the system as soon as an occurrence of “SQLAlchemyError” appears. This worked (it doesn’t solve the problem but it doesn’t mean I don’t have downtime).

I encapsulated everything in three panels:

  • The first enables the system restart.
  • The second is only visible when the first is enabled and allows you to activate the restart when the “SQLAlchemyError” occurs or the scheduled restart. - The third panel only appears when I enable scheduled restart in the second panel.

It would be more functional, flexible and elegant if I could enable this on a per-entity basis, which would make the panels much more powerful!

I hope you appreciate the request and consider it a useful addition to the system.

Ex. 1 (When disabled, this panel is only visible.):
image

Ex. 2 (When the entity in the first panel is enabled, the second panel appears with more options):
image

Ex. 3 (When the “scheduled restart” option is enabled in the second panel, the third panel appears to enable the days of the week when the system will be restarted, the time and to which smartphone a notification will be sent. It also has the type of restart - whether only HA or the entire system):

1 Like

I agree. I’d like to be able to specify visibility on individual entities on an entities card. The way it works now, I have to split each entity into its own entities card so I can provide visibility specifications.

1 Like

Why not using a stock conditional row?

@ Ildar_Gabdullin

Ok, what’s a conditional row?

Alright, I looked it up and was tricky to get the syntax but some examples helped, and I got that working!

Thanks for the tip!

You are right. This “conditional” option works.

However:

  • You lose visual editing (you are forced to write code).
  • You cannot create a condition that applies to multiple rows. If you want the same condition to show or hide multiple rows, you have to repeat the same rule on multiple different rows.

This would be easily solved if they created this property in the visual editor.

And it would be even better if, in addition to visibility, we could configure the row to be “enabled” or “disabled”.

Although it is feasible, if I use this option for my complex panels, basically all the code will be manual.

This is about “I want to use UI”. If you need advanced stuff - use yaml.

Allow me to disagree. This is about the “usability” of the system.
I’m a programmer. For me, using code is not a problem.
But it’s one thing to need to use code and open a “template” for that. It’s another thing for them to have made a feature available that, when inserted, “breaks” the user interface.
You lose the “usability” of the system. It stops being for “everyone” and becomes accessible to “a few”.

1 Like