Trigger-based template binary_sensor and still wrong last-changed

Configuration
1

This is an old issue - but hope smth is going to be changed?

There is a trigger-based binary_sensor:

input_boolean:
  some_flag:

template:
  - trigger:
      - platform: state
        entity_id: input_boolean.some_flag

    binary_sensor:
      - name: some_flag
        state: >-
          {{ trigger.to_state.state }}

which gives this nice history (up - input_boolean, down - binary_sensor):

изображение
изображение1218×91 3.05 KB

And assume that HA restarted recently.
One of the features of trigger-based template sensors is “their states survive after HA restart”.
And what is a use of it if still “last-changed” is reset at HA restart?
изображение

Yes, I heard about workarounds like “save last-changed as input_datetime helper, then show it as a secondary info”. But this is a fundamental thing, not a “let’s make our design follow Material 3 standards” stuff. And many people DO need to restart HA sometimes, so “restarting HA is a rare case” cannot be an excuse.

2

What if you are using {{ trigger.to_state.last_changed }} as an attribute of the template binary sensor?

3

Thank you, it probably could be a good workaround, but still it does not solve the problem.
Imagine that a user has 100+ binary sensors, he needs to repeat same code for the “my_last_changed” attribute, then use some custom card to display this attribute as a secondary-info… Not to mention that some triggers may be not of a “state” platform and we’ll need another code to define “last-changed”.

4

I understand your point. But I fear that there’s no other possibility currently. The template binary atches that what you give it, in the example above it is the state of the input boolean. :man_shrugging:

5

And how this fact explains why “last-changed” is reset on HA startup?
Assume, the input_boolean was changed on 20:30, then on 21:00 HA was restarted, now it 21:10 - then last-chaged must be 20:30, not “10 minutes ago”.