Lovelace - display only some attributes based on entity state?

[doron]

Hi folks,
I’m trying to have some attributes (“features”) of a card show / not show based on some dynamic value (say, a template or an entity state).

Specific example: I need to have a thermostat card present only some of its features, based on the value of another entity:

- type: thermostat
    entity: climate.my_ac
    features:
      - style: dropdown
        type: climate-fan-modes
      - style: icons
        type: climate-hvac-modes
        hvac_modes:
          - heat
          - cool
          - dry
          - "off"

Now, what I want is for the hvac_modes to display only some of the modes, based on some condition. The use case is that they’re all part of a VRF system and if the system is currently cooling, I don’t want the “heat” option to be displayed, and vice versa. When the VRF system is off, I want all modes to show. (I plan to have a “vrf” entity that will be either “off”, “cool” or “heat” based on state of all units.)

Is there a way to have the card become conditional in such a way?
(I suppose I can have three cards and control their visibility but that seems borderline criminal by the elegance police )

Thanks for any pointers!

[Ildar_Gabdullin]

If you need to show buttons conditionally - try using card-mod.
Honestly, never did I it myself for thermostat, but it should be possible.
Use smth like “display: none” for a particular UI element dependently on your conditions defined in jinja.

[doron]

Thank you @Ildar_Gabdullin. Sounds like a great idea!
I’m trying to implement it, but for the life of me I can’t make the card_mod config affect the button.

As an example, the “heat” option div, which I would like to set to “display: none”, is in a path like this:

document.querySelector("body > home-assistant").shadowRoot.querySelector("home-assistant-main").shadowRoot.querySelector("ha-drawer > partial-panel-resolver > ha-panel-lovelace").shadowRoot.querySelector("hui-root").shadowRoot.querySelector("#view > hui-view > hui-sections-view").shadowRoot.querySelector("div > ha-sortable > div > div > hui-section > hui-grid-section").shadowRoot.querySelector("ha-sortable > div > div:nth-child(2) > hui-card > hui-grid-card").shadowRoot.querySelector("#root > hui-card:nth-child(1) > hui-thermostat-card").shadowRoot.querySelector("ha-card > hui-card-features").shadowRoot.querySelector("hui-card-feature:nth-child(2)").shadowRoot.querySelector("hui-climate-hvac-modes-card-feature").shadowRoot.querySelector("ha-control-select").shadowRoot.querySelector("#option-heat")

How do I code a card_mod clause that will affect it?

[Ildar_Gabdullin]

I am far away from a normal PC and cannot help.
Perhaps this could be a starting point: there is an example of replacing icons for features.
But to replace an icon, you need to go down to some svg element.
In your case, you need to set “display: none: for a more higher level.
The mentioned example is here: main card-mod thread - 1st post - “fantastic” link in the bottom - Tile - custom icons for features.
Note this is a Tile, you need a Thermostat - but a method is similar.

[doron]

Thanks! Wow, that bunch of posts indeed merits the title “fantastic”. What a wealth of knowledge - not sure how I didn’t find it before asking here

At any rate, I made some progress with that. The only setup that seems to work for me looks like this (for now I just make them red to see it “takes”):

    card_mod:
      style:
        hui-card-features $ hui-card-feature:nth-child(2) $ hui-climate-hvac-modes-card-feature $ ha-control-select $: |
          div#option-cool {
            color: red ; 
            }

So one final(?) question is wrt the “nth-child(2)” part. It’s rather specific, so that it may be less resilient to future potential changes. Removing it does not work. I tried to replace “2” with “n” and that does not work; if I replace it with “2n” it does work. “-n+2”, which should have covered first 2, also fails. Which makes me pause…
Is there a way to specify this in a more “generic” way, “for any nth-child” or some such? Might the above be a bug in card-mod?

Thanks so much for your help!

[Ildar_Gabdullin]

@doron

Removing it does not work

Removing what?
The expression xxx:nth-child(n) stands for “any xxx element”.
The expression xxx:nth-child(2) means “2nd”.
Suggest to Google about nth-child().

[doron]

@Ildar_Gabdullin

@doron

Removing it does not work

Removing what?

Sorry, I was too terse.
I meant removing the entire “:nth-child(2)” suffix.

@Ildar_Gabdullin

The expression xxx:nth-child(n) stands for “any xxx element”.

Indeed. And for some obscure reason, it does not take in this scenario. It should have, as it should indeed mean “any child element”. I don’t understand that. It might indicate some card-mod glitch.

@Ildar_Gabdullin

The expression xxx:nth-child(2) means “2nd”.

Clearly And it works for me, as does nth-child(2n) and some other an+b formula variants. I wanted to say xxx:nth-child(n) to indicate any child, so as to make it more robust and future-proof, but that didn’t take.

[Ildar_Gabdullin]

@doron

might indicate some card-mod glitch.

No idea, cannot check the whole path you specified.
Without nth-child, ALL elements should be styled.
If not - you either specified a wrong path or “!important” must be used.

[Ildar_Gabdullin]

@doron

wanted to say xxx:nth-child(n) to indicate any child

Not needed, just omit nth-child.

[doron]

Okay, this is a nit, and might be a card-mod bug; you’ve been extremely helpful and I don’t want to keep nagging you for picking this nit. Consider this solved, with my deep gratitude.

Just for posterity:

@Ildar_Gabdullin

@doron

might indicate some card-mod glitch.

