Template sensor deprecated entity_id

Configuration
1

Hi, I have template sensors that used entity_id so that they would NOT update with every state change from the value_template, like this:

sensor:
  - platform: template
    sensors:
      p1_energy_low:
        friendly_name: P1 Energy Low
        entity_id: [] # empty; so never automatically updated
        value_template: "{{ states('sensor.energy_consumption_tarif_1') }}"
        unit_of_measurement: kWh

With the template entity_id feature it was possible to have an automation trigger an update for this sensor whenever I want, but unfortunately that doesn’t work anymore now.

Now that entity_id is deprecated in 0.115 I need a new way to have a sensor that only updates the sensor.energy_consumption_tarif_1 state at some interval, and NOT every time sensor.energy_consumption_tarif_1 changes.

Does anyone know a way to achieve this without the deprecated entity_id attribute?

2

You could use a python_script, or update an input_number, but it kinda depends what this sensor is actually for. If it’s just to show the lowest (as the name suggests) then a min_max sensor (or one of the other statistical sensors) would probably handle this without the requirement for any templates or automations.

3

Thanks, no it has nothing to do with min/max. I want to store sensor states in an influxdb, but I only need the states at specific intervals defined by myself, not every time the sensor in the value_template updates. You could argue that it doesn’t harm to have all state updates in the database, but I really don’t need all states, so I liked the fact that I could simply only store the states at the intervals defined by me.

So in general, the template sensor with entity_id allowed me to create a new sensor that only updates whenever I want, and that doesn’t seem to be possible anymore.

4

Do the exact same thing but with an input_text instead of a template sensor. And if you want a template sensor for graphing, change the template sensor to pull from the input_text.

- alias: Update Input Text
  trigger:
  - platform: time_pattern
    hours: /2
  action:
  - service: input_text.set_value
    data_template:
      entity_id: input_text.my_text
      value: "{{ states('sensor.energy_consumption_tarif_1') }}"

sensor:
  - platform: template
    sensors:
      p1_energy_low:
        friendly_name: P1 Energy Low
        value_template: "{{ states('input_text.my_text') | float }}"
        unit_of_measurement: kWh

As a side note, even if you left that last entity_id field empty, the entity_id was still pulled from your value_template and used as a listener prior to 0.115. So it didn’t even do what you thought it did.

Prior to 0.115, in order to make the template not have a listener and never update, you’d have to separate the word ‘states’ from an entity_id. Regex was used to sniff templates to find states(‘xxx.xxx’). So something like this would have worked the way you expected:

        value_template: >
         {% set e = 'sensor.energy_consumption_tarif_1' %}
         {{ states(e) }}
1 Like
5

thanks, yes that sounds like I can do the same as before!

about your side note: it may be that prior to 0.115 the template sensor didn’t do what I thought it did, but it certainly worked the way I wanted it to and expected to, my example wasn’t theoretical, it really worked :slight_smile: : it only updated its state every 5 minutes, triggered by my automation’s homeassistant.update_entity, so sensor.p1_energy_low in my influxdb only has values every 5 minutes prior to 0.115. Now that entity_id: [] doesn’t work anymore, I see values every 10 seconds, which is every time that sensor.energy_consumption_tarif_1 changes.

What I liked about the “old” template sensor was that you could create a sensor that had less often state updates than the sensor it reads from. For example, I can also imagine some day I want to create a sensor that only shows the outside temperature at 12 noon, so it can be stored in a database without the need for all the other states im not interested in. Now I guess I need an extra input for that, which (just for my case) is kind of a shame, but don’t read it as complaining, I’ll go with the flow! :slight_smile:

6

you can still do that with SQL sensor. Just a different way of doing it.

1 Like
7

I don’t see how, then the “original” sensor states would still have to be in a database already wouldn’t they? My whole point is to not store the original states in any database or recorder history in the first place.
But again, your suggestion to use the extra input_text works fine, so its a great workaround to for the loss of entity_id!
thanks

8

Well in this instance you’d store the opposite. Use the recorder to store all the old states, instead of using it to store the 1 you care about. You’d just trade one for the other. But yes, you’d need to store information you might not want to store.