All my integrations & frontend are installed via HACS.
Never had any problem with it.
It is located in HA/www/community/custom-ui folder:
just for the sake of testing, please adjust the var names:
friendly_name: >
var objName = entity.entity_id.split('placeinfo_')[1];
var place = 'sensor.place_' + objName + '_xxx';
return place;
or:
friendly_name: >
var objName = entity.entity_id.split('placeinfo_')[1];
return 'sensor.place_' + objName + '_xxx';
just to be sure, you didnāt see any JS errors in inspector? because the only other thing I could think of, is the entity or the attribute does not exist, and itās simply not able to perform the template. In which case you should add a guard one that (always guard templatesā¦)
it could explain why the one template works, and the other doesnāt, making that a user errorā¦
This should not affect, JS has nothing bad about capitals.
Actually, my customization now DOES work - and I missed a moment when exactly it started working.
But I did not change anything about these sensors - I just started changing some other code not related to these topic, without touching HACS & without HA restarts.
I see some errors not related to the topic, smth about "tracker-card " (which I have been seeing for many months).
Since there is no JS debugging tool like we have for jinjia2 (āTemplateā tab), I rewrote my JS code to jinjia2 code and tested it in the āTemplateā tab, it works without any doubts.
Looking at this code, I have no idea which checks should I add:
friendly_name: >
var OBJ_NAME = entity.entity_id.split('placeinfo_')[1];
var SENSOR_PLACE = 'sensor.place_' + OBJ_NAME + '_xxx';
return SENSOR_PLACE;
Great, so probably cache after all, and your entities changed state.
As for the guards, have a look at the āsupport_custom_uiā button-card template how to do that
Cleaning cache, restarting HA, restarting browser do not help.
I have no idea what caused HA to change states.
Now I just restarted HA without making any changes in code - and customization again does not work.
Yesterday it started working because of unknown reasons - now it again not working.
Erratic behaviour.
really sorry to hear about your troubles, and I would love to help you out if I can where possible.
Must say, my custom-ui is rock solid on 3 instances, on 2 of those the customizations sometimes take a few seconds to kick in. Have been looking into this, and for now I can only suspect it to have to do with a connection to the backend states.
I have really complex customizations, and a lot of them, and a huge (not my words) install.
Did you notice any difference between the devices you are using? Maybe a weaker device cant handle it as well a more modern one?
Marius, thank you for your support!
Now I am testing on a VmWare on a rather powerful gaming PC.
The only thing that I may suspect is a HACS. May be Custom UI is not installed correctlyā¦
Some customizations work - but not always, even w/o any changes of code ))) .
Got a new issue.
Letās consider this sensor:
sensor:
- platform: template
sensors:
newtest_placeinfo_ildar:
friendly_name_template: "{{ 'ildar' }}"
...
This is how this sensor looks in Glance card:
type: glance
entities:
- entity: sensor.newtest_placeinfo_ildar
Now I need to show the sensor in Logbook card:
type: logbook
entities:
- sensor.newtest_placeinfo_ildar
hours_to_show: 24
So far it is OK, friendly_name works.
Then letās define the friendly_name by Custom UI (the code for friendly_name described above is commented):
homeassistant:
customize_glob:
sensor.newtest_placeinfo_*:
templates:
friendly_name: >
return entity.entity_id.split('placeinfo_')[1] + '_CustomUI';
The Glance card:
The Logbook card:
Seems that friendly_name does not work.
Is it a known bug?
Also, in my setup "auto-entities::template" does not see added attributes.
I have already wrote about it.
A small example:
The almost same sensors as mentioned above:
homeassistant:
customize_glob:
sensor.newtest_placeinfo_*:
templates:
friendly_name: >
return entity.entity_id.split('placeinfo_')[1] + '_CustomUI';
some_id: >
return entity.entity_id.split('placeinfo_')[1] + '_id';
First a list w/o using added attributes:
type: custom:auto-entities
card:
type: entities
entities: null
unique: entity
show_empty: true
filter:
template: >
{% for state in states.sensor -%}
{%- if state.entity_id | regex_match("sensor.newtest_", ignorecase=False) -%}
{{ {'entity':state.entity_id } }},
{%- endif -%}
{%- endfor %}
Next a list w/o using added attributes, but with changed name:
type: custom:auto-entities
card:
type: entities
entities: null
unique: entity
show_empty: true
filter:
template: >
{% for state in states.sensor -%}
{%- if state.entity_id | regex_match("sensor.newtest_", ignorecase=False) -%}
{{ {'entity':state.entity_id, 'name':'aaaa' } }},
{%- endif -%}
{%- endfor %}
And now a list with added attributes:
type: custom:auto-entities
card:
type: entities
entities: null
unique: entity
show_empty: true
filter:
template: >
{% for state in states.sensor -%}
{%- if state.entity_id | regex_match("sensor.newtest_", ignorecase=False) -%}
{{ {'entity':state.entity_id,'name':state_attr(state.entity_id,'some_id') } }},
{%- endif -%}
{%- endfor %}
So, the added attributes are not visible for the "auto-entities::template".
The customization works:
type: entities
entities:
- entity: sensor.newtest_placeinfo_ildar
- type: attribute
entity: sensor.newtest_placeinfo_ildar
attribute: some_id
name: some_id
missed this additional posting. sorry for a later reply.
on the logbook: Ive discussed this on Discord with Bram, and the Logbook works differently:
Custom UI probably expects an current state object on the state badge, but the logbook doesnt have that as it is not a current state.
about the template in auto-entities: I can not reproduce, and showed that it works on my side before, I posted the config above. I did also check on an added attribute (Package: Test) and that worked fine too,. this was on individual entities, so will test on a glob too, to see if that makes a difference.
TESTED:
no, it does not, and it works perfectly:
homeassistant:
customize_glob:
'*.test*':
# templates:
# friendly_name: >
# var splitfname = entity.entity_id.split('test')[1];
# var fname = 'Friendly name changed to: ' + splitfname;
# return fname;
test_attribute: test
Lovelace:
- type: custom:auto-entities
card:
type: entities
title: Template Attribute test
filter:
template: >
{{states|selectattr('attributes.test_attribute','eq','test')
|map(attribute='entity_id')|list}}
Frontend:
You are testing this with very complex situations, maybe start somewhat simpler and build from that on, so we can really find what is causing an issue.
Actually, these cases are very simple, are not they?
homeassistant:
customize_glob:
sensor.newtest_placeinfo_*:
templates:
friendly_name: >
return entity.entity_id.split('placeinfo_')[1] + '_CustomUI';
some_id: >
return entity.entity_id.split('placeinfo_')[1] + '_id';
type: custom:auto-entities
card:
type: entities
entities: null
unique: entity
show_empty: true
filter:
template: >
{% for state in states.sensor -%}
{%- if state.entity_id | regex_match("sensor.newtest_", ignorecase=False) -%}
{{ {'entity':state.entity_id,'name':state_attr(state.entity_id,'some_id') } }},
{%- endif -%}
{%- endfor %}
did you first test with a fixed added attribute, like I did above?
The customization:
homeassistant:
customize_glob:
sensor.newtest_placeinfo_*:
templates:
friendly_name: >
return entity.entity_id.split('placeinfo_')[1] + '_CustomUI';
some_id: >
return entity.entity_id.split('placeinfo_')[1] + '_id';
some_fixed: >
return 'fixed';
The Entities card:
type: entities
entities:
- entity: sensor.newtest_placeinfo_ildar
- type: attribute
entity: sensor.newtest_placeinfo_ildar
attribute: some_id
name: some_id
- type: attribute
entity: sensor.newtest_placeinfo_ildar
attribute: some_fixed
name: some_fixed
Now the auto-entities:
type: custom:auto-entities
card:
type: entities
entities: null
unique: entity
show_empty: true
filter:
template: |
{{states|selectattr('attributes.some_fixed','eq','fixed')
|map(attribute='entity_id')|list}}
The card:
Does not work.
youāve added the fixed (non template) attribute under templates: .
Please add it under the entity like I did.
Customization:
homeassistant:
customize_glob:
sensor.newtest_placeinfo_*:
some_fixed_2: fixed_2
templates:
friendly_name: >
return entity.entity_id.split('placeinfo_')[1] + '_CustomUI';
some_id: >
return entity.entity_id.split('placeinfo_')[1] + '_id';
some_fixed: >
return 'fixed';
The Entities card:
type: entities
entities:
- entity: sensor.newtest_placeinfo_ildar
- type: attribute
entity: sensor.newtest_placeinfo_ildar
attribute: some_id
name: some_id
- type: attribute
entity: sensor.newtest_placeinfo_ildar
attribute: some_fixed
name: some_fixed
- type: attribute
entity: sensor.newtest_placeinfo_ildar
attribute: some_fixed_2
name: some_fixed_2
The auto-entities:
type: custom:auto-entities
card:
type: entities
entities: null
unique: entity
show_empty: true
filter:
template: |
{{states|selectattr('attributes.some_fixed_2','eq','fixed_2')
|map(attribute='entity_id')|list}}
Seems that templated attributes do not work here.
well, not sure if I grasp this completely, but setting a fixed additional attribute by means of a template isnāt very useful, so I believe that not to be an issue?
the templated additional attribute could be interesting, but it can be challenging to use that in an auto-entities filter. What to template there? How would you know what to use in that filter, since the attribute is dynamic?
we could try:
templates:
custom_attribute: >
return entity.entity_id.split('placeinfo_')[1] + '_custom';
and in the lovelace card:
filter:
template: |
{{states|selectattr('attributes.custom_attribute','contains','custom')
|map(attribute='entity_id')|list}}
have to check the syntax here, because I donāt remember the exact filter for that in Jinja
EDIT:
dont think this will work, I can see the template in the dev/states but it isnt set.
Could be that we could add it to custom-ui, but I am not sure it is worth the trouble, since this is all very theoretical, and I wonder who would want thisā¦
you can probably do it using an attributes_template in Core jinja, and then add an anchor?
From simple to difficult: fixed attribute ā fixed templated attribute ā changing templated attribute.
Originally I had the 3rd case (does not work in auto-entities::template).
You proposed to simplify the case - so I tested with a fixed templated attribute (does not work), then I tested with a fixed attribute (does work).
- Your templated attribute could be like āhomeā or ānot_homeā - so you may want to use it as a filter.
- The
auto-entities::templateis not used ONLY as a filter - it is used to populate complex cards likemultiple-entity-row, so the added attributes are used to keep entity_ids of āpairedā sensors (just an example). This is not my fantasy, I am talking about a real implementation:
This card works fantastic - but I cannot use Custom UI here to add these attributes (here Custom UI is only used for icon color for batteries), all attributes were added by traditional way.
Update: Here each row has binary_sensor.battery_charging_xxx, sensor.battery_level_xxxx, device_tracker and some other additional data like āupdate alertedā, ālocationā - all this data are gathered using entity_ids (kept as attributes of the main entity - binary_sensor.battery_charging_xxx).
The customization:
homeassistant:
customize_glob:
sensor.newtest_placeinfo_*:
some_fixed_2: fixed_2
templates:
friendly_name: >
return entity.entity_id.split('placeinfo_')[1] + '_CustomUI';
custom_1: >
return entity.entity_id.split('placeinfo_')[1] + '_custom';
some_id: >
return entity.entity_id.split('placeinfo_')[1] + '_id';
some_fixed: >
return 'fixed';
The Entities card:
type: entities
entities:
- entity: sensor.newtest_placeinfo_ildar
- type: attribute
entity: sensor.newtest_placeinfo_ildar
attribute: some_id
name: some_id
- type: attribute
entity: sensor.newtest_placeinfo_ildar
attribute: some_fixed
name: some_fixed
- type: attribute
entity: sensor.newtest_placeinfo_ildar
attribute: some_fixed_2
name: some_fixed_2
- type: attribute
entity: sensor.newtest_placeinfo_ildar
attribute: custom_1
name: custom_1
The auto-entities:
type: custom:auto-entities
card:
type: entities
entities: null
unique: entity
show_empty: true
filter:
template: |
{{states|selectattr('attributes.custom_1','contains','custom')
|map(attribute='entity_id')|list}}
Does not work.
That was my first thought.
But this cannot be done, every template must contain some unique string like ildar, irina, mama, papa etc.
well, youāve run into a limitation of custom-ui.
It is extremely powerful, and can do an enormous amount of code limiting. But, it canāt do everything.
Feel free btw to PR this in the repo, and see if you can add it. If we can template the friendly_name like I have demonstrated, maybe we should be able to do that for another attribute tooā¦
Tbh, the bottom is not an issue of custom-ui, but simply incorrect jinja. there is no filter ācontainsā?
You create huge posts, with a lot of info, itās is entirely possible I havent seen it completely yet, so will have a look later on.
Marius, I think you are right. Wrong codeā¦
I would be happy to clarify any questions!
So far I use Custom UI only for:
- icon color for batteries;
- entity_picture for persons;
- some other minor things.
did a quick test, and verbosely copied the custom-ui friendly_name template I have working for ages to a custom_name attribute:
sensor.*_sensor_light_level_raw:
templates:
icon_color: >
if (state < 1) return 'black';
if (state < 3000) return 'maroon';
if (state < 10000) return 'firebrick';
if (state < 17000) return 'orange';
if (state < 22000) return 'green';
if (state < 25500) return 'gold';
if (state < 28500) return 'teal';
if (state < 33000) return 'dodgerblue';
if (state < 40000) return 'lightskyblue';
if (state < 40000) return 'lightblue';
return 'lightcyan';
friendly_name: >
function capitalizeFirstLetter(string) {
return string.charAt(0).toUpperCase() + string.slice(1).toLowerCase();
}
var id = entity.entity_id.split('.')[1].split('_sensor_light_level_raw')[0].replace(/_/g,' ');
var id = capitalizeFirstLetter(id);
if (state < 1) return id + ': dark';
if (state < 3000 ) return id + ': bright moonlight';
if (state < 10000) return id + ': night light';
if (state < 17000) return id + ': dimmed light';
if (state < 22000) return id + ': \'cosy\' living room';
if (state < 25500 ) return id + ': \'normal\' non-task light';
if (state < 28500) return id + ': working / reading';
if (state < 33000) return id + ': inside daylight';
if (state < 40000) return id + ': maximum to avoid glare';
if (state < 51000) return id + ': clear daylight';
return id + ': direct sunlight';
custom_name: >
function capitalizeFirstLetter(string) {
return string.charAt(0).toUpperCase() + string.slice(1).toLowerCase();
}
var id = entity.entity_id.split('.')[1].split('_sensor_light_level_raw')[0].replace(/_/g,' ');
var id = capitalizeFirstLetter(id);
if (state < 1) return id + ': dark';
if (state < 3000 ) return id + ': bright moonlight';
if (state < 10000) return id + ': night light';
if (state < 17000) return id + ': dimmed light';
if (state < 22000) return id + ': \'cosy\' living room';
if (state < 25500 ) return id + ': \'normal\' non-task light';
if (state < 28500) return id + ': working / reading';
if (state < 33000) return id + ': inside daylight';
if (state < 40000) return id + ': maximum to avoid glare';
if (state < 51000) return id + ': clear daylight';
return id + ': direct sunlight';
unit_of_measurement: lm
device_class: illuminance
and see, check the bottom line here:
which proves it can be done after all 
!
attribute custom_name changes immediately and together with the friendly_name and state. perfect!
thanks for having me test this, I wasnāt even aware we could do this ā¦
I lost you, what do you mean?
Now I do believe that we can add custom templated attributes (but cannot understand why they work erratically on my setupā¦). If not talking about that errata, the only things I dislike are:
- Logbook issue (no friendly_names)
- auto-entities issue (we discussed above)
I asked you about it a few days ago - it is possible to SHARE same code between separate templates?
For example, 3 templated attributes have same code on the first 5 lines.
the fact we can template the additional attribute was new to me.
and we can use those in auto-entities, Ive just tested this:
- type: custom:auto-entities
card:
type: entities
title: Template templated Attribute custom_name
filter:
include:
- attributes:
custom_name: '*'
and it works perfectly.
Logbook: no template works there, not only the friendly_names.
sorry missed that. we can use anchors, but only for complete sections, not for āthe first 5 linesā and then attach something else.
we can however be very crafty in JS templates, as Ive shown in my friendly_name template above, and forgo the need for explicit naming, as we need to do with jinja attributes templates per sensor.
please create a separate and dedicated post for that, so not wont drown in the many other things you say 
1 issue per post works best.
depending on the card, you can also have a look at the button card templates I use, where this function originated.
UPDATE:
just so you know, and I have seen that before in other places:
this didnt work:
customize_glob:
'*.test*':
templates:
custom_name: >
return entity.entity_id.split('.')[1] + ' custom';
but this does:
customize_glob:
'*.test*':
templates:
custom_name: >
var id = entity.entity_id.split('.')[1];
return id + ' custom';
Lovelace:
- type: custom:auto-entities
card:
type: entities
title: Templated Attribute custom_name
filter:
include:
- attributes:
custom_name: '*'
not sure if this is a bug, or a JS idiosyncrasy, will ask the devās about it. Rule of thumb: first set a var to the entity with any splits/pipes what have you. Secondly, use the var in the final return
Update:
asked Bram and he returned it shouldnāt make a difference. maybe I made a typo in (.') before, not sureā¦