Hi,
I have upgraded my alarm system with esp32 and some relay boards.
The alarm respond to messages via MQTT in a topic (alarm/cmd) and send it’s state in another topic (alarm/state).
I have configured a binary sensor to check the alarm state.
When I put the alarm in “away” mode, but one or more window are opened, the alarm won’t turn on, in this case my wish is to send to my esp32 another payload via mqtt that my esp32 recognize and shortcircuitt another relay, to program my alarm, bypassing the perimeter.
I have programmed an automation that listen to the same topic that my esp32 listen too, and if after three seconds, when the state of the alarm is off, the automation will trigger the second command.
The problem is the delay time, I don’t know how to program the automation in this way.
I have tested the automation and works normally, but it’s send the second program immediately and the result is that my alarm is disinserted.
How can I check the binary sensor (binary_sensor.alarm_box_armed) only after three seconds after received the message (alarm/cmd - armed_away) ?
The yaml for the automation is:
alias: Deactivate the perimeter in case of one or more window are opened
description: ""
trigger:
- platform: mqtt
topic: alarm/cmd
payload: armed_away
condition:
- condition: and
conditions:
- condition: state
entity_id: binary_sensor.alarm_box_armed
state: "off"
for:
hours: 0
minutes: 0
seconds: 3
action:
- service: mqtt.publish
data:
topic: alarm/cmd
payload: armed_p2
- service: notify.notify
data:
message: Alarm perimeter deactivated
mode: single
Hi,
thanks for your response, but the proposed solution, does’t works for me.
When I wrote the ‘state = off’ in the wait_for_trigger action, I receive the following error:
“Message malformed: extra keys not allowed @data [‘state’]”
I modified the keyword ‘state’ with ‘to’ (ex: “to: ‘off’”), but the automation doesn’t work as expected.
I did some experiments:
``
wait_for_trigger:
platform: state
entity_id: binary_sensor.alarm_box_armed
from: ‘off’
to: ‘off’
for: “00:00:05”
``
In this case, when I send the message “alarm / cmd = armed_away”:
if a window is opened, the trigger does not fire → KO
if no window is open the alarm is correctly inserted → OK
Actually, this version is equivalent to not having the automation at all …
The second experiment uses timeout, instead of “for”:
``
action:
In this second example, when I send the message “alarm / cmd = armed_away”:
if a window is opened, the automation works as expected, wait for 5 seconds and send the second message: “alarm / cmd = armed_p2” which excludes the perimeter and activates the alarm only with internal sensors. → OK
if no window is opened, the alarm is totally activated (this is OK, but only for the first five seconds), but after 5 seconds, the second message is sent even if the state of the “binary_sensor.alarm_box_armed” is ‘on’. → KO
I need a way to stop the automation, if the value of “binary_sensor.alarm_box_armed” is “on” (checked with developer’s pages).
That’s due to my mistake. While transforming your State Condition into a State Trigger, I forgot to change the state option to a to option. I have corrected the example posted above.
That’s not a valid state-change. The State Trigger listens for state-changes and off to off isn’t a change of state.