Trigger-based template sensors problem

[hakspiel]

Hi there,

i use a “Trigger-based template sensor” to store once a day (after sundown) my daily Photovoltaic yield.
As it is, it is working, i receive daily values, but with following problems:

• the last value in my variable “History_PV_Daily_Energy” is not accessible after reboot
  • Value is “Unknown” after reboot
• when i add the variable to a history graph, i see it as a “bar graph” instead of a xy-graph
  • I would prefer the xy-view, how can i force this view?

Can someone help me?

Template

template:
  - trigger:
    - platform: time
      at: "22:00:00"
    sensor:
      - name: "History_PV_Daily_Energy"
        state: "{{ states('sensor.SMA_PV_Daily_Yield')|float  }}"

[septillion (Timo)]

Sensor values are indeed not stored over reboots. You could change it to an input_number with an automation.

And bars happens when HA does not recognizes the state as a value. So maybe the wrong decimal point?

[123 (Taras)]

@hakspiel

the last value in my variable “History_PV_Daily_Energy” is not accessible after reboot

Helpers are the only entities whose states are stored/restored. On startup, all others acquire their states from their associated integration or, in the case of Template entities, by evaluating their templates. For Trigger-based Template entities, their templates are evaluated only when triggered. Knowing that, it’s expected that your Trigger-based Template Sensor has no state value (unknown) on startup.

@hakspiel

see it as a “bar graph” instead of a xy-graph

You must add a unit_of_measurement option such as:

  unit_of_measurement: kW

I used “kW” in the example but you should use whatever units that are appropriate for ‘History_PV_Daily_Energy’.

[hakspiel]

Thanks for the fast answers,
@123
i will try the unit of measurement hint, thanks for that.

Is there any possibility to tell Hass to use the last known value, as long there is no update available?
I do something similar via MQTT, and there the daily value stays alive.

@septillion
You are right, there is something wrong with the decimal separation.

The code should extract at 22:00 o’clock the value from the variable “SMA_PV_Daily_Yield”.
as you see in the picture, the value is dispalyed with the correct decimal separator (for germany).
But the value in “History_PV_Daily_Energy” is with a wrong decimal separator.

The code is not that complicated, and it should also be converted to a float, so what can i do?

[123 (Taras)]

@hakspiel

Is there any possibility to tell Hass to use the last known value, as long there is no update available?

How do you propose to do that given that a Trigger-based Template Sensor acquires its value only when it is triggered?

If you added another trigger like this:

  - trigger:
    - platform: time
      at: "22:00:00"
    - platform: homeassistant
      event: start

Now it will evaluate its template at startup and report a value. However, that wouldn’t work for your application because you don’t want “History_PV_Daily_Energy” computed whenever Home Assistant restarts.

I do something similar via MQTT, and there the daily value stays alive.

No, that’s not even remotely similar. On startup, an MQTT Sensor acquires its value from its state_topic. If the last value was not stored by the MQTT Broker then there will be no value available and the sensor will report unknown. If the last value was published as a retained message then it is stored on the Broker and will be available to Home Assistant on startup.

The important point here is that Home Assistant isn’t storing anything in either case. On startup, it simply reconnects to the Broker, re-subscribes to certain topics and acquires their payloads if they exist. Storing the last payload value is handled entirely by the MQTT Broker (and is a unique feature to MQTT, not Home Assistant).

[hakspiel]

Understood,

I have to create an automation that sends the value once a day via MQTT to the broker with Retain flag.

And then create a new sensor that reads the value from MQTT. Also on startup.

When i update the value on startup, i will have another value, because the yield is growing ecery hour with sunlight. And the yesterdays value is gone.

[septillion (Timo)]

Although possible, why the hard workaround? What was wrong with a helper (aka, input_number) that is designed for the task?

[123 (Taras)]

@hakspiel

create an automation that sends the value once a day via MQTT to the broker with Retain flag.

Yes.

create a new sensor that reads the value from MQTT. Also on startup.

Yes. On startup it will report the value published at 22:00.

When i update the value on startup, i will have another value, because the yield is growing ecery hour with sunlight. And the yesterdays value is gone.

This part I don’t understand. Why are you “updating the value on startup” when I thought you wanted the sensor to only display the last value published at 22:00?

[hakspiel]

The last was related to the idea to add a trigger that updates the value on startup.
Bit what i need is the value from 22:00. otherwise it is gone.

@septillion
I think i did not understand your idea with the input_number

[Troon]

@hakspiel

i did not understand your idea with the input_number

If the sensor is not retaining its value over a restart, you can use an input_number to store it instead, as these definitely do retain state. Here, as an example, is my automation for recording the peak power consumption of my electricity meter:

