How do I trigger on a Rising &/or Falling edge of a numeric sensor?

I have an automation that triggers successfully when the sensor reads above the set value. However, due to reasons that I am yet to understand, it is not uncommon for the sensor to trigger as a result of change to/from an “unknown” or “unavailable” state.

And this is my current YAML:

alias: "Cost (today) Day Rate Switch "
description: Record the kWh used, when I switch to "Day" Rate
trigger:
  - platform: numeric_state
    entity_id:
      - sensor.smart_meter_electricity_import_unit_rate
    above: 0.2
  - type: turned_off
    platform: device
    device_id: f07f7d6a22ff5cfcbd1df6ebfa945390
    entity_id: 4e7a126f13b61404be3dd755177d5986
    domain: binary_sensor
    enabled: false
condition: []
action:
  - service: input_number.set_value
    target:
      entity_id: input_number.kwh_at_day_rate_start
    data:
      value: "{{ states('sensor.smart_meter_electricity_import') }}"
mode: single

And if this can be done without having to create a Trend or Derivative sensor, so much the better.
Regards, Martin

Check the Traces for your automation, if the “from” state for your false triggers is actually “unknown” or “unavailable”, then use conditional logic to avoid executing the actions when that happens:

condition:
  - condition: template
    value_template: "{{ trigger.from_state.state not in ['unknown', 'unavailable'] }}"

Replace the condition block thus:

condition:
  - "{{ trigger.from_state.state not in ('unknown', 'unavailable') }}"
  - "{{ trigger.to_state.state not in ('unknown', 'unavailable') }}"

Edit: ninja’d by Drew, but mine includes to_state also.

Another option would be to set up a template sensor that mirrors the rate sensor but ignores non-numeric updates.

Apologies for the time to acknowledge. But catching random events is not easy.
Now, I think, I’m still getting triggers (which I would rather not) but at least the Action is not executing.
Can you point me to the description of these “trigger.xxxx” commands. But if such does not exist yet, can you confirm that the strings within the parentheses () are a list? And the string can be any valid value from that sensor? i.e. “1234.56”.
Regards, M.

Strictly it’s a tuple. A list would be ['like', 'this'] and would behave the same way in this case. The differences are subtle. Reference:

https://jinja.palletsprojects.com/en/latest/templates/#literals

Yes, noting (as you seem to understand) that states are always strings, so "42" not 42.

The problem with this document, is that it does not list the parameters?

So, if I was attempting to use
trigger.from_state.state (which is how it is shown)
for the first time, how would I know that there are an unlimited number (are there?) of parameter (‘str1’, ‘str2’, … ‘str_n’) permitted. Is there some other understanding that I need to gain that will open this set of command for me?
Regards, M.

It’s not a “command”, it’s the State Object of the thing that caused the trigger, in its “before” condition.

So trigger.from_state.state is the (string) state of the sensor before it changes and caused the trigger to fire; and trigger.to_state.state is the state of the sensor after it caused the trigger to fire.

In your case, trigger.to_state and states.sensor.smart_meter_electricity_import_unit_rate are the same thing when you look at them; the from_state is a temporary record of what is was beforehand.