Assistance with state change in automation

[ylnest2018]

Hey, i think this might be simple but I cant get my head around it.

I have a device that when it reloads the integration, it renders a sensor’s state ‘unavailable’ then reports it back to its current state.

I am able to set my automation trigger to be only if the sensor changes from ‘0’ to ‘200’ but I want to put a condition, not to run if the sensor changes from ‘unavailable’ to ‘200’

I have also create a status helper so that the status only changes if the numbers change eg 0 > 200 = Refilled, 200 > 0 = Empty…maybe i should be using the status helper instead of the state?

Reason why I feel like I need to use the state instead of status, is so when I manually trigger the outlet on my external device, that it still can act as a trigger, just trying to prevent the false positives on the reload

evidence of the sensor change

[Didgeridrew]

The State trigger is very literal. If you set it with to: 200 and from: 0 it will only trigger when the value changes directly from “0” to “200” without any intermediary steps… a change from “unavailable” to “200” will not trigger it.

[ylnest2018]

thanks for getting back to me so quickly. That park works for me, however is there a way I can make it so the first trigger is only from a state change? maybe ive asnwered my question while asking it, however when trying to use the attributes available I couldnt seem to get it to cooperate, see below:

[Didgeridrew]

Instead of dozens of screenshots, it is much easier for us to diagnose issues if you post the automation’s YAML configuration.

It looks like you may have specified an attribute Value… if you want to trigger off the actual state, leave the attribute field empty.

[ylnest2018]

alias: RODI - Refill ATO - Finished
description: ""
triggers:
  - type: turned_off
    device_id: acbd50af8b493cb409970c6cd1040d05
    entity_id: 0c6a2b9576e4c07f4c5d8014a5f115eb
    domain: switch
    trigger: device
  - trigger: state
    entity_id:
      - input_select.ato_level_state
    from: In-Use
    to: Refilled
conditions:
  - condition: device
    type: is_off
    device_id: acbd50af8b493cb409970c6cd1040d05
    entity_id: 833ea930720a4826ef808f466f2c8cec
    domain: switch
  - condition: numeric_state
    entity_id: sensor.sensor_tado_thermostat_outdoor_temperature
    below: 30
actions:
  - data: {}
    target:
      entity_id: switch.plug_ro_booster_pump_switch
    action: switch.turn_off
  - delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
  - data: {}
    target:
      entity_id: switch.sonoff_1000e5f654_1
    action: switch.turn_off
  - delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
  - data: {}
    target:
      entity_id: switch.sonoff_1000e5f654_2
    action: switch.turn_off
  - data: {}
    target:
      entity_id: switch.sonoff_1000e5f654_3
    action: switch.turn_off
  - metadata: {}
    data:
      message: ATO Refill - Completed
    action: notify.mobile_app_iphone
mode: restart

[tom_l]

I don’t see anything like to: 200 and from: 0 in that automation.

The state trigger has a not_from option.

[WallyR (Wally)]

First a little warning about using device ids instead of entity ids.

Why and how to avoid device_ids in automations and scripts

Background When you start writing automations, a device trigger seems the obvious choice. Everybody knows what a device is and it comes at the top of the UI dropdown list. [image] It works… but it is certainly not a “great way to start” because it is storing up problems for the future. Far better to use an entity, with state or numeric_state. Device_id problems The yaml will be longer and harder to follow, which may make maintenance difficult, especially a few months down the line when y…

Next you can see in the trigger section that you have from and to keys.
If you look at the state trigger in the automation trigger documentation for HA you will see that there is an option to use not_from and not_to also. There is also an example of using it with the unknown/unavailable states.

[ylnest2018]

ah sorry you’re right I used the state change for the time being because I want to test if the logic works on at least the next time it goes from unavailable to 200.

alias: STATUS - ATO Refilled
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.apex_ato_hi
    from: "0"
    to: "200"
    attribute: value
conditions:
  - condition: state
    entity_id: sensor.apex_ato_lo
    attribute: value
    state: "200"
actions:
  - action: input_select.select_option
    metadata: {}
    data:
      option: Refilled
    target:
      entity_id: input_select.ato_level_state
  - action: notify.mobile_app_iphone
    metadata: {}
    data:
      message: ATO Is Refilled
mode: single

[tom_l]

triggers:
  - trigger: state
    entity_id:
      - sensor.apex_ato_hi
    to: "200"
    not_from:
      - unavailable
      - unknown

[ylnest2018]

thanks, I have to admit I dont currently control my automations in YAML, would there be a good video someone could link to or a thread to learn more about harnessing YAML automations over the GUI? I currently use the GUI to avoid mis-typing anything

[ylnest2018]

further to this…if I edit in YAML and add the not_from…will that update in the GUI view or it doesnt work like that?

[ylnest2018]

I assume this is a correct use of your suggestion?

alias: RODI - Refill ATO - Finished
description: ""
triggers:
  - trigger: state
    entity_id:
      - switch.apex_ro_make_ro
    from: "on"
    to: "off"
    not_from:
      - unavailable
      - unknown
  - trigger: state
    entity_id:
      - input_select.ato_level_state
    from: In-Use
    to: Refilled

[tom_l]

No. If you are specifying from you don’t need not_from.

[ylnest2018]

ok, i understand now. lastly, would you say its best practice to do one way or the other? or just specific to the task?

[tom_l]

If you know the state(s) you want to trigger from use that/them.