- alias: Energy - max power recorder

  description: Updates the maximum power recorder whenever prior threshold is exceeded

  id: 1fef4933-5115-4055-91d2-48d5d3a051b7

  trigger:
    - platform: template
      value_template: "{{ (states('sensor.power_meter_house')|float > states('input_number.max_power')|float) }}"

  action:
    - service: input_number.set_value
      data:
        entity_id: input_number.max_power
        value: "{{ states('sensor.power_meter_house')|float }}"

The input_number entity looks like this:

[123 (Taras)]

@hakspiel

what i need is the value from 22:00. otherwise it is gone.

Then all you need is:

• An automation to publish the value of sensor.SMA_PV_Daily_Yield to a topic at 22:00 (as a retained message).

• An MQTT Sensor, called sensor.history_sma_pv_daily_yield, that subscibes to the same topic.

Done!

Sample automation:

alias: example_1
trigger:
- platform: time
  at: '22:00:00'
action:
- service: mqtt.publish
  data:
    topic: 'sensor/history_sma_pv_daily_yield'
    retain: true
    payload_template: "{{ states('sensor.SMA_PV_Daily_Yield')|float  }}"

Sample MQTT Sensor:

#sensor:
  - platform: mqtt
    name: 'History SMA PV Daily Yield'
    state_topic: sensor/history_sma_pv_daily_yield
    unit_of_measurement: kWh
    device_class: energy

[Troon]

@123

(as a retained message)

@123

- service: mqtt.publish
  data:
    topic: 'sensor/history_sma_pv_daily_yield'
    payload_template: "{{ states('sensor.SMA_PV_Daily_Yield')|float  }}"

Need to add retain: true on that, I believe. Default is false [docs].

[123 (Taras)]

Thanks for bringing it to my attention. I fixed it and now it’s time for me to put my tablet aside and have breakfast before I forget to include other things I have suggested!

[hakspiel]

@Troon
@123

thanks for the help, i did it now with the MQTT solution.
However, i use Troon’s automation with input numer, to see the daily MAX Power of my Photovoltaic.

[123 (Taras)]

@hakspiel

i use Troon’s automation with input numer, to see the daily MAX Power of my Photovoltaic.

Whatever you prefer to use, it’s your choice.

• If you are not already using MQTT (although I believe you are) then it’s easier to store the value in an input_number.

• If you are already using MQTT, there are benefits to storing the value in an MQTT Sensor (such as the ability to assign it a device_class and unit_of_measurement for better presentation in the UI and history chart).

[Friedrieck]

Why not using Utility Meter - Home Assistant (home-assistant.io)?

[Mariusthvdb (Marius)]

@123

How do you propose to do that given that a Trigger-based Template Sensor acquires its value only when it is triggered?

sorry for the bump, but I have only just started with these trigger bases sensors.

Accepting the unknown at startup up to know, I thought id change the template somewhat to show a text indicating it wasnt yet triggered:

  - trigger:

      - platform: event
        event_type: hue_event
        event_data:
          id: auditorium_tap_switch_button
    sensor:
      - unique_id: auditorium_tap_switch_last_event
        name: Auditorium tap switch
        state: >
          {% if state_attr('sensor.auditorium_tap_switch','last_triggered') is not none %}
          {{trigger.event.data.subtype}}
          {% else %} Not yet tapped
          {% endif %}
        attributes:
          last_triggered: >
            {{trigger.event.time_fired}}

which works fine in the template editor, but that of course evaluates the template.

Since this is not time material, nor any specific system value depending on it I could probably trigger them on startup, but then the last_triggered wouldn’t be none any longer, hence rating another issue: not being tapped just yet, it would still be unknown ;-=)

Cant we somehow adapt the state template in a way to have it show the text at startup, and a correct value when tapped?

[123 (Taras)]

If you do this:

  - trigger:
      - platform: event
        event_type: hue_event
        event_data:
          id: auditorium_tap_switch_button
      - platform: event
        event_type: event_template_reloaded
      - platform: homeassistant
        event: start

the Trigger-based Template Sensor will be evaluated when:

1. Hue button event occurs
2. Template entities are reloaded
3. Home Assistant startup

However, adding the two extra triggers means the template can no longer assume the trigger variable contains information related to the Hue button event.

[Mariusthvdb (Marius)]

yes, thanks Taras, I’ve been running in circles with this. each time I think I can finally use a trigger based template sensor, these exceptions occur… don’t want the hassle of an intermediary helper and automation, so not much left than accepting the ugly ‘unknown’ in the front-end I guess.

If only … we were able to set a default value here too, the one place it would actually be useful