Automation triggers at wrong times/randomly

Configuration
1

I’m running 7.1 on Raspberry 3A+. Fairly fresh installation with only a few entities so far.

My plan was to raise the window shutters when my phone alarm goes off. The shutters are controlled via a separate bridge, but it worked ok doing it manually (i.e. pressing a button in HA). I tried to include my phone alarm as well, but that is causing issues where the shutters would just randomly raise in the middle of the night.

For setting the alarm, I’m using the Android app and I’ve enabled the “next_alarm” sensor. When I was testing it out, I would set the alarm a few minutes in advance and it would always trigger ok, so that rules out any timezone differences. I then tied the alarm trigger to raising the shutters and tested it a few times by setting the alarm a few minutes ahead and it worked great. I then set the alarm for the next morning and went to bed.

The alarm was set for 7:00 (am), but the shutters went up at around 1:30 (am). I lowered them manually and went back to sleep. Then at around 6:45, the shutters went up yet again.

The trigger itself is fairly basic:

{{ states('sensor.date_time') == as_timestamp(states.sensor.mi_9t_next_alarm.state)| timestamp_custom('%Y-%m-%d, %H:%M') }}

Since setting the alarm a few minutes in advance is working fine, I’m guessing there’s something else going on. Maybe HA/bridge loses connection and it somehow raises the shutters when it’s back? Or maybe the next_alarm gets momentarily set to a wrong value and it triggers the blueprint.

I’ve tried checking the log, but all I see is the time when the shutters were raised during the night. I can’t find what caused the trigger to go off.

Any help is much appreciated, thank you!

Edit: Here’s the complete automation as well if it helps:

alias: Mi9 Alarm Raises Shutters
description: ''
trigger:
  - platform: template
    value_template: >-
      {{ states('sensor.date_time') ==
      as_timestamp(states.sensor.mi_9t_next_alarm.state)|
      timestamp_custom('%Y-%m-%d, %H:%M') }}
action:
  - service: cover.open_cover
    target:
      entity_id: cover.rolo_spalnica
mode: single
2

“next alarm state” is not only set by your own alarms. A number of apps, including system ones, can set alarms on a droid device, even if you don’t notice them.

3

Excellent catch!

I went back to the app and played around some more. There were indeed different alarms set before my morning alarm. I’ve now enabled the “allow” list to only listen to the next_alarm from my clock app. Hopefully this solves it.

Thank you for your quick reply!

1 Like
4

going through the same now, I am looking at alarm entity history and I can see many triggers.
May I ask, how did you go about allowing only the clock app to be listened to?

5

managed to figure it out, there’s some documentation here
namely: multiple apps can set the sensor next-alarm value, in my case it was the calendar, it does so by using AlarmManager in Android.
Luckily the sensor has a package attribute, that says who did set the next alarm, you can easily figure out the package name by setting an alarm soon, going to Settings->Devices->[Select device/phone]->Sensors and click on Next Alarm it will show history, and attributes below, expand attributes to get the current package name - com.sec.android.app.clockpackage in my case. (make sure that the newly set alarm is reflected as it takes some time to poll new information).
then in my automation I simply stated that this condition:

condition: state
entity_id: sensor.[device_name]_next_alarm
attribute: Package
state: com.sec.android.app.clockpackage