'Misaligned' icon sizes

[Tamas-Toth-ebola]

Checklist:

• [x ] I updated to the latest version available
• I cleared the cache of my browser

Release with the issue:

4.0.0-beta.001 (but I think the 'problem' is version independent)

Last working release (if known):

I think the 'problem' is version independent

Browser and Operating System:

Official Ubuntu 24.04 Desktop + Chrome 126.0.6478.126 (Official Build) (64-bit)

Description of problem:

First of all, I would like to thank you very much for this fantastic plugin! This should be official feature, as your description write.

The problem is a very small barely visible problem, I had just caught it today, totally random. If you check my screenshot, the last 2 rows, the first one is the official HVAC fam-mode row, the second one is my custom with an addition button, to silent mode. So if you check the 2 rows your icons are a bit larger than the official tile button icons.

I just report it for the global consistency, of course, this is really a very minor problem.

Javascript errors shown in the web inspector (if applicable):

Your Full Remote Config

Additional information:

[Tamas-Toth-ebola]

Also the button hover style behaviour is not the same as the official. The official buttons - on hover - have a very slight opacity of the active tile button color, while your buttons have a very-light-grey color on hover.

[Nerwyn]

Nice attention to detail! I hadn't noticed either of those. the buttons also use the 20x20px icon size, so I should make that the default for --mdc-icon-size.

I should also be able to copy the ripple color variables from the built in tile features and use them with mwc-ripple.

[Nerwyn]

Fixing the ripples may take some more time, as ha-ripple seems to have more logic for fixing the ripple after pressing the button while the ripple remains stuck for mwc-ripple.

[Nerwyn]

@Tamas-Toth-ebola can you try the latest v4 beta? I was able to switch to the material/web ripple and it seems to be performing like the built in features.

[Tamas-Toth-ebola]

Hi!

With beta.003 I get the following...

Official buttons...

Your buttons...

The second button is where my mouse pointer was, just not grabbed.

Grey vs. light-title-color

[Nerwyn]

I think you may need to clear browser cache. I'm getting the smaller icons and correct overlay color.

[Tamas-Toth-ebola]

Hi @Nerwyn !

You were basically right, but in a strange way 😄

'Of course' I already originally refreshed my browser enough time to clear it's cache, but there were an interesting detail... While I used the latest beta, I still did not get the GUI based functions. Now I re-downloaded the plugin from HACS, as option of HACS, and seems, with it... the plugin totally refreshed as I finally have gotten the GUI functions and the refreshed styles.

But this is just a half success, as the icon sizes seem really solved, but the hover effect is interesting.

I previously used the following style definitions (I mean, for example)...

            style:
              '--color': |
                {% if state_attr('climate.climate', 'fan_mode') == 'auto' %}
                  var(--tile-color)
                {% else %}
                  initial
                {% endif %}
              '--opacity': |
                {% if state_attr('climate.climate', 'fan_mode') == 'auto' %}
                  1
                {% else %}
                  0
                {% endif %}     
              '--icon-color': |
                {% if state_attr('climate.climate', 'fan_mode') == 'auto' %}
                  var(--white-color)
                {% else %}
                  initial
                {% endif %}

...because, without it, I do not get proper state reporting, so the 'buttons' do not follow the state of the entity/attribute behind it. Also the original HA buttons have inverted icons if the buttons are active, to keep the contrast with the colored buttons. Your buttons have only one icon color without the custom 'hack', so I did it...

As the GUI based functions make sterile new configs, the result is a proper hover style on the buttons, but how can I use the state of the entities behind them to drive the button states?

Also interesting that the written lines are true for 'selectors', but plain buttons do not have correct hover styles, at least for me, never...

Lot of thank for your fast response, effort, and for all! You are really a star with this functions... should be PR-ed into the official codebase.

[Tamas-Toth-ebola]

Just one another sentence...

I forgot, why I had searched for custom solution for proper button colorization...

With your official attribute (value_attribute) I simply could not get the proper result...

