Enabling/Disabling recorder for specific entities on trigger

Configuration
1

Hi,

I have a temperature probe for my pool installed in the piping outside the pool.
It produces meaningful data only when the pump is working (I shut down the pump during the night), otherwise, the water temperature in the pipes go down WAY faster than the rest of the pool.

When my pump is off (got a toggle automation on my pump plug) I want to stop recording the temperature data.

I asked google, the AI gave me “a solution” that seems based on an older version of the recorder actions ? in any case it doesn’t matcgh the UI of the latest HA versions.

So, I found the Recoder ‘Disable’ action, no option in UI to specify entities … but there is some extra objects in YAML ?

I tried this (nothing is disabled) :

action: recorder.disable
metadata: {}
data: {sensor.pool_temp_in_temperature}

Google suggested to call the ‘recorder.disable_entity’ service.
If I select the “Perform action, Previously known as call service” action and input it in the search field, it doesn’t exist.

Any input on the matter ?

2

Actions for the recorder integration are listed here:

and any AI hallucinations aren’t supported.

If you don’t trust the docs to be complete, use the source:

3

I would suggest that you:

  1. Have the recorder exclude ALL data from that sensor (even mark it as still enabled, but hidden)
  2. It wasn’t too long ago that template sensors could have triggers. I would create a template sensor (text) based upon the sensor value in #1, that will only show a change if the pump is running (it could even have a state of “Pump Turned On” and “Pump Turned Off” when the pump turns on or off, and when the pump is turned on, as soon as the temperature readings come through, this template sensor would instead show the temperature.
  3. Then in your automation triggers, scripts, all your logic - just use that template sensor value instead.

If you need to have the value of the template sensor survive HA restarts (it will be unknown otherwise until it is first changed), include in that logic for the template sensor to instead write to an input_helper (text) whenever the value changes, and in all of your logic in #3, just utilize the input_helper value instead and do not utilize the other two sensors at all.

That’s the way I would do it - it’s a little convoluted but you would then have total control -

Here is a syntax example for a template sensor with a trigger for your configuration.yaml file. It shows, when the state of a switch changes, if it is off (if it is on it returns “N/A”, I really don’t care what the value is) how it was last turned off (physically, by a dashboard UI, or by an audomation). It has never actually shown “unkown”.

template:
#
# Bedroom 3 Light (for accessing these and with the last_changed value):
# {{ states('sensor.bedroom_3_light_off_context') }}
# {{ states.sensor['bedroom_3_light_off_context'].last_changed }} - to see WHEN it was done
#
  - trigger:
      - platform: state
        entity_id: switch.bedroom_3_outlet_shelly_1_switch
    sensor:
      - name: "Bedroom 3 Light Off Context"
        state: >
          {% set c_id = trigger.to_state.context.id %}
          {% set c_parent = trigger.to_state.context.parent_id %}
          {% set c_user = trigger.to_state.context.user_id %}
          {% if states('switch.bedroom_3_outlet_shelly_1_switch') == 'on' %}
            n/a
          {% elif c_id != none and c_parent == none and c_user == none %}
            physical
          {% elif c_id != none and c_parent == none and c_user != none %}
            dashboard_ui
          {% elif c_id != none and c_parent != none and c_user == none %}
            automation
          {% else %}
            unknown
          {% endif %}
        unique_id: bedroom_3_light_off_context

(PS/FYI The above was for when I have a scenario where if someone turns off a light and then leaves the room, the motion sensor would then turn the lights on because it detects motion - while they are walking out of the room! My workaround is to include in my automation condition to not turn on the light from motion being detected if the switch is off and was last turned off physically within the last 5 minutes.)

1 Like
4

I figured it was hallucinating thanks, but going from the source … I am sadly not versed enough in programming to make educated sense of the source :confused:

5

That’s seems like a good start, I’ll have to read your explanations a few times and figure out some of the concepts you gave :

  1. Have the recorder exclude ALL data from that sensor (even mark it as still enabled, but hidden)

  2. Create a template sensor (text) based upon the sensor value in #1, that will only show a change if the pump is running

Use of the input helper : I have done one already as a boolean based on time. I think I’ll manage this part, I don’t quite get the necessity to do so tho, as I don’t have experience with templates.

