Advanced Tile card with new controls and features

[BBE-FR]

What type of request is this?

This is a list of enhancement to the already awesome Tile cards and its features !
Please do not see this big list as a big complains, but more a notebook to all the improvements I would like to see arriving on this already great and versatile card ! 🙏

FR currently closed because its main goal was deemed impossible, see closure comment for explanations: https://github.com/orgs/home-assistant/discussions/489#discussioncomment-15486935

Some other FR or issues are still openned to cover some other aspects than template or action buttons as you can see below:

Existing card or feature name

{"Card" => "Tile"}

---

Full control of element to be displayed:

FR moved there for clarity: https://github.com/orgs/home-assistant/discussions/1430

A huge versatility is obtained on badges on the "content" tab interface on what to display. If the Tile card had the same capability this would be a huge versatility improvement.

---

Propose an horizontal layout:

😍 Implemented in 2025.3 😍

---

Features consistency

This issue for me is a bug, which was reported and documented here: home-assistant/frontend#27480

There is more in the comments below, but I would suggest as a generic UX principle for features to try (as much as possible) to have the features reflecting the state of the entity (like the icon) thus most of the time:

• grey when the entity is OFF (light grey or dark grey depending the theme)
• with the relevant color when the entity is ON
  refer to comment: https://github.com/orgs/home-assistant/discussions/489#discussioncomment-13985246

---

Generic customisable features

Rejected by the dev => use custom features in HACS instead of this.

😍 2025.3 already introduced the toggle feature for all toggle-able entities. This is a first step toward features available for all entities, but many entities still do not have adapted features.

Instead of trying to create a dedicated feature for each entity type, it would be useful to let the user create his own buttons as feature.
These buttons could be added in a feature the same way optional entities are added and customized into the versatile "heading card".

This heading card "badges" based on additional entities can be used to create indicator or even buttons (but too small to offer proper usability as buttons):

Same functionality as example performed with custom-card-feature to illustrate the look it could have in a Tile:

This new feature would add buttons (same consistent design as the area card), with a design and behaviour based on the selected entities, with the same level of customisation and same interface for each button as as for a Tile card (not more) :

• chosen entity would pilot the default appearance and actions of this button with the same look, behavior, default state as the tile card icon (icon/icon color/icon tap action)
• same customisation level offered for icon (icon and icon color customisation, maybe icon could be replaced by a text there if not too complex)
• adjust the visibility (nice to have, but could allow to create conditional buttons depending on scenarios + is fully consistent with Tile or heading card entity capacity)
• adjust the icon action (toggle the selected entity, display the more info of the entity, navigate, launch an action...) (with optional hold and double tap action in yaml as for the Tile card)

This kind of button row would be consistent with existing core cards (area card and heading card) in term of behaviour, interface and look and could solve 90 to 99% of the need for custom cards...

The way to set them should be as simple as the tile card itself (select the type of feature, add one button, define an entity linked for display/control, adjust the content, visibility and select the action) level of customisation for a button being similar to the icon behaviour of a Tile card icon and not as complex as other existing custom features existing in HACS (for example the very complete custom-card-feature, complete but too complex).

---

New Features for sensors :

😍 Implemented in 2025.9 and 2025.12 😍 https://rc.home-assistant.io/blog/2025/09/03/release-20259/#new-tile-card-features

These features could still be slightly improved, with color thresholds, but this first step is already very good!

---

Tile cards and devices :

Discussion started from here: https://github.com/orgs/home-assistant/discussions/1042 but as discussed in the comments below, this should be part of a "device card" not a Tile, thus this is removed from this FR.

More in the comment below with an interesting discussion on the interest to display a "device" in a Tile card (choosing which entity to link with the icon, and allowing to display all entities/attributes in the state) or to link the device of the displayed entity to be able to:

• control the "main" or "selected" entity of the device (example the switch for a smart plug)
• display information of the other entities from the device (example for a smart plug: state of the switch, power, energy)
• display any feature of the other entities from the device (example for a smart plug: a minigraph of the power).

