persistent trigger based sensors

[luka6000]

The problem

How to make trigger based sensors value persistent and survive restart? Trigger based sensors always have state unknown until next trigger.

This sensor defined below was not directly possible without trigger based sensors because it needs access to previous and current state to calculate the difference.

It's always an option to push event to mqtt and make sensor out of that but there should be other way, right?

What is version of Home Assistant Core has the issue?

core-2021.4.6

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

No response

Link to integration documentation on our website

https://www.home-assistant.io/integrations/template/#configuration-for-trigger-based-template-sensors

Example YAML snippet

template:
  - trigger:
      - platform: state
        entity_id: cover.living_room_shutters
    sensor:
      - name: "Living room shutters tilt"
        unique_id: living_room_shutters_tilt
        icon: mdi:math-integral
        state: >-
            {%set diff=(trigger.to_state.attributes.current_position - trigger.from_state.attributes.current_position) %}
            {%set curr=states("sensor.living_room_shutters_tilt")|int%}
            {%if curr > 0 %}
            {%else%}{%set curr=0%}
            {%endif%}
            {%if diff <= -3 %}{%set tgt=0%}
            {%elif diff >= -2 and diff <= 2%}{%set tgt=(curr + diff*30)%}
            {%elif diff >= 3 %}{%set tgt=90%}
            {%else%}{%set tgt=0%}
            {%endif%}
            {{ tgt|int }}
        unit_of_measurement: "°"

Anything in the logs that might be useful for us?

No response

Additional information

No response

[probot-home-assistant]

Hey there @PhracturedBlue, @tetienne, mind taking a look at this issue as its been labeled with an integration (template) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[tdejneka]

How to make trigger based sensors value persistent and survive restart?

Whether it's a Template Sensor or the recently introduced Trigger-based Template Sensor, its value is not "persistent" nor does it "survive a restart". In the case of Template Sensors, their template is always evaluated on startup (and is not stored/restored like Helpers).

To make a Trigger-based Template Sensor behave the same way, just add another trigger:

  - trigger:
      - platform: state
        entity_id: cover.living_room_shutters
      - platform: homeassistant
        event: start

Now it will also be evaluated on startup.

[luka6000]

Now it will also be evaluated on startup.

Ok, but what's the point? There is no data in that 'start' trigger. Look at the code - sensor information was extracted from the trigger, from changing the value of something. Start event has no interesting data in it.

Your solution is good only for time based trigger sensors. This is not the case.

[tdejneka]

You have a valid point; your template cannot be redesigned to avoid using the trigger variable, and simply use states() or state_attr(), because it compares the cover's trigger.from_state and trigger.to_state.

It would appear that a Trigger-based Template Sensor is not the right choice for your application.

One possible workaround is to convert your Trigger-based Template to an automation that writes its computed value to a Helper like an input_text or input_number. Helper states are stored/restored.

If a Helper isn't how you want the value to be presented, another possibility is to make the automation publish its computed value to an MQTT topic (as a retained message). Create an MQTT Sensor that subscribes to the topic. Now you have a sensor (that can have device_class, unit_of_measurement, etc) with a persistent value (because the value is stored by the MQTT broker) that is instantly restored on startup (i.e. the moment Home Assistant reconnects to the broker).

[luka6000]

It would appear that a Trigger-based Template Sensor is not the right choice for your application.

This conclusion is very wrong. Look at trigger based documentation:

Whenever the trigger fires, the template sensor will re-render and it will have access to the trigger data in the templates. This feature is a great way to create data based on webhook data

This is exactly my case: I need access to trigger data during sensor value update.
If my case was with webhook, my trigger based sensor would also lost it's value after restart.

I understand that triggered based sensors are exactly to not use those input helpers which can be manually altered and is very awkward solution.
Think of trigger data (like my sensor above) but also webhook or events (like custom events trigger with mobile app). Kill all those input helpers. Long live trigger based sensors! ;-)

[luka6000]

If a Helper isn't how you want the value to be presented, another possibility is to make the automation publish its computed value to an MQTT topic (as a retained message). Create an MQTT Sensor that subscribes to the topic. Now you have a sensor (that can have device_class, unit_of_measurement, etc) with a persistent value (because the value is stored by the MQTT broker) that is instantly restored on startup (i.e. the moment Home Assistant reconnects to the broker).

yes, I've already mentioned this solution at the top. I have such sensors based on events coming from mobile app. I've done it like that because there was no other way to quit input helpers. And since this is sensor data and not user input, I don't want to use helpers. But now we have trigger base sensors and I think this is great solution! Well, until you realize this sensor is very ephemeral. Is this a bug or what?

