SmartThing Automation to turn off lights at a time is not running

SmartApps & Automations
1

For the past year or so I have been having issues where my SmartThings Wifi hub does not run automations to turn off Zigbee and Zwave lights at a certain time in the day. I’ve called SmartThings support a number of times and they only advice I get is that I have to delete the automation and rebuild them from scratch. This is an issue as I may not be home when the automations fail to run so I don’t know that the lights are left on. Figured I would reach out to this support group to see if anyone else has any ideas or be lucky enough to find a developer who can investigate the issue and hopefully come up with a firm resolution that doesn’t require me to rebuild these automations everytime they fail.

Below is my setup:

HUB: SmartThings Wifi Hardware ID: 0024 Firmware Version: 000.047.00012
Lights: Various Zigbee and Zwave devices

Automations:
Turn on lights at Sunset: This automation always works
In this case lets track the Dining Room Lamp which is turned on by this automation

Turn off lights at midnight: This automation is currently not running
It should have turned off the dining room lamp at midnight

Below is the Event Log from SmartThings Advance for the light in question:
In the log you can see that the light did not turn off at midnight. I had to manually turn off the light in the SmartThings app.

In order to prevent this issue from happening I tried to setup a Home Assistance that mirrored my automations but executed 1 minute after the program SmartThings automation. Last night I took down that Home Assistant to see what would happen and sure enough the SmartThings automations did not run. This is happening on multiple lights and multiple automations.

Does anyone have any ideas as to what may be happening and how it can be corrected?

Screenshots will be posted in follow up posts.

2

Light on at sunset automation

image
image614×1330 87.3 KB

3

Lights off at midnight

image
image614×1330 75.5 KB

4

SmartThings Advanced Logs

image
image1756×758 149 KB

5

I’ve the same hub model as you, and I’ve faced this situation several times. My troubleshooting concluded that this happens if there is a power outage. For some reason this hub model loses the “time” stamp and unless you disable/enable the individual automations that have specific times as triggers they will never run again. What I did is to connect the hub to a ups power backup so the hub never loses power. It is odd tho that the sunset and sunrise based automations don’t stop working… Hope this helps

6

Do you notice any difference after waiting over 24 hours that the time-based routines start running at the correct time? I’ve seen some similar problems and am trying to prove the idea the hub might come up after a power outage before the internet is up and running–perhaps (and this is simply a guess!) the hub tries to get the time from the 'net, fails, and defaults to something. Time passes and, eventually, the hub re-syncs time and routines resume their correct operating times going forward. :thinking:

1 Like
7

I’ve tried that, but nothing happens even after 24 hrs or even 48 hrs. For me what fixes the problem is disabling and enabling again. As a hint I had most of my time based automations inside the “Smart lightning” Smartapp, that way I could enable and disable all together instead of individually. So everytime I had a power outage I simply “reset” those automations and that solved the problem. Having a ups for power backup solved the problem for me.

8

@SableBlack That power outage thing is resonating with me. All of my issues typically occur after a power outage and SmartThings never recovered regardless of how long I wait. I know I have tried to work this with Samsung and SmartThings Customer Support but they don’t seem interested in trying to fix that ever is wrong.

If SmartThings doesn’t fix this issue I may stick with my shadow Home Assistance automations which is running on a free cloud computer to provide the backup coverage should I lose power again.

I really wish someone at SmartThings too an interest in this issue and tried to implement a bug fix.

9

Mine are all simple time-based Routines: if Sunset, set a virtual switch called “Evening Mode” that another Routine uses to turn on a few lights; when away, turn off the Office Lamp at 10:32 PM; and so on. I am not using Smart lighting at this time…

1 Like
10

This is more like my case: time-based events are way off to start. But, they seem to “fix” themselves within a day or two (or three?) and usually are lighting automations that are in use when Location Mode = Away.

1 Like
11

I have a virtual device that does that periodically. I have times set in the Routine tab of the device so when the switch doesn’t come on, I simply toggle the on and off from enabled to disabled and back. Fixes it every time.