---

Templating capabilities:

Rejected by the devs. Thus, for a "Tile template", we have to rely on the very versatile "mushroom template card" available in HACS.

Templating capabilities for Name, State, Icon, Color and badge in the Tile card to take the full control of the display for advanced user:

It is currently not possible to change the icon or icon color easily. You have either to:

• go through card_mod
• switch to mushroom template card

(both being awesome, but are not fully home assistant integrated).

In the same manner, if you want to display a specific information (name, attribute), the only "core" way to display Jinja2 template for the time being are:

• the markdown card which is not as nice as tile cards when placed together, has no icon and has no possibility to define "tap actions".
• define a dedicated template entity (for example a sensor) only for this dashboard use, not very user friendly, nor practical, not even always a good architectural choice to add entities for a pure display issue.

Use cases

described above.

Visual examples

described above

Anything else?

none

[BBE-FR]

To develop a little bit on the Feature consistency issue:

My opinion about feature consistency is the following:

There should be the following generic UX principle for features, to try as much as possible to have the features reflecting the state of the entity (like the icon) thus most of the time, especially in terms of color, when the feature is reflecting the state of the entity:

• grey when the entity is OFF (light grey or dark grey depending the light or dark theme)
• with the relevant color when the entity is ON (or not OFF)

All the examples below are obtained with the demo dashboard entities so anybody can look to it in the demo dashboard:

• good example of the toggle feature:

• Good example with media player volume slider:

• Good example with climate CVC mode selector:

• Questionable case for covers position slider:

For the cover, I personally think the control should be kept. Thus I find usefull to keep the slider control. But for me keeping also the color is inconsistent, the color could be shifted to grey when 100% closed. For example like for the climate above where the "off" state is materialized in darker grey. Due to this I do not use this feature in my dashboard because it creates a false impression that a cover is open... But I admit this is questionable.

• Bad (in my opinion) example with the color-temp slider of light entity:

Why remove the slider for control but keep the color for the color temp feature ?

I personally think that a truly 100% professional design should allow to have a state where the full Tile card color (icon + features) match the "off" state (like the media and climate example above) and that the cover and light are inconsistent.

Hereafter an example to highlight that:

• Regarding lights, I have an entity (a group) showing "On" on the main page, exactly as the summary card of the "Home" experimental dashboard.
• Clicking on it opens a view dedicated to lights with a tile for each lights (exactly as in the "Home" dashboard).
• On this view, only the "on" light should appear "colored" to have a quick finding and eventually controlling them.

The behaviour of this always orange color-temp slider, making all light appear as ON, is preventing me to use this feature in this page for me, whereas this is exactly the type of pages where it would fit to offer full control on all lamps.

Concerning Covers, the same logic should apply for me, as for the closed state is "grey" because it is the "safe" position, only the "not closed" slider should appear "colored". But for this case I admit I am not sure everybody would be 100% comfortable to have the cover bar turning dark grey as soon as the cover is 100% closed.

[BBE-FR]

Thanks. It looks like example of the documentation, but there is no guidelines here. It does not say: when designing something please respect these golden rules.

For example, this is my dashboard first page (based on Tile look):

I have some personal rules:

• red is for warning
• amber is for caution
• if everything is nominal color should be grey (unless informative)

I would have expected something similar in term of UX/UI (at least internal) maybe it is done via figma but not shared? Or it is relying on Material design or web awesome...

[MindFreeze]

This is something we are working on but is not ready yet. Right now we just have high level guidelines around branding, margins, etc. The next steps are to consolidate the design of cards, dashboards and all the different pages in the app.
It's not easy though as everything has to remain highly customizable and backwards compatible.

[BBE-FR]

If there is a place to contribute on some "design principles", UI or UX, I would be happy to contribute if it is felt useful.

I cannot help on code (not my core competency) but on design specification, human factor and interface, I could...

