heck yes, many config used other entities than sensor.time. As a matter of fact, most of the entity_id’s I used were other entities for triggering the update.
Also, I used scripts to update the template sensor that without an entity_id set in the config wouldn’t update by itself.
in the case of my earlier posted unavailable template sensor:
- platform: template
sensors:
entities_unavailable:
# entity_id:
# - script.update_entities_uun
# - automation.check_for_unavailable_entities
friendly_name: Entities Unavailable
value_template: >
making sure this only ran on demand, because it was only needed to run on demand, and not constantly.
or like this, including sensor.time, making sure it ran, once a minute, but also on demand by the state change of the boolean (which was automated, so notifications ran immediately:
github_repo_updates:
friendly_name: Github repo updates
# entity_id: input_boolean.github_repo_update, sensor.time
value_template: >
{% set updates_on = states.input_boolean
|selectattr('entity_id','in',expand('group.github_repo_updates'))
|selectattr('state','eq','on')|map(attribute='name')|list|count %}
{{updates_on}}
attribute_templates:
updates: >
{% set updates_on = states.input_boolean
|selectattr('entity_id','in',expand('group.github_repo_updates'))
|selectattr('state','eq','on')|map(attribute='name')|list %}
{% if updates_on|length == 0 %}
No Updates..
{% elif updates_on|length == 1 %}
The {{updates_on[0]}} repo has an update available
{% elif updates_on|length == 2 %}
The {{updates_on[0]}} and {{updates_on[1]}} repos have updates available, please check
{% else %}
The {{updates_on[:-1]|join(', ')}}, and {{updates_on[-1]}} have updates available, please check
{% endif %}
the above example shows something else, might I ask that here: would be really cool if we could have global templates (call them variables if must) per template entity, so we can use that for all templates in that sensor. As you can see we need to double up on the yaml code now, while it could be so much shorter (and less error prone because of that).
like:
github_repo_updates:
friendly_name: Github repo updates
variable:
update_on: >
{% set updates_on = states.input_boolean
|selectattr('entity_id','in',expand('group.github_repo_updates'))
|selectattr('state','eq','on')|map(attribute='name')|list %}
# entity_id: input_boolean.github_repo_update, sensor.time
value_template: >
{{updates_on|count}}
attribute_templates:
updates: >
{% if updates_on|length == 0 %}
No Updates..
{% elif updates_on|length == 1 %}
The {{updates_on[0]}} repo has an update available
{% elif updates_on|length == 2 %}
The {{updates_on[0]}} and {{updates_on[1]}} repos have updates available, please check
{% else %}
The {{updates_on[:-1]|join(', ')}}, and {{updates_on[-1]}} have updates available, please check
{% endif %}
I have several templates for which I have created an extra backend sensor to use like this, but that is way more complicated, and of course creates yet another sensor …
check this:
weather_icon_backend:
# entity_id: sensor.dark_sky_icon, weather.dark_sky, weather.buienradar
# friendly_name_template: >
# {{states('sensor.weather_icon').split('weather-')[1]|title}}
value_template: >
{% set mapper_icon =
{'partly-cloudy-night':'night-partly-cloudy'} %}
{% set mapper_br =
{'pouring':'pouring',
'lightning-rainy':'lightning-rainy',
'snowy-rainy':'snowy-rainy'} %}
{% set mapper_ds =
{'clear-night':'night',
'partlycloudy':'partly-cloudy'} %}
{% set icon = states('sensor.dark_sky_icon') %}
{% set buienradar = states('weather.buienradar') %}
{% set dark = states('weather.dark_sky') %}
{% set weather = mapper_icon[icon] if icon in mapper_icon else
mapper_br[buienradar] if buienradar in mapper_br else
mapper_ds[dark] if dark in mapper_ds else
dark if dark in
['sunny','rainy','snowy','snowy-rainy','windy','fog','cloudy','hail','lightning']
else 'sunny-alert' %}
mdi:weather-{{weather}}
# icon_template: >
# {{states('sensor.weather_icon')}}
weather_icon:
# entity_id: sensor.dark_sky_icon, weather.dark_sky, weather.buienradar
friendly_name_template: >
{{states('sensor.weather_icon_backend').split('weather-')[1]|title}}
value_template: >
{{states('sensor.weather_icon_backend')}}
icon_template: >
{{states('sensor.weather_icon_backend')}}
which, btw, is another fine example of a sensor using more than sensor.time for entity_id’s 
)
) and they still do AND my processor use has fallen (I seem to be an exception I know, but look at the efficiency difference elicited by looking at specific states (and attributes) rather that EVERYTHING that this entity_id represents)
. I cannot reply to all that, sorry.