Automation Not Triggering on Time

Configuration
1

I am bashing my head trying to figure out why this isn’t working. Here is my code from a few days ago, that recently quit working. It’s just an alarm clock automation, but getting it to trigger on time seems to be a real issue right now.

Most of the code in this package is based off of this thread.

The following state will evaluate to true in the template editor if I go change the value of sensors.time in the states.
{{ states.sensor.time.state == states.sensor.wakeup_alarm_start_time.state }}

However, the automations don’t get triggered. Looking through the log book, the Time state is updated at really random intervals.

Here is my current code. I’ve consolidated a lot of the time calculations into a couple of template sensors to make the comparison operation in the trigger value_template a bit quicker. However, again, changing the time doesn’t fire off the automation. Hell, even the minutes: '/1' automation isn’t going off every minute.

Can anyone help me figure out what is going on here?

2

Can you post your time sensor configuration? The interval time should be minutely depending on your config.

3

This is the only place that I have any sort of time sensor specified.

Is this what creates the sensor.time sensor? Or am I missing something. It’s the only time sensor I could find in the documentation. (However, there is a highly likely chance that I’ve missed something.)

The most troubling part is that the automations have worked flawlessly for months up until the past week or so.

4

Here is an example of the sporadic interval of the time sensor.

image

However, when you expand on the entity history, it shows that it’s been properly updating.

image
image1727×208 13.1 KB

5 
  trigger:
  - platform: time
    minutes: '/1'
    seconds: 0
  condition:
  - condition: template
    value_template: '{{ now().strftime("%H:%M") == states.sensor.wakeup_alarm_start_time.state
      }}'
6

Yeah, I just wasn’t sure if you were using internet time which has a slightly different interval. Anyways, On to your issue. Can you verify the state of states.sensor.wakeup_alarm_start_time.state and states.sensor.time.state? If they both have the “%H:%M” format, then I would look towards your condition.

Also, I would avoid using the ‘/1’ time trigger because it can bog down your system.

EDIT: What I mean when I say ‘look towards your condition’, I mean: Verify that the binary workday sensor is working as expected.

7

I setup the '/1' automation purely to test with. I’m trying to avoid using it for that exact reason.

My workday sensor appears to be working fine.

image
image772×184 15.4 KB

I’ve already had one odd altercation with the workday sensor.

8

Here’s a test you could perform live, Try making a template sensor with the same code that you’d use for the template trigger. See if it responds when you change the input datetime to match the current time. It should respond immediately. If that works, then it should also work for your triggers.

9

So, I’ve already tried something along those lines.

I have a couple of template sensors already.

Here’s a template test:

System Time: {{ now().strftime("%H:%M") }}
Current Time: {{ states.sensor.time.state }}
Wakeup Time: {{ states.sensor.wakeup_time.state }}
Offset: {{ states.input_number.wakeup_duration.state | int }}
Alarm Time: {{ states.sensor.wakeup_alarm_start_time.state }}
Logical Operation: {{ states.sensor.time.state == states.sensor.wakeup_alarm_start_time.state }}

And here it is in my instance.

image
image1065×280 35.6 KB

Now let’s go over to the states, and set sensor.time to 4:30
image
image1054×279 35.7 KB

Now the logical operation is true.
Something I also noticed was that the operation would evaluate false if the time were set to “4:30” without the leading zero. So, I double-checked my logbook, and the times are 00:00 formatted.
image
I’m out of ideas.

10

Ok, well this is clearly annoying so lets try something different:

try:

{% set c = strptime(states.sensor.time.state,'%H:%M') %}
{% set a = strptime(states.sensor.wakeup_alam_start_time.state,'%H:%M') %}
{{ c.hour + c.minute/60 == a.hour + a.minute/60 }}
11

Okay, now that’s getting weird. It almost looks like a localisation issue.

image
image856×300 27.3 KB

I’m in UTC-6, though. So, if it were going back to UTC, it would be 10:30. And just for safe measure, I checked the date on the system itself, and it’s got the correct time. (Mon Jun 11 14:32:16 CDT 2018 when I ran date.)

12

Well if you use the method I described, you’d have to treat your alarms as 24/hr time.

13

Which is fine. I keep all of my clocks in that format anyways. the 14.5 and 4.5 values are what threw me off. It looks like those values still came out right.

image
image851×300 27.1 KB

14

It’s confusing that even this automation isn’t bombarding me with notifications. It’s got a trigger for my alarm time and also '/1'.

https://github.com/Apocrathia/home-assistant-config/blob/master/packages/function_alarmclock.yaml#L99

15

Are you sure that the root of your problems is that automation? Have you checked your logs for errors. Not the log page, but the home assistant logs text file

16

I’m glad you reminded me of that. I’ve got Home Assistant feeding into Splunk with the Home Assistant Splunk App. I’m not entirely sure how useful the output will be, but it’s one more source of data for troubleshooting.

I’ve noticed a lot of ERROR (MainThread) [homeassistant.core] Error doing job: Task was destroyed but it is pending! errors in the log file. Any ideas?

17

The automations didn’t fire again, this morning. Here’s what was in my logs around that timeframe.

2018-06-12 04:04:54 ERROR (MainThread) [homeassistant.core] Error doing job: Task was destroyed but it is pending!
2018-06-12 04:18:09 ERROR (MainThread) [homeassistant.components.light.hue] Unable to reach bridge *redacted*
2018-06-12 04:56:09 ERROR (MainThread) [homeassistant.components.light.hue] Unable to reach bridge *redacted*
2018-06-12 05:00:21 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.weather_pws_temp_high_record_c is taking over 10 seconds
2018-06-12 05:00:21 ERROR (MainThread) [homeassistant.components.sensor.wunderground] Error fetching WUnderground data: TimeoutError()
2018-06-12 05:07:30 ERROR (Recorder) [homeassistant.core] Error doing job: Task was destroyed but it is pending!
18

Looks like this is an issue with hue? When was it supposed to fire? 4:30?

19

The Hue has been having issues for a while now. It just pops on and offline. Not sure what it’s deal is. I’ve got to do an RF scan in my house to see if there’s some sort of Zigbee/Wifi interference and if I need to change channels for stuff. Even if the Hue was offline, the automation still would have triggered, and my TV would have come on.
The automation was supposed to fire at 04:30, but there’s not even an error at that time. Which tells me that it didn’t get get triggered.

20

I think you should turn debugging on in the logs to see all logs. Set the alarm to a close time and see what events fire in the log. They may actually be on the ‘info’ log level to be honest, i don’t remember.