No idea, cannot check the whole path you specified.
Without nth-child, ALL elements should be styled.
If not - you either specified a wrong path or “!important” must be used.

That is indeed what I was expecting. Yet, with nth-child(2) or (2n), it works (impacts rendering); without nth-child, with nth-child(n), and/or with “important!”, it appears not to work. Since (2) works for me, I’m considering this solved.

Thank you so much!

[Ildar_Gabdullin]

@doron

without nth-child,

Ping me here in this thread in a week please. Will try to see what happened.

[LiQuid_cOOled (Not really a...)]

The nth-child isn’t necessary

card_mod:
  style:
    hui-card-features$ hui-card-feature$:
      hui-climate-hvac-modes-card-feature$:
        ha-control-select$: |
          #option-off{
           color: red;
            }
          #option-cool {
           color:blue;
          }
          #option-heat {
           color: orange;
          }

[doron]

@LiQuid_cOOled

The nth-child isn’t necessary

Indeed! When you break it into separate lines as you did, it works! (Which for me, solves the concern). If you combine the hui-climate-hvac-modes-card-feature into the previous line, it does not work (unless you add “:nth-child(2)”).

I’ll leave it as a mystery. Thanks for showing this variant! It is more elegant than mine and makes the code more solid.

[LiQuid_cOOled (Not really a...)]

It will work with your format

card_mod:
  style:
    hui-card-features$ hui-card-feature$ hui-climate-hvac-modes-card-feature$ ha-control-select$: |
          #option-off{
           color: red;
            }
          #option-cool {
           color:blue;
          }
          #option-heat {
           color: orange;
          }

It just has multiple element hierarchies that can be mapped different ways

[doron]

@LiQuid_cOOled

It will work with your format

card_mod:
  style:
    hui-card-features$ hui-card-feature$ hui-climate-hvac-modes-card-feature$ ha-control-select$: |
          #option-off{
           color: red;
            }
          #option-cool {
           color:blue;
          }
          #option-heat {
           color: orange;
          }

It just has multiple element hierarchies that can be mapped different ways

Indeed it SHOULD. Only that it does not; at least that’s what happens here. Quite clearly: When broken as in your previous post, it works; when placed on one line as you posted here, it does not.

For posterity, if someone bumps into this thread due to some other keywords, here is what I ended up doing:

    card_mod:
      style:
        hui-card-features$: 
          hui-card-feature$:
            hui-climate-hvac-modes-card-feature$:
              ha-control-select$: |
                #option-cool {
                {% if is_state('sensor.vrf_state','heat') %}
                  display: none ; 
                {% endif %}
                }
                #option-heat {
                {% if is_state('sensor.vrf_state','cool') %}
                  display: none ; 
                {% endif %}
                }

[LiQuid_cOOled (Not really a...)]

What card mod version are you on? When I post code, it is tested and WORKS!!!

type: thermostat
entity: climate.living_room
features:
  - type: climate-hvac-modes
card_mod:
  style:
    hui-card-features$ hui-card-feature$ hui-climate-hvac-modes-card-feature$ ha-control-select$: |
      #option-off{
       color: red;
        }
      #option-cool {
       color:blue;
      }
      #option-heat {
       color: orange;
      }

I was simply trying to assist… You do realize the way you select the features mattters when mapping the shadow-root?

[doron]

@LiQuid_cOOled

What card mod version are you on? When I post code, it is tested and WORKS!!!

I’m not doubting that in the slightest
Then again, I am reporting what I see here. I have card-mod 3.4.4, which I believe is the latest at the time of writing this.

@LiQuid_cOOled

type: thermostat
entity: climate.living_room
features:
  - type: climate-hvac-modes
card_mod:
  style:
    hui-card-features$ hui-card-feature$ hui-climate-hvac-modes-card-feature$ ha-control-select$: |
      #option-off{
       color: red;
        }
      #option-cool {
       color:blue;
      }
      #option-heat {
       color: orange;
      }

I was simply trying to assist…

… and you have, big time! If my previous post sounded anything less than very grateful, it’s probably my bad. You certainly provided the robust and more elegant solution I was seeking. Thanks again!!

That being said… and just to try and pick on that weirdness I’m seeing, be it an error on my part or a card-mod bug, - my thermostat setup is slightly different that yours, which could explain the fact that we’re seeing different behaviors.
My thermostat has two features configured, not one. Like so:

  - type: thermostat
    entity: climate.l1_001
    show_current_as_primary: false
    features:
      - type: climate-fan-modes
        style: dropdown
      - type: climate-hvac-modes
        style: icons
        hvac_modes:
          - heat
          - cool
          - dry
          - "off"
    card_mod:
      style:
        hui-card-features$:
          hui-card-feature$:
            hui-climate-hvac-modes-card-feature$:
              ha-control-select$: |
                #option-cool {
                {% if is_state('sensor.vrf_state','heat') %}
                  display: none ; 
                {% endif %}
                }
                #option-heat {
                {% if is_state('sensor.vrf_state','cool') %}
                  display: none ; 
                {% endif %}
                }

It is in this setup, that specifying the selectors on one line fails(*), while specifying them in the nested way you showed, one per line, works.
Are you seeing same?

(*) Unless I append “:nth-child(2)”, as discussed above.

[LiQuid_cOOled (Not really a...)]

When adding Features to the card, the order matters. If the type: climate-hvac-modes isn’t selected first you’ll have to use the :nth-child path vs the path I provided. That is at least what I’m seeing.