For the selector entry earlier I tried the following...

        entity_id: climate.climate
        value_attribute: fan_mode

...but sadly without properly selected active button.

My HVAC has the following attributes and results (example)...

hvac_modes: auto, cool, dry, fan_only, heat, off
min_temp: 8
max_temp: 30
target_temp_step: 1
fan_modes: auto, low, medium low, medium, medium high, high
preset_modes: eco, away, boost, none, sleep
swing_modes: off, vertical, horizontal, both
current_temperature: 25
temperature: 25
fan_mode: low
preset_mode: none
swing_mode: off
friendly_name: [Climate]
supported_features: 441

Where do I make a mistake? (Sorry I totally forgot, that this was the reason why I made the custom button styles...)

[Nerwyn]

You should be setting the option field of each option button to the fan mode attribute value you want in order for it to highlight based on the selector attribute value with no additional styles needed. Something like this:

options:
  - option: auto
    icon: mdi:fan-auto
  - option: low
    icon: mdi:speedometer-slow
  - option: medium low
    icon: mdi:circle-medium
  - option: medium
    icon: mdi:speedometer-medium
  - option: medium high
    icon: mdi:circle-medium
  - option: high
    icon: mdi:speedometer

There's a bunch of examples in it in the README if you search for option:.

[Nerwyn]

Icon color changing when selected is inconsistent between theme dark/light modes, so it's up to the users to change their colors if they want to.

[Tamas-Toth-ebola]

You should be setting the option field of each option button to the fan mode attribute value you want in order for it to highlight based on the selector attribute value with no additional styles needed. Something like this:

options:
  - option: auto
    icon: mdi:fan-auto
  - option: low
    icon: mdi:speedometer-slow
  - option: medium low
    icon: mdi:circle-medium
  - option: medium
    icon: mdi:speedometer-medium
  - option: medium high
    icon: mdi:circle-medium
  - option: high
    icon: mdi:speedometer

There's a bunch of examples in it in the README if you search for option:.

Thanks! This was my problem, and sorry for disturbing you (with it). The reason of my missed information, as your examples are wonderful, but usually complex, and as option key-value pair is not mandatory field of options, I somehow overlooked it.

But without option the hover color is not the tile main active color, what could be intentioned, but without 'per option' entity_id + value_attribute definition(s) we have to use custom background CSS definitions to follow the state of the actual entity, when the hover color will be also not based on the title main active color, or the relevant entity's active color, with light transparency.

But this is really a very minor problem, so I just wrote you the whole background.

So thanks again for your support!

[Tamas-Toth-ebola]

Icon color changing when selected is inconsistent between theme dark/light modes, so it's up to the users to change their colors if they want to.

Understand! From this point the discussion is far from a bag report, lot more like different aspects.

I think, as HA offially handle this question, the best would be, if your solution defaultly could follow the official way, which is with day theme...

• dark icon on disabled background color, and light icon on active item background color

...while with night theme...

• light icon in any case

...and where your users - of course - could still override this method with their custom CSS parameters...

So the written logic is almost the same as you, I mean users can always override with their own requests, but the default could follow the official way.

But we definitely should not agree with it, I just wrote my opinion.

[Tamas-Toth-ebola]

And the last thing, that with plain buttons I simply cannot reach the 'toggle' like visual result. With properly defined value entity/attributes, the button visual state does not follow the relevant entity/attribute state, so I have to define custom background CSS here in every case.

For it I simply did not find any sample among your examples, as the only colored single button (from the examples) is colored with custom CSS also.

This is just about toggle like working methods... where the background color not follow the state of the 'switch', and also the hover color stay grey, what is almost the same thing which I mentioned 2 comment above, with selectors.

Still very lot of thanks for you, where these are just my opinions, nothing offense!!!

[Nerwyn]

But without option the hover color is not the tile main active color

Are you sure you don't have any overriding styles set? The default hover and selected color is var(--tile-color) for me and is defined here in code.

I think, as HA offially handle this question, the best would be, if your solution defaultly could follow the official way, which is with day theme...