[MindFreeze]

The dashboards project in Discord https://discord.com/channels/330944238910963714/1351536906437005313 I think

[BBE-FR]

To my understanding, this dashboard discord channel is a discussion space on the new "Home" automatic dashboard, not for all dashboards. (I already send some ideas there anyway).

There is a frontend channel also.

To be honest, I did not really found any place where a UX/UI strategy or rules is/are shared.
I fear it does not exist and the coherency relies on the people writing/accepting PRs...

Not an issue anyway...

[BBE-FR]

To develop a little bit on the feature for sensor topic:

I discovered some interesting inputs from @Madelena here: https://github.com/orgs/home-assistant/discussions/67#discussioncomment-13606976

Work in progress from @marcinbauer85 and @MindFreeze seems to be covering the "feature for sensor" of my Christmas list !!

This is a great news if it make it way to the release !!

[MindFreeze]

That was my idea but some people are complaining that it looks too much like the brightness slider. I consider this a feature instead of a bug as it is essentially a read only slider but not everyone agrees.

[BBE-FR]

I fully agree with your approach.

Its a read only slider, the "actionable slider" having a kind of "cursor" to play with...

Hope it make it way to the release and have a future...

[BBE-FR]

https://rc.home-assistant.io/blog/2025/09/03/release-20259/#new-tile-card-features

Part of the release !!

Many thanks @MindFreeze for this new steps toward a super versatile tile card !!

[BBE-FR]

Adopted for the battery monitoring page.
@MindFreeze I hope it will continue for all sensor with a customisable min/max for display for example).

😍

My code is based on Auto-entities with the type of battery in the friendly_name for include test:

type: custom:auto-entities
card:
  type: vertical-stack
card_param: cards
filter:
  include:
    - options:
        type: tile
        features_position: inline
        vertical: false
        features:
          - type: bar-gauge
      name: ^*AAA*
    - options:
        type: tile
        features_position: inline
        vertical: false
        features:
          - type: bar-gauge
      name: ^*CR*
  exclude:
    - options: {}
      state: ">50"
sort:
  method: state
  numeric: true
show_empty: true

[BBE-FR]

2025.12 brings the generalization of bar gauge with min/max to all sensors !
Brilliant

Thanks @MindFreeze !

[pcan08]

Could it be something like this ?
I am trying to prototype something.
You can select and sort entities, and for each of them, sort and select features from among those that already exist.

[GeorgeZ83]

That looks awesome! Any news on the progress or a link to the project?
It's a great start but, if I understand correctly, it only shows the available features that the entity currently supports.
What the OP wants is the ability to add generic features to a tile that are not limited by the supported entity features.
For the moment we can use this: https://github.com/Nerwyn/custom-card-features

[pcan08]

Thanks, i'll share the code when it will be more mature. Yes it supports only entity features but we can select multiple features.
Mixed with this I guess it could be more powerfull (of course not as many as the custom feature addon) but as you said, this could be a good start.

What I prototyped works but I'm not convinced by the rendering. I'd like to be able to manage feature sizes better, for example by putting 2 features on the same row. For me this is a little bit challenging because I am not yet familiar enough with frontend development, especially css

[BBE-FR]

That looks awesome! Any news on the progress or a link to the project? It's a great start but, if I understand correctly, it only shows the available features that the entity currently supports. What the OP wants is the ability to add generic features to a tile that are not limited by the supported entity features. For the moment we can use this: https://github.com/Nerwyn/custom-card-features

Exactly. I would like a "core" simplified version of custom-card-features to define simple features (buttons for example) that could be linked to other entities than the "main" tile entity.

Custom_card_features is covering the need. It is very complete, allowing full control of the feature, but it is a bit too complex if you want for example to just add a few buttons to show the state of a few entities and toggle them...

My initial dream is only button row. You could choose the number of button you need in this row (or add buttons as you need them),
then for each button, with the same level of customisation and same interface as as for a Tile card you could:

