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.
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.
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?
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
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.
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?
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.
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.
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.