Automation keeps repeating

Hi. I have two automations set up as temperature alarms according to below. One is triggered above 25 degrees, and the second one is returning to normal (below 25 degrees). The problem is that the second automation keeps repeating every 20-30 minutes or so after being triggered once (i.e. being below 25 degrees). Is there any way to stop this?

I want to avoid adding a delay since that would stop the alarm from triggering more than once should the temperature actually fluctuate between >25 - <25 within the time of delay.

- id: '1647165519569'
  alias: Low temp
  description: ''
  trigger:
  - platform: numeric_state
    entity_id: sensor.test_2
    for:
      hours: 0
      minutes: 0
      seconds: 5
    below: '25'
  condition: []
  action:
  - service: notify.gmail
    data_template:
      title: Temperature to normal in:" {{ trigger.to_state.attributes.friendly_name
        }} "
      message: Temperature of {{ trigger.to_state.attributes.friendly_name }} restored
        to normal. Current temperature is {{ trigger.to_state.state }} {{ 'Ā°C' }}
  - service: notify.group1
    data_template:
      title: Temperature to normal in:" {{ trigger.to_state.attributes.friendly_name
        }} "
      message: Temperature of {{ trigger.to_state.attributes.friendly_name }} restored
        to normal. Current temperature is {{ trigger.to_state.state }} {{ 'Ā°C' }}
  mode: single

Thanks. However, the temperature stays well below the threshold but still keeps sending me alarms. The way you describe it is how thought it works as well as how I want it to work. Any ideas of what could be causing it?

If itā€™s of any help, currently it sends exactly with 30 min intervals.

Remove the quotes. Numeric State trigger works in numbers, not strings.

Tried removing the quotes just in case to no avail. Checked the trigger logs and temp graphs and the threshold hasnā€™t been passed once, itā€™s stayed constantly below.

Yes, I went into automationā€“>debugā€“> step details & traces.

Here is step:

Executed: 15 March 2022, 18:14:38
Result:
params:
  domain: notify
  service: gmail
  service_data:
    title: Temperature to normal in:" KYL-1 "
    message: Temperature of KYL-1 restored to normal. Current temperature is 22.1 Ā°C
  target: {}
running_script: false
limit: 10

The graph also doesnā€™t show any indication that the temperature passed 25.

Could you include trigger.from_state.state into the message? Maybe the sensor becomes ā€˜unavailableā€™ from time to time.

Executed: 15 March 2022, 19:15:28

  from_state:
    entity_id: sensor.test_2
    state: unavailable
    attributes:
      state_class: measurement
      unit_of_measurement: Ā°C
      device_class: temperature
      friendly_name: KYL-1
    last_changed: '2022-03-15T18:15:22.841951+00:00'
    last_updated: '2022-03-15T18:15:22.841951+00:00'
    context:
      id: 49f74bdde620ad7df392cd9d67876c86
      parent_id: null
      user_id: null
  to_state:
    entity_id: sensor.test_2
    state: '22.2'
    attributes:
      state_class: measurement
      unit_of_measurement: Ā°C
      device_class: temperature
      friendly_name: KYL-1
    last_changed: '2022-03-15T18:15:23.001671+00:00'
    last_updated: '2022-03-15T18:15:23.001671+00:00'
    context:
      id: 146cc99959ce0c329d98b45ba22827a0
      parent_id: null
      user_id: null

It would appear in ā€œfromā€ that the sensor indeed becomes unavailable. But why would that happen momentarily every 30 minutes?

Itā€™s a Dallas temperature sensor connected to an ESP8266. The esp is slightly modded to be able to use an external antenna. I have set the update interval to 1 sec.

I transmit over the the public HiveMq mqtt broker. I donā€™t know if that may affect it but tomorrow Iā€™ll try local transmission without any mqtt in case the broker might have some data limit. The strange thing though is that yesterday the interval was 26 minutes. Do you think this could have anything to do with it?

I have the WiFi signal from the same esp but nothing else

Good idea. I will try to do a local setup either today or tomorrow, that will at least provide some indication if itā€™s client side or broker side. Perhaps even try another broker

IS there a workaround or fix for a sensor that does become unavailable, so it doesnā€™t reset the automation (and have it trigger again?)

Just an idea and donā€™t have the specific steps here but Iā€™ve solved a similar issue by removing the following from the action.

for:
      hours: 0
      minutes: 0
      seconds: 5
    below: '25'

This will have it trigger for all changes to the sensor.

Then to filter for the specific condition, in the action start with Option then in Option 1 as the condition select template with something like {{ trigger.from_state.state >= 25}}. Then add another condition with {{ trigger.to_state.state < 25}}. The add your existing actions as actions under option 1. Leave the default action empty.

You could also simply add the templates above as conditions for the actual automation and not do the whole option but I like to do this as it leaves the possibility to add other triggers or options.

This way itā€™s impossible for it to trigger unless it goes below 25.

2 Likes

Maybe add a condition to the automation that checks if trigger.from_state.state | float(default=25) > 25?

1 Like

What would be the appropriate condition type here? I canā€™t see anything called ā€œOptionā€. Or do I just write option directly it the automation script?

Iā€™m just learning this so Iā€™m combining visual editing with configuring the yaml itself.

EDIT: The ā€œforā€ paragraph is in my trigger. HA doesnā€™t seem to accept running automation without a trigger (which makes sense). How would I remove it and still have the automation trigger correctly?

Stick with the UI, it has advanced well. The resulting YaML would look like

...
  trigger:
  - platform: numeric_state
    entity_id: sensor.test_2
    for:
      hours: 0
      minutes: 0
      seconds: 5
    below: '25'
  condition: 
  - condition: template
    value_template: "{{ trigger.from_state.state | float(default=25) >= 25 }} "
...

The idea is, that is sensor.test_2 returns from ā€˜unavailableā€™ or ā€˜unknownā€™ to a value below threshold, automation executed is prevented when previous state was non-numeric or above threshold value.

1 Like

Hi.Thanks a lot. Tried it now but still getting the same error:

trigger:
  id: '0'
  idx: '0'
  platform: numeric_state
  entity_id: sensor.test_2
  below: 25
  above: null
  from_state:
    entity_id: sensor.test_2
    state: unavailable
    attributes:
      state_class: measurement
      unit_of_measurement: Ā°C
      device_class: temperature
    last_changed: '2022-03-18T12:24:57.187110+00:00'
    last_updated: '2022-03-18T12:24:57.187110+00:00'
    context:
      id: 93904d62d6f6a58adb08ef0f1acbf568
      parent_id: null
      user_id: null
  to_state:
    entity_id: sensor.test_2
    state: '22.9'
    attributes:
      state_class: measurement
      unit_of_measurement: Ā°C
      device_class: temperature
    last_changed: '2022-03-18T12:24:57.359618+00:00'
    last_updated: '2022-03-18T12:24:57.359618+00:00'
    context:
      id: 1fa9b069060f03293e68a5fb0f7dccf0
      parent_id: null
      user_id: null

The condition should match this, I donā€™t know why it is still executing the action part.

What exactly does the code you wrote do? Iā€™m mostly curious about the ā€œfloatā€ part.

It converts the outcome of trigger.to_state.state into a decimal number and - if that fails, because the state is not numeric - uses 25 as default. The float is then compared to the threshold value of 25, the expression must be true to pass.

Thanks.

After switching to local broadcast the problem went away. Therefore, I conclude that it is with all likelihood the MQTT broker that cuts off every now and again for some reason.