• choose an entity that will pilot default appearance and actions of this button (same look and behavior as the tile card icon)
• customise the content (icon and color, maybe icon could be replaced by a text there if not too complex)
• adjust the visibility (optional, but could allow to create conditional buttons depending on scenarios)
• adjust the action (toggle the selected entity, display the more info of the entity, navigate, launch an action...) (with optional hold and double tap action in yaml as for the Tile card)

[oerix]

Much needed feature, main reason why I'm sticking with Mushroom template card.

[BBE-FR]

Moreover, the latest version of Mushroom template card now allow to use features.

Thus you can have the full versatility with mushroom + custom-card-features for a full compatibility with tile look and a full control of the feature.

This was basically my request, but performed in mushroom, not in core cards...

[oerix]

@BBE-FR Yes, native templating within the editor. Also, another request would be to hide 'Badges' for Tile cards, without any hacky workarounds like card-mod or custom cards.

[BBE-FR]

@oerix true. I have added this in the 1st post.

[MindFreeze]

A hide_badge option seems reasonable. We already offer configuring this for the area card.

[BBE-FR]

That would be nice.

If we could consider also hide name and hide state like described in the "Full control of element to be displayed" part of the first message, the versatility of the Tile cards would become huge !

I know that there is the tap action issue (body tap vs icon tap) if you "remove" body (when name AND state are hidden) or icon, but I think it deserves a proper thinking.

[BBE-FR]

To develop a little bit on Tile cards and devices :

Interesting discussion here: https://github.com/orgs/home-assistant/discussions/1042

Devices could be part of the Tile card (either a new tile card for devices, or a way to link a device to a tile card) to allow to display state or features of other device related entities inside a single tile cards.

The example of a smart plug is a very good exemple of a Tile that could allow:

• control the "main" or "selected" entity of the device (example the switch for a smart plug)
• display information of the other entities from the device (example for a smart plug: state of the switch, power, energy)
• display any feature of the other entities from the device (example for a smart plug: a minigraph of the power and/or the toggle feature of the switch).

This could allow compact display of device related information.

[MindFreeze]

We had a PR for an unrestricted button feature and it was rejected by UX because it allowed users to do things unrelated to the selected entity. For the example above, this looks like a better area card. We have a task to make area card actions more configurable but we haven't even clearly defined it yet.
A related feature that I have been asking for is to display the state of entities from the same device. For example power consumption or battery level. It was discussed that we should have a device card for this similar to the area card. The consensus is that we would like to have this but no one is working on it yet.

[BBE-FR]

Thus as said in french "les carottes sont cuites" or in English "The fat lady has sung"...
Neither template nor customizable button appears to have any short term future in core and even PR will be refused...

back to HACS...

[BBE-FR]

Thanks @MindFreeze to have taken the time to give a proper feedback. Very appreciated!

And thanks for the latest addition to Tile card that you provided, I hope to continue to see small evolution of it, this FR is still relevant: https://github.com/orgs/home-assistant/discussions/487 and most of your contribution where in the right direction to kill it (imho).

[MindFreeze]

I started working on the area card task btw home-assistant/frontend#27512

[BBE-FR]

I have seen this home-assistant/frontend#29025

Promising !

Might be the new basis on my dashboard instead of one of my two current solution if versatile enough !

• stack-in-card + mushroom template + mushroom chips (for button row)
• tile with a template sensor (for template capability into Tile) + custom features (for button row)

Plus maybe the picker you propose could become available in other cards.

[BBE-FR]

Closed based on latest discussions showing that template or customisable button will be continuously refused by the core frontend team.

For those (like me) still having the need for templating or additional row of button in a tile, You need to head to HACS for these capabilities:

