I’m starting to spend time on customizations and I’m finding the “Reload Core” functionality to be unreliable in getting Hass to recognize my changes. Sometimes it seems to work, but most of the time I have to restart to see any changes. Most of what I’ve been changing so far are friendly names and hiding entities that I don’t care about, but restarting will get more and more tedious as I make more complicated changes. Here’s the beginning of my configuration.yaml:
homeassistant:
# Name of the location where Home Assistant is running
name: Home
# Location required to calculate the time the sun rises and sets
latitude: xxx
longitude: xxx
# Impacts weather/sunrise data (altitude above sea level in meters)
elevation: xx
# metric for Metric, imperial for Imperial
unit_system: imperial
# Pick yours from here: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
time_zone: America/Los_Angeles
# Customization files
customize: !include customize.yaml
customize_glob: !include customize_glob.yaml
My customize.yaml has a bunch of these:
sensor.zone_001:
friendly_name: Living Room Left Window
sensor.zone_002:
friendly_name: Living Room Right Window
sensor.zone_003:
friendly_name: Living Room Rear Window
sensor.zone_004:
friendly_name: Living Room Rear Door
sensor.zone_005:
friendly_name: Front Door
sensor.zone_006:
friendly_name: Garage Door
sensor.zone_007:
friendly_name: Office Window
sensor.zone_008:
friendly_name: Dining Room Right Window
sensor.zone_009:
friendly_name: Dining Room Door
sensor.zone_0010:
friendly_name: Dining Room Left Window
sensor.zone_0011:
friendly_name: Family Room Sliding Glass Door
That’s just a sample - there are more friendly name changes and some “hidden: true” entries as well. I know that Hass is loading the file when I hit “Reload Core” because it’ll spit out an error if I leave out a colon or otherwise mess up the format. Still, if I reload the browser page without cache (shift-reload) and try changing the state of the item, the customizations don’t seem to “take”. Even with logging set to “debug”, there just isn’t much information about what’s happening during the reload. I don’t see the friendly names being updated in Lovelace, and I don’t see the new values reflected in the dev-state page. Even with a browser cache issue, I would think that the changes should at least show up in the state page.
I only have a couple of items in the “glob” variant, and commenting it out entirely doesn’t help. The only reliable way to get changes to load is to restart Hass (3-4 minutes until my Z-Wave network is ready to go).
Is there some magical incantation that I’m missing?
I tried that too, but it seems to do the same as Configuration->General>Reload Core. Still no updates. I didn’t know about frontend.reload_themes, so I’ll keep that in mind.
Do you changes just show up without any additional work? Should I just be able to go into dev-state and see friendly_name & hidden updated, for instance?
Yes, I’ve tried that and a different browser. Should dev-state reflect the changes right away? It seems like that would help eliminate the browser cache if it’s a problem. In my case, dev-state still reflects the old values.
After trying lots of different tactics over the course of an hour or two to get the changes to show up without restarting, I finally restarted Hass and they showed up right away.
I just tested and same behavior. The one way it does update without a restart is through Configuration->General->Customization and updating it there. It’s odd because loading the device there shows the updated name after doing “Reload Core”, but it isn’t used anywhere else until saving it on that page.
Yep, I can confirm that that works. I manually edit customize.yaml, save, reload core, and go into Configuration->General->Customization->pick node, and I see the new (in this case) friendly_name there. When I hit “save” for that node without making any changes, it updates everywhere. Thanks for the tip.
I do have to “touch” each and every node that changed, so it’s only slightly less work than just making the changes manually in the GUI, though, and I don’t think it’s how it’s supposed to work based on lots of prior threads. Sounds like a bug?
Possibly, or it’s just a limitation of the way states are updated. I looked at the code and I’m not quite sure.
The configuration panel will change the friendly name in the config and then tell HA to update the state of that entity, which is what triggers the name to appear as changed.
Reload core, on the other hand, simply reads in the new values but doesn’t tell HA to update any entities. Which makes some sense, because it doesn’t know which one(s) changed and it could be pretty resources intensive to update the state of every entity just to update a friendly name or two.
However, reload core does actually work. You just have to wait until the value of the entity changes before it gets reflected. I tested this by using a random sensor so the value would change frequently. After doing reload core, the friendly name will update the next time the state changes.
Thanks for investigating. That’s consistent with what the docs say here, but I tried flipping the state and still couldn’t get the entities to update. I kinda wish there was a way to just “touch” them.
New customize information will be applied the next time the state of the entity gets updated.
when you do a “reload core” the changes will only ever be reflected in the UI when the state of the specific entity that you changed is updated. If it doesn’t update you won’t see any change at all.
You could try using the service call homeassistant.update_entity. You could even try with entity_id: all. No idea if that would work though.
Edit: Quick test doesn’t seem to work. I wonder if it only works when the state actually changes.
Edit again: It does actually work for some platforms. Random binary sensor worked, demo device tracker didn’t (probably because it doesn’t really update its state).
That seems to work if I target a single entity, but not a group, and it doesn’t accept “all” (gives me an “invalid dictionary value” and I can’t pull it down from the drop-down list). Maybe this is a job for a short Python script…
It seems like a useful feature request. Customization is pretty tedious otherwise. I wish there was an automatic “group.all_sensors” like there is for other device classes, but it looks like I’ll have to create one. I have lots and lots of sensors, and they’re usually the ones I care about displaying in Lovelace and customizing.
Eureka! Group expansion borrowed heavily from here (h/t to @pnbruckner), and still rough around the edges.
entity_id = hass.states.entity_ids()
expanded_a_group = True
while entity_id and expanded_a_group:
expanded_a_group = False
for e in entity_id:
if e.startswith('group.'):
entity_id.remove(e)
g = hass.states.get(e)
if g and 'entity_id' in g.attributes:
entity_id.extend(g.attributes['entity_id'])
expanded_a_group = True
logger.info("Updating entities")
for e in entity_id:
if not e.startswith(('group.',
'switch.',
'light.',
'sensor.',
'binary_sensor.')):
continue
if e.startswith('sensor.custom'):
continue
service_data = {'entity_id': e}
hass.services.call('homeassistant',
'update_entity',
service_data)
logger.info("Finished updating entities")
And it seems to work. Customizations appear in Lovelace and in dev-state. I love that whenever I find something in Hass frustrating, I can just go fix it
Because I wanted to exclude those particular sensors. But this was 2 years ago and can’t remember why . The first check rejects everything that isn’t one of those things (letting sensor.* through) and the second rejects some of the sensors.
I’ve added some extra logging and see in the log that my template sensors are found and update_entity executed for this sensor… but no magic, no changes in the UI.
entity_id = hass.states.entity_ids()
expanded_a_group = True
while entity_id and expanded_a_group:
expanded_a_group = False
for e in entity_id:
if e.startswith('group.'):
entity_id.remove(e)
g = hass.states.get(e)
if g and 'entity_id' in g.attributes:
entity_id.extend(g.attributes['entity_id'])
expanded_a_group = True
logger.info("Updating entities")
for e in entity_id:
if not e.startswith(('group.', 'switch.', 'light.', 'sensor.', 'binary_sensor.')):
continue
service_data = {'entity_id': e}
logger.info("Updating: " + str(service_data))
hass.services.call('homeassistant', 'update_entity', service_data)
logger.info("Finished updating entities")
I haven’t used it in probably a year and a half, so I don’t know if it still works. I only used it in conjunction with custom_ui, and I moved away from that long ago. You can try calling homeassistant.update_entity from Dev->Services and see if that works before trying to debug the script any further.