• dark icon on disabled background color, and light icon on active item background color

...while with night theme...

• light icon in any case

The hard part about this is figuring out if the user is in dark or light mode. AFAIK Home Assistant doesn't make this information readily available.

And the last thing, that with plain buttons I simply cannot reach the 'toggle' like visual result.

Can you post your full tile card config?

[Tamas-Toth-ebola]

1. Selector - Hover

• Finally, I figured it out, thanks to forcing me into it. I had 3-4 selector based tile service calls, and almost all of them worked fine after - based on your help - I added them proper option attribute. Only one of them was wrong, and 'of course' I continuously checked just that (for the 'problem'), where I used a composite/complex condition check, because my climate's very own 'custom preset' mode had no really own state. I mean... I use my climate's 'auto' mode with fixed lamellas position (bottom-left) as 'nigh' custom preset, while 'auto' mode with another fixed lamellas position (top-right) as 'day' mode. The corresponding service calls were 1-1 script call which of course did not have own state, so your solution was not able to determine their states without my custom complex condition checks for CSS. After I realized the problem, I completely reconstucted the conception, I introduced a custom helper (enum) for my own presets, and an automation to switch it automatically based on the climate's own attributes. Now with it I can follow real states of my custom presets so I can use a selector with real options based on it, and with proper result. Thanks for it, and sorry for wasting your time...

2. Auto day/night

• It's totally understandable, sorry, I did not know this state is unavailable for the plugin. I'm a bit sad about it, but of course, it is far 'from your possibilities', so thank you for the explanation.

5. Simple toggle button

• Below my config example (the corresponding part):

      - type: button
        title: Quiet
        icon: |
          {% if is_state("switch.climate_quiet", "on") %}
            mdi:volume-mute
          {% else %}
            mdi:volume-vibrate
          {% endif %}
        entity_id: switch.climate_quiet
        haptics: true
        tap_action:
          action: call-service
          service: switch.toggle
          target:
            entity_id: switch.climate_quiet
          data: {}
        background_style:
          '--color': |
            {% if is_state("switch.climate_quiet", "on") %}
              var(--tile-color)
            {% else %}
              initial
            {% endif %}
          '--opacity': |
            {% if is_state("switch.climate_quiet", "on") %}
              initial
            {% else %}
              .2
            {% endif %}
        icon_style:
          '--icon-color': |
            {% if is_state("switch.climate_quiet", "on") %}
              var(--white-color)
            {% else %}
              initial
            {% endif %}

With the defined button background style the button color is almost the required, but with improper hover color on it's off state. A bit darker grey as the default grey, while it gets a bit lighter tile color in case of hover with it's on state.

Without custom background style, the button color simply doesn't follow the corresponding entity's state. It calls the corresponding service, so basically works, but without visual feedback as toggle button's on/off with it's active tile colored button in case of on state.

I get same result with any other 'tile - service call - button' with switch like entity behind it. Where I'm wrong?

[Nerwyn]

I'm a bit confused. Your styles above set the background color and opacity and icon based on the switch state and they seem to work correctly. When your switch is off the above styles do not change the background color or opacity. By default the buttons do not give feedback on entity state as designed, as the buttons are not made to give any feedback on entity state without additional user input.

[Tamas-Toth-ebola]

Hi!

Sorry for the late answer I had a bit of a bottleneck in my spare time 🫤 but I'm trying to finish our discussion now.

What you wrote is correct, the applied custom styles are working fine (eventually not exactly, but almost), but what I mentioned that in case of toggle mode of buttons, I missed the 'feature' to get about it a visual feedback.
In a simply line, I thought that if a button is 'above' a 2 states switch, as toggle button, the button could show the state of the switch as pushed or not push button. You already answered that this is not the case:

By default the buttons do not give feedback on entity state as designed, as the buttons are not made to give any feedback on entity state without additional user input.

From this point you can absolutely close my report as all the available problems were already solved, and lot of thanks for them!