Custom-ui was developed a long time ago, before Home Assistant introduced the modern Dashboard (Lovelace). Home Assistant has evolved significantly since then, so most users no longer need custom-ui.
Theming and the use of state-colors in the Frontend have become very powerful and should be your first choice for customizing colors based on states.
If you need more, especially if you want to use templates, consider using the custom Card-mod, which allows the user to modify almost anything in the Dashboard views (the Frontend).
Only as a last resort should you consider using custom-ui, and only in those cases where you need more power and control.
The use of the templating feature on all attributes (yes, custom-ui is that powerful) should be discouraged because it interferes with entities in the Home Assistant state machine (the back-end).
The Core development team consistently emphasizes the importance of maintaining as clean a state machine as possible and warns against overloading it with (custom) attributes, especially templating those attributes.
So, again, only use custom-ui if you know what you are doing and if no other option is available.
We can customize entities in core Home Assistant. However, this is rather limited. Two of the most important features Custom-ui offers on top of the core customization are support for:
- Templates
- icon_color attribute.
We can use these features globally in our Home Assistant configuration and thus create extremely powerful yet very compact customizations. Added to that, custom-ui allows one to hide attributes from the more-info pane. Check the examples how.
Please see the pinned discussion on development of this plugin.
In short:
- If you want a tool to customize icon_color: Use either custom-ui (with template support) or custom-icon-color.
- If you want a tool to customize more-info dialogs: Use custom-more-info
Current custom-ui (with legacy more-info manipulation) will be archived, and renamed, so we can keep the custom-ui name for the current custom-ui-only.
New Custom template attributes
All modifications in my entire config are now implemented using Card-mod. I am aware this only works in the actual cards in the View, and not on the more-info dialog of entities. It is an acceptable trade-off between optimal desktop customization, and optimal core handling of the state machine.
In the end, the best way forward is to avoid overloading the state machine with custom elements as much as possible..
There is only 1 modification I 'need', that can't be done with card-mod.
My person's entity_picture need to grayscale when not_home
, specifically in the type: map
cards.
Currently we can succesfully set a css filter in most other regular cards with card-mod, but those modifications do not affect the Map card.
For that purpose, and that purpose alone, this new custom-attributes-templates
now sees the light.
In all honesty, I hope this can be deleted as soon as core Home Assistant would provide other means to do so.
There is however not a single hint entity_picture will ever be leveraged (we can not even set an entity_picture in the UI and need customize:
in Yaml for that), eg. like we can now do with state-colors.
Until that moment, this will have to do:
homeassistant:
customize_domain:
person:
templates:
entity_picture: >
var id = entity.entity_id.split('.')[1];
return state === 'not_home'
? '/local/family/' + id + '_not_home.png' : '/local/family/' + id + '.jpg';
I purposely do NOT provide an easy way to download it via HACS, or plan a release. The file can be downloaded from the list above, and installed like any other resource:
- url: /local/resources/custom-attributes-templates/custom-attributes-templates.js?v=202400815
type: module
New Custom More-info
Custom More-info is a new custom Plugin for Home Assistant and superseeds the plugin custom-attributes
announced below.
Next to the functionality of custom-attributes
, with custom-more-info
users can customize when and when not to display the History and Logbook sections in the More-info card. Even hide the History icon in the Header completely. Automatically, or based on manual settings.
From now on you are in control of the More-info attributes and all other sections. Filter all, unfilter all, or select which to see/hide by glob, domain, device_class, or entity_id. Any combination is possible!
Custom More-info gives the user ultimate control over the More-info panel.
New Custom Attributes
Custom attributes is a new resource for Home Assistant to customize which entity attributes are displayed in the Dashboard on more-info cards. Moreover, if configured so that no more attributes are left to display (all attributes are filtered), the attributes dropdown box is not rendered at all. This is replacing that specific functionality from Custom-ui.
DON'T INSTALL BOTH CUSTOM-ATTRIBUTES AND CUSTOM-MORE-INFO SIMULTANEOUSLY. USE ONLY 1 OF THESE 2 NEW PLUGINS
New Custom icon_color
A new custom-ui sibling was released, custom-icon-color, which can be used only for adding an attribute in customize:
and the attributes configuration options of template: entities.
No more templates possible with this version, which minimizes impact on the HA system and Frontend if you wish to do so. There was never a huge impact, but this brings it down even further, if you don't need the template options and still want the icon_color attribute in your options. Configuration is identical to what is already explained in the example section
Did you know....: custom-ui facilitates setting a Jinja template on custom attributes in core integrations that allow setting a custom attribute.
-
Download the custom-ui
-
Place the file in your
config/www
folder or any subfolders. -
Include the card code in your
ui-lovelace-card.yaml
title: Home resources: - url: /local/custom-ui.js type: module
or when using the UI, click
-
Make sure the HACS component is installed and working.
-
Search for
custom-ui
and add it through HACS -
Add the configuration to your
ui-lovelace.yaml
resources: - url: /hacsfiles/custom-ui/custom-ui.js type: module
-
Refresh home-assistant.
See INSTALLING
See EXAMPLES.
For card-mod replacement mods, see CARD-MOD-EXAMPLES
It goes without saying that custom-ui is an extension of core Home Assistant functionality. As such, you should understand what is documented on Homeassisant.io about the subject.
Important to note, is that Home Assistant core Jinja templating is calculated in the back-end, server side, (the device Home Assistant is running on). Custom-ui Javascript templating is calculated in the front-end, browser side, (the device Home Assistant is displayed on).
Heavy templating might impact the performance of the system and will depend on processor power and memory available on either side of your devices.
Custom-ui can't customize everything. Entities created in python scripts (you need to set the customization in the script itself) and entities created by several add-ons can't be touched by custom-ui. E.g. Home Assistant Google Drive Backup. You can work around that by creating template sensors for those entities, which you can again customize in HA.
Also, do notice that changes to configuration used by this plugin will only apply on the state change of the related entity. Thus, if you have already reloaded your new YAML config via Developer Tools > YAML > Location & Customizations, but it didn't "kick in", try to force a state change in the entity you're testing
Not all core HA cards use the same icon handling. Because of that, cards like
are not customized by custom-ui
.
Thomas Loven's Card-mod, which is an amazing plugin for Lovelace with many features, to the rescue.
Be aware that custom-ui is very impactful. As a matter of fact, it is 'stronger' than card-mod.
Meaning if you have e.g. a customize_glob
on icon_color
set using custom-ui, any card-mod
config won't work.
I've been a longtime and heavy user of custom-ui, and this is the place to applaud Andrey for his amazing plugin. Home Assistant wouldn't be the same without the global customizing it enables us to do. Couldn't live without it! All credits go to @andrey-git. You can read up on a bit if history how it came to this adapted version.