• mushroom for template or a template helper displayed in a "Tile" (because too much template could cause perfo issue=> ref this comment: https://github.com/orgs/home-assistant/discussions/489#discussioncomment-15485296)
• custom features for button row (because buttons are not entity related and will not be implemented in tile=> ref this comment: https://github.com/orgs/home-assistant/discussions/489#discussioncomment-15486780)

to create your own "super Tile":

I have understood that Tile is strickly entity related, and thus no control outside the entity will be accepted.

I consider it a valid but restrictive choice.

It will force to create other cards to tackle some "extra entity" display or control needs that could have been tackled by a single "super tile" or even only by features:

• area related display and control => the existing area card is doing that with limited customization possibilities => need partially covered.
• device related display and control => not covered yet, one use case: a smart plug: if you want to display state (on/off), control it (toggle) and display the actual power output => it is not feasible in a single card (excepte entities). Additionaly, all devices may not be covered if some thing are out of device scope (ex, the command to send my vacuum robot to specific rooms are scripts, because not proposed by the official integration, I rely on actions => I wont be able to fit it in a strict "device" card)

=> this could also be covered by an evolution of the entities card with a Tile / feature design

• label related display and control => possible future evolution. Why not use more labels in frontend, to allow specific display / control. UX/UI to be defined, but there could be a link with the current creation of area / label "target" trigger and conditions in automation world. use cas: a card to display/control my "Christmas lights", all boolean and climate associated to "automation of heating", etc...

[BBE-FR]

@laupalombi another shameless self promotion for some frontend concepts... very low probability that this closed FR would fall under your eyes otherwise, but many interesting discussion held there and concepts discussed here.

Again, no complain, just feed for though...

[BBE-FR]

Also tagging @mbb365 for the same reasons as Lau just above.

Some feed for thought not easily accessible in a closed FR...

[Mariusthvdb]

adding a single FR to this, consider the current input_datetime and a custom time-picker card resulting in

how sweet it would be to have that built with a stock tile card. Seems all the elements are there (compare open/close up/down for covers)

edit

I now notice this is closed. Ill open a separate FR/Discussion

[Liquidmasl]

I am currently building a mosaic custom card thats just a container really to place arbitrary other cards into it, overlyaing, next to another, etc.
it will just look like a single card, while having in there whatever a user might want to have.

I think it is strange that this needs a custom integration at all though, I wish i could just 'merge' cards on lovelace. Put an tile card for a light from col 0-10 and then a button from 10-12, merge them, now they look like 1 card, full flexibility with minimal friction.
But I hope my projects works smooth enough that it might be adopted at some point

[BBE-FR]

I already use your excellent fork of vertical stack in card : https://github.com/Liquidmasl/nested-lovelace-card

The base of my Dashboard (up to last week) was mainly this one with a mushroom card "nested" with a line of chips.

I changed all my "room cards" to migrate to mushroom template with a custom feature to get rid of card mod and position issues.
But still use nested lovelace cards whenever i need to fuse two cards.

Thx a lot to continue this project !

[Liquidmasl]

Hey awesome!
Since I started maintaining it, I was about to basically rewrite it for a bunch more functionality. Since I noticed that its scope kinda... exceeds a simple update I started implementing the mosaic card, which can do the same as the nested lovelace card but better, hopefully. It will eventually replace the fork.
But I will try to make it a 1 click, optional, migration.

The new card should support completely free placement of cards in a grid, even overlapping. So everyhting that is possible in nested right now will be in there as well, and hopefully the rest as well.
Getting a sweeet visual editor to work for this is a bit of a challange. I want drag and drop and reactive menues and no yaml. We will see.

I am stoked that I accidentally commented a discussion here where the OP is one of the few people who uses my card tho :D

[BBE-FR]

I want drag and drop and reactive menues

That would be perfect !

Basically the need is to transform a "smaller" section into a card...

I am stoked that I accidentally commented a discussion here where the OP is one of the few people who uses my card tho :D

In the french speaking forum, we were a batch of users of the vertical stack in card... and I promoted your card lately thus I assume I am not alone to have migrated...