Maybe I am missing your point, but why don’t you use the service homeassistant.update_entity in the automation, for the sensors you want to update each second ?
It’s not about updating sensors by using an automation. Of course if there were only a few sensors you wanted to update every second and that’s all you wanted a one second resolution update interval for then I would agree.
But remember you need to first build the sensor and then create an automation to cause the one second update for the sensor.
using this update counter you can use it directly in the sensor template just like we used to need to do when we used sensor.time to update every minute. Then there is no further update automation required. You just have one automation and one counter updating every second in the background.
And it also allows you to use it in automations to compare now() to a date_time down to the second where right now it only works down to the minute without it (as in my example above).
Or it allows you to use it in dev-tools to auto refresh the page every second to test templates at one second resolution.
My point is that there are more than one use for this function aside from just updating sensors and it makes that sensor update functionality easier to do.
AT least, IMO.
What do you do that requires second resolution?
I was just helping someone yesterday with a blueprint that flashed lights at the completion of an echo timer. I tried to use now() to trigger the automation (then found that I got bit by that referenced bug) but then tried to make the condition for the timestamp of the entity state to be <= now(). But I found that the actions could be up to a minute delayed from the actual timer expiring because now() only updates at most every minute.
A one second update resolution would have made it less complicated to do the time calculations and run the actions at the correct time.
I’ve run into this with other things but just accepted the one minute update and moved on because most of the time it’s no big deal.
The experience in the other thread made me realize there are times it would be helpful to have that functionality so I made it available if I needed it.
I can’t see the downside to having a one second “heartbeat” counter available. 
Ah, got a link to that blueprint?
1 Like
maybe create a template sensor:
second_updater:
value_template: >
{{(now() - states.sensor.time.last_changed).total_seconds()|int}}
and use your automation to update that each second:
automation:
- alias: Second updater
trigger:
platform: time_pattern
seconds: '/1'
action:
service: homeassistant.update_entity
entity_id: sensor.second_updater
with should be usable now for all your demands?
must confess I dont know what the impact on the system would be though.
I’m not sure what you are meaning.
I have already created the functionality I need as I posted above and it’s working fine. it mimics a second hand (or the digital equivalent) so you can match the time down the second if needed.
I’m not sure your solution does that.
sorry, but I thought this is what you needed, and the template sensor seems much easier than the timer setup:
one can use this sensor as trigger in all other configs.
1 Like
It looks like it offers the same functionality. If I had seen yours first I might have actually used it instead
But with the last change to the code above for mine it seems to be matching the second exactly the majority of the time (if that is important) but yours seems to be a second off from the real seconds (if that is important 
) so I’ll stick with mine for now.
Thanks for posting that tho. It’s always good to have alternatives.
Ha, hadn’t even noticed that, and yes that seems logical.
Cool.
of course, I should have simply used
{{now().strftime('%-S')}}
for the template sensor. what was I thinking…
and fyi, this follows the true seconds of the machine, no lag at all.
1 Like
I think I’ll actually use yours instead now.
It is more simple.
Thanks!
Home Assistant 2021.4 will include trigger-based template sensors. These will disable the template update mechanism discussed here and instead update when a trigger matches. With this, I think some more use cases from this thread are covered; for example to only update at midnight and to never update. It should even be possible to make a trigger that matches state change events for specified entities.
As this is currently in beta, now would be a good time to point out if you see issues with it.
3 Likes
Yes! As I’ve applauded your suggestion on Discord, please add the option indeed. Adding
trigger: []
to replace the former ‘entity_id’ and have it not updated using that is a great tool to add. allowing 100% enduser control (in a non hacky way )
I saw the PR awhile ago, thought it was a very good addition, but didn’t fully appreciate the extent of this new feature’s usefulness. Thanks for explaining some of the long-standing pain points it mitigates.
For example, I recently wanted a simple Template Binary Sensor to indicate the Christmas season. Basically, it would be on for about a month and a half. However, the template’s time calculation, employing now(), would be computed every minute (when it only needs to be done every day). In other words, the template only needs 365 evaluations annually, not the 365 * 1440 it will perform.
I believe the trigger-based template sensor will allow me to trigger on sensor.date (i.e. once a day) then compute the template’s time calculation. Regardless of how many spare CPU cycles are available, this is simply a more efficient technique. I look forward to trying it when released next week. 
as Frenck explained, it can trigger on any trigger we now have in automations, that includes template trigger.
Which makes this a hugely powerful sensor platform. adding the suggested trigger: [] would make this an ultimate solution to, well, to anything really.
just wait for variables too
Yeah … or you can use a time: trigger to trigger at: 00:00:00 and avoid the sensor.date helper.
(However, I think binary sensors are not supported in the initial implementation)
1 Like
Good tip, thanks! I was still thinking in the old (and deprecated) “entity_id” mindset.
Good to know; fortunately, a Template Sensor (with on/off states) will work for my intended application. If and whenever Template Binary Sensor is supported, I’ll re-configure the entity.
Hmm, I think I didn’t grasp the concept correctly. This is effectively a new integration, namely Trigger Template, and not a modification of the existing Template (or Template Binary) integration. Nevertheless, it’s still a perfect fit for my intended application.
There are implementation details that cause little code reuse but I don’t see how that changes the concept per se?
… ah, maybe it doesn’t 