1 Like
12

@Barkis I went thru my log history and it looks like the time-based events never fixed themselves. Once they stop working they like that until I recreate the automation.

13

Will rebooting the hub make things go back to normal, without recreating the automation?

1 Like
14

I’m going to give that a try. I’ll induce a power failure and see rebooting will do anything

1 Like
15

I have the same experience (also with a Smartthings Wifi hub) and have come to the same conclusions, and recovery plan, as SableBlack; the similarity extends even to having my hub connected to a UPS.

It’s rare, but every now and then I’ll deliberately cut power to my hub, and then just as you’ve described, I find that some of my time-based automations (e.g., starting our old-school coffee maker) don’t work until I disable / enable the automations (which has become less convenient recently).

I’m hoping we’ll get at least one more firmware update to address this and, ideally, add the ability to use the hub-replace feature. As I’ve mentioned before, I’m okay with laying out the cash to replace my hub after six-plus years (even though, for the most part, it still works quite well, with the issue mentioned here as one of the few exceptions), but I don’t appreciate the lack of information from Samsung regarding what to expect in terms of continued support for these hubs.

1 Like
16

This is essentially the supposition I’m exploring. On many systems–linux, for sure, and many other embedded OSes–time is kept as “seconds until (event)” or “seconds after (event).” At the time an automation is updated, the hub’s OS presumably knows the correct time, i.e., it’s been long enough since boot time for a successful time query on the 'net.

However, should the hub come up before the internet is ready, fetching the time from the 'net will fail. The default in many systems is some known past time–in linux it is “seconds since epoch,” which is midnight on January 1, 1970. The date will be way, way off, but the time will be within 24 hours. Or, epoch could be some other time–perhaps the time of the first release of the product or some other known, arbitrary time–but still within the 24 hour window.

Logically, if the time initialization fails, it should “know” it failed and periodically attempt to get an update. I think SmartThings does something along these lines, as I’ve noticed within a day or two my automations are firing at the correct time again. But this supposes all timers are re-calculated when the time is updated or re-calculated each time an event happens and the timer is reset for the next event occurrence.

All of this assumes there is no battery backed up real-time clock (RTC chips are how your computer typically remembers the date/time between bootups–although it will get the current time shortly thereafter). I have no idea if the ST hub has an RTC chip equivalent not–keep in mind this discussion is pure speculation. :wink:

Background: on embedded products for which I’ve recently written code (Lua, C, and C++), there was no sense of time-of-day. Calculations for timers figured out how many seconds from the current time until the scheduled event and set that as the remaining “ticks” until the event fired. Once the timer(s) decremented to zero, the event happens.

So, it would be interesting to know the elapsed time between one event and the next to see if that was correct after said power failure. In other words, if turning on the light over the kitchen sink was to happen the correct number of minutes after turning on the table light on the office desk–even if the office desk lamp turned on in the middle of the night. :thinking:

1 Like
17

I apologize for the diversion, but Barkis’s post put a smile on my face because, unrelated to Smarrtings, I’ve been dealing with time epochs quite a bit recently for work while dealing data from a network of weather stations. When I pull data from the stations they’re in the Unix epoch (seconds from January 1, 1970, UTC), but I’m using the data to explain local weather events to students, so I want them in my time zone (ET), with daylight savings time factored in (EST / EDT, as appropriate). I suspect Barkis will be amused by the fact, however, that I like to make graphs in Igor Pro, which displays date and time information as seconds since January 1, 1904! (It took me a little while to get all of this working as intended…)

1 Like
18

I often had time based routines (using the native ST time condition) stop working as well. I switched all time based routines to use the virtual calendar device by Mariano_Colmenarejo and haven’t had a routine fail since.

2 Likes
19

So I’ve induced a Power Outage by unplugging the hub and let all the automations sit a steady state for several days. The time based automation never ran after the simulated power failure.

Bottom line is once my hub loses power or the time based automations fail to run they never come back until I recreate the automation.