How to a take the template sensor and keed history for it ? (Will the recorder grab it by default ?

6

YOU CAN DO THIS!

You don’t need any of that logic I was showing, just use the same syntax to create your template sensor. For example the status of this sensor returns the text “this is the state”:

template:
  - trigger:
      - platform: state
        entity_id: <you put your sensor here that is hidden>
        sensor:
           - name: "Whatever you want to call this sensor"
             state: >
                "this is the state"

The recorder keeps the history oif everything by default. You can tell the recorder to exclude things. This is what I have for that setting:

#
# Changes to the default logging parameters:
#
recorder:
# remove this auto_purge line when 2024.8.X comes out as it resolves a bug
#  auto_purge: false

#
# We leave auto-purge on (which is the default if the
# setting is not specified) - which weirdly takes place
# every daty at 04:12 local time - since we don't care 
# how often it is purged but rather how much data is
# kept -  
# auto_purge: false
# purge_keep_days default is 10 if setting is missing
  purge_keep_days: 30
#
# If not specified, the commit_interval is defaulted to 1
# (1 second) - I have decided to cut in half the number of
# commits made to the database by just changing this to 2
# (hopefuly this will help prolong the life of the ssd)
  commit_interval: 2
#
# These command_line entities are called pretty often and 
# are just using up too much log spece - which disrupts from
# my being able to easily anallyze the logs on the fly - and 
# not worth the effort to save for any reason (unless I want
# to debug later in which case can easily be done by just 
# commenting out one or more of the below lines):
  exclude:
    entities:
#      - SENSOR.HASSIO_DNS_ERROR_COUNT_IN_LAST_10_MINUTES
# Add the other hidden input_text sensors
      - sensor.weewx_last_array_data_formatted
      - sensor.WEEWX_LAST_SENT_TO_AWEKAS
      - sensor.WEEWX_LAST_SENT_TO_WUNDERGROUND_PWS
      - sensor.WEEWX_LAST_SENT_TO_OWM
      - sensor.WEEWX_LAST_SENT_TO_METEOSERVICES
      - sensor.WEEWX_LAST_SENT_TO_PWSWEATHER
      - sensor.WEEWX_LAST_SENT_TO_WINDY
      - sensor.WEEWX_LAST_SENT_TO_WINDGURU
      - sensor.WEEWX_LAST_SENT_TO_WOW
      - sensor.WEEWX_LAST_SENT_TO_CWOP
      - sensor.WEEWX_LAST_SENT_TO_WEATHER365
      - sensor.WEEWX_LAST_SENT_TO_WEATHERCLOUD
#      - sensor.WEEWX_LAST_REST_CALL_FAILURE
      - sensor.SYSLOG1_ERRORS
      - sensor.CONSOLE_LAST_SENT_TO_WEATHERUNDERGROUND
      - sensor.CONSOLE_LAST_SENT_TO_WEATHERCLOUD
      - sensor.CONSOLE_LAST_SENT_TO_AMBIENTWEATHER
# ...and the uptime sensor counters shouldn't be logged....
      - sensor.rpi_uptime
# ...and we don't need to care about past ink levels...
      - sensor.epson_wf_3730_series_black_ink
      - sensor.epson_wf_3730_series_cyan_ink
      - sensor.epson_wf_3730_series_magenta_ink
      - sensor.epson_wf_3730_series_yellow_ink

Hope that heolps, report back here how it goes!

7

I see often a lot of YAML config code in documentation and examples like you do, but I’m not quite sure where to input this.

I am in my helpers page, I click “create Helper” > Template

I have a few choices, alarm, binary sensor, button, image, number, select, sensor, switch. (No Text)

The sensor one make sense.

I must define

Name : pool_in_temp_on
State template : TBD

Unit of measurement : Null (if I put something, I get an error “Sensor None has device class ‘temperature’, state class ‘measurement’ unit ‘°C’ and suggested precision ‘None’ thus indicating it has a numeric value; however, it has the non-numeric value: ‘’ (<class ‘str’>)”

Device class : Temperature
State Class : Measurement
Device : Pool_Temp_In

Now, all that’s left is to define the state template, wich I’m not sure what it means, but should represent my conditions / filter ?

Edit : Found the piece of doc closest to my goal ?
Template - Home Assistant

template:
  - triggers:
      trigger: state
      entity_id: sensor.outside_temperature
    conditions:
      - condition: template
        value_template: "{{ is_number(states('sensor.outside_temperature')) }}"
    sensor:
      - name: Outside Temperature last known value
        state: "{{ states('sensor.outside_temperature') }}"

Edit 2 : Got a value in preview

Just put this in the State template

{{
states('sensor.pool_temp_in_temperature')
}}

Now I could select the unit of measurement then the preview displayed the falue, now, I only need to display if light.filtreur_piscine_on_off = on …

I’ll report back as soon as I got something !

8

OK, i got the condiftion working.

{% if is_state('light.filtreur_piscine_on_off', 'on') %}
{{ states('sensor.pool_temp_in_temperature') }}
{% endif %}

Outputs the value because the “light” is now on.

If I switch it to off, to test the “false” condition, I get this error :

Sensor None has device class 'temperature', state class 'measurement' unit '°C' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: '' (<class 'str'>)

What could i do ? Or can I just ignore that ?

Edit : It can be ignored, the value wil be “unknown” if nothing is sent.

Now, to see if it behaves as wanted :slight_smile:

9

Please format your code for the forum using the </> button.

Nonsense. Just look at lines 32 to 36 of the link — you can see the services (now “actions”) listed there, aligned to the docs and excluding the ones vomited it by AI.

11

You can add an “elseif” that would instead just return -1 or -9999 ?

12

image
image1803×751 75.7 KB

13

And how would I know these represents what you are talking about ?

All I see here are … Variable definitions ? Nothing that tells me “These are the services you can call in your actions” …

As I told : I am sadly not versed enough in programming to make educated sense of the source.

The code bits have been formated, thank you.

14

If it really doesn’t like nulls, I’ll add an “elseif”, but the point is to remove unreasonable dips in my graphs.

image
image1577×708 107 KB

15

You were asking how tro create an input_text so I was showing you

1 Like
16

No, in this case you don’t use the value from the template sensor, that is to be ignored by the recorder as well. I’d suggest you create an input_number helper and update that only when you want to - from within the template sensor - then drive the greaph off of the input_number value. But you still have a problem. Your graph shows all time, not just the times when the pool pump is running. What did you want to have in the graph during the time periods when the pump is not running? LOL

17

The ApexCharts-Card has options to handle null data points, I could keep it blank, or display the last know value.

1 Like
18

The “correct” way to deal with this in the sensor is to use an availability template. At the moment, that is only available in YAML config, not through the UI.

template:
  - sensor:
      - name: Pool temp when light on
        state: "{{ states('sensor.pool_temp_in_temperature') }}"
        availability: "{{ is_state('light.filtreur_piscine_on_off', 'on') }}" 
        device_class: temperature
        state_class: measurement
        unit_of_measurement: "°C"

That will then show the temperature when the light is on, and be unavailable (without generating that error) when the light is off.

2 Likes