Trigger an automation when a numeric state changes

Configuration
1

Does anyone know how can I trigger an automation when the value of a sensor changes? It could change up or down, by a lot or by a little. There are no existing sensors to compare the current target SOC against.

The context is an automation that is currently triggered by me plugging my VW ID3 into my Zappi charger (which is to say, the ID3 reports it is connected and it is at Home). I use Intelligent Octopus Go, which controls the Zappi; you need to tell Octopus how much charge you need. I have this working so far: it unlocks the Zappi and tells Octopus how much charge I need (calculated from the target and current SOCs reported by the ID3). This is all I need 99% of the time, but sometimes I am planning a longer trip, in which case I need to charge my ID3 up to 100%. I would like my automation to trigger if I change the target SOC setting after I plugin, i.e. a second trigger of “the target SOC has changed” on this existing automation.

My current workaround is to change the target SOC before plugging into the charger and of course this is fine, but not as shiny and polished as it could be. I also suppose I could configure a “change target SOC” Helper and use that to trigger the automation - this is what I will do if there is no way to add the trigger to the existing automation.

Thanks for any help

Steve

2

A state trigger:

Or am I missing something? Show the YAML of your current automation if you need more.

1 Like
3

Troon

Oh! So I don’t have too specify the “above” or “below” setting and if I don’t then I get a trigger on any change.

Thanks for replying so quickly and sorry for being so dim!

Steve

4

Or rather not that but have a state change with no from or to.

5

You can’t specify them for a State Trigger even if you wanted to. Those two options are exclusive to a Numeric State Trigger.

Be advised that a State Trigger without from or to options will trigger for an entity’s state-changes and changes to the values of its attributes.

If you specify a to with no value, the State Trigger will trigger exclusively for the entity’s state-changes.

6

I don’t know in advance what the “To” value would be. I could potentially assume I am always changing from 80 if necessary to get this to work nicely.

The entity has no attributes as far as I can see. The entity state itself is changed manually and won’t change often; I’ll add a time period to the trigger to avoid triggering on any weird temporary changes.

7 
trigger:
  - platform: state
    entity_id:
    - sensor.my_sensor
    not_from:
    - unknown
    - unavailable
    not_to:
    - unknown
    - unavailable

This will trigger on numeric changes and will not trigger at startup or if the sensor is unknown or unavailable for other reasons

1 Like
8

Leave it blank (to simply constrain the State Trigger’s operation as previously described) or, better yet, do what stigvi suggested to ensure it only triggers for nominal state values and not non-nominal values like unavailable and unknown.

9

And if you use a numeric trigger, you can still test for unknown and unavailable to limit triggering at startup

trigger:
  - platform: numeric_state
    entity_id:
      - sensor.my_sensor
    below: 100
condition:
  - condition: template
    value_template: >-
      {{ trigger.from_state.state != 'unknown' and trigger.from_state.state != 'unavailable' }}
1 Like
10

Thanks for that. I hit this exact problem in the dead of last night. Oddly, the same variable is then used in a calculation and that worked fine except that as the car had been charging for a while the resulting “charge required” was lower than it was. The Octopus API behaves oddly if you change it mid-charge plan - my car ended up 75% charged rather than 80%.

I’ll add protection against unavailable. Is there anyway to test this other than just wait for next time?

Steve

11

Sensors from integrations are usually unavailable or unknown for a short time when you start Home Assistant. When HA is started, you can use the trace functionality in automations to go back in time and see what your automation did.