[tdejneka]

This conclusion is very wrong. Look at trigger based documentation:

I did and the excerpt you selected explains precisely how it currently works but doesn't refer to the added feature you want which is for the sensor's value to somehow "persist" in the absence of a trigger. The fact is, on startup, your example will have no value until it is triggered. The computed value will persist in Home Assistant's state machine until a restart (just like all other sensors).

Is this a bug or what?

It's not a bug. What you want is simply not the way it works (or was ever intended to).

What you want constitutes a Feature Request and would probably have to go through an Architectural review because it requests behavior that differs from all other sensors (no sensor values are stored by Home Assistant; on startup all are either retrieved from an integration or computed by templates).

[thomasgermain]

Following, since I have same kind of issue here, I want to trigger an sensor update once a day.
This is working well except:

• upon restart. The start event could do the trick, but I'm sure there are some use cases where people don't want their template entity state to be updated on start (maybe for daily consumption sensor ?). I think there could be an option where you indicate if you want your entity state persistent (upon restart).
  -- If yes, the state will have the last known value before restart and will update when trigger matches
  -- if no, then your entity will have "unknown" value, but you can still add start even to the trigger :)

• upon template entity reload (through the UI), my entities are losing their states until the next trigger happens. (I'm currently migrating from old template to new template style, so I'm reloading a lot right now). I have no idea here 😞, you might want to update it after the reload, but there won't be any trigger data then..

Honestly, it sounds quite hard to have something that would fit every use cases

EDIT:
for template entity reload, there is an event event_type event_template_reloaded

[droopanu]

EDIT:
for template entity reload, there is an event event_type event_template_reloaded

Did you manage to make it work for template_reload?
I tried this:

template:
  - trigger:
      - platform: homeassistant
        event: start          
      - platform: event
        event: event_template_reloaded  

And I get the following error:
ERROR (MainThread) [homeassistant.config] Invalid config for [template]: [event] is an invalid option for [template]. Check: template->event. (See ?, line ?).

[luka6000]

What you want constitutes a Feature Request and would probably have to go through an Architectural review because it requests behavior that differs from all other sensors (no sensor values are stored by Home Assistant; on startup all are either retrieved from an integration or computed by templates).

Was thinking about this lately again. Maybe the issue actually comes down to exactly this: getting startup value from something. So having this kind of attribute I could decide to get startup value from history (per SQL query?) or maybe mqtt topic? Recorder history looks quite good and should not require any architectural changes, right?

[tdejneka]

I deleted two of my posts because what I wrote was wrong and didn't want them to mislead anyone.

thomasgermain provided the correct solution. Simply add the following trigger to your Trigger-based Template Sensor.

      - platform: event
        event_type: event_template_reloaded  

It will cause the sensor to compute its state value when Template Entities have finished loading.

[luka6000]

It will cause the sensor to compute its state value when Template Entities have finished loading.

But there is no information in this event trigger. It doesn't even have state object

2021-05-15 21:07:59 ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'dict object' has no attribute 'to_state' when rendering '{%set diff=(trigger.to_state.attributes.current_position - trigger.from_state.attributes.current_position) %} {%set curr=states("sensor.living_room_shutters_tilt")|int%} {%if curr > 0 %} {%else%}{%set curr=0%} {%endif%} {%if diff <= -3 %}{%set tgt=0%} {%elif diff >= -2 and diff <= 2%}{%set tgt=(curr + diff*30)%} {%elif diff >= 3 %}{%set tgt=90%} {%else%}{%set tgt=-1%} {%endif%} {{ tgt|int }}'
2021-05-15 21:07:59 ERROR (MainThread) [homeassistant.components.template.sensor] Error rendering state template for sensor.living_room_shutters_tilt_raw: UndefinedError: 'dict object' has no attribute 'to_state'

[tdejneka]

You're right; in its current form, the Trigger-based Template Sensor is inappropriate for your application. You'll need to do use another method.

[luka6000]

There is a precedence for persistent sensors and that is utility meter
https://www.home-assistant.io/integrations/utility_meter

[tdejneka]

As mentioned previously, Issues are for bug reports, not Feature Requests. Discussing it here won't change the status quo. You may have noticed that since this Issue was opened, now 24 days ago, no one from the development team has been assigned to it or has commented.

[luka6000]

ok guys, @PhracturedBlue , @tetienne , looking at documentation
https://www.home-assistant.io/integrations/template/#storing-webhook-information
How do I "store information in template entities"? Is this correct that current implementation actually doesn't do any storing?

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[luka6000]

latest updates don't do any good with this. Still there is no way to recover template sensor last value after ha restart.

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.