Announcement - Changes coming to Cron jobs

Hello SmartThings Community!

I’d like to make you aware of a change coming to our scheduler. As it stands today we are not strictly enforcing any limits on how short a cron schedule can run in a SmartApp. We also provide a tip in our documentation that it is not recommended to schedule anything under 60 seconds because a schedule like that can become unreliable.

As some of you may, or may not know, we are in the process of building and releasing a new scheduler. While we build the new scheduler we are looking for ways to improve and maintain the current scheduler and any future schedulers we release.

To that end, we will start enforcing a limit on cron schedules. Starting Monday, March 14, 2016 we will not allow cron schedules which run more often than 1 minute intervals. While we don’t anticipate this change having wide impact, we wanted to announce the change so you can adjust your development habits and current SmartApps/Device Type Handlers accordingly.


What will happen if a schedule in my SmartApp/DeviceType hits this limit?

We will do some magic on our end and your app will be automatically rescheduled at a one minute interval.

See the table below for examples:

Here are some additional examples of cron jobs that will be re-written:

  • ‘1/5 * * * * ?’
  • ‘* * * * * ?’
  • ‘* * * * MAR,JUN,SEP,DEC ?’
  • '* 0/15 * * * ?’

Will I see any errors in the logs?

No, since the cron expression won’t inherently break, and we only re-write it to run in at least a one minute interval, we will not display logs.

What will happen to my current Cron Jobs?

They will remain untouched until the schedule is updated. If your cron expression is set to run more often than once per minute it will be re-written on the backend to run at a 1 minute interval when the schedule is updated or a new SmartApp is installed.


We appreciate your understanding as we evaluate and find ways to improve our scheduler consistency.

10 Likes

Super appreciate the heads-up advance notice, Tim! This really helps to ensure we have time to review our code and determine if there is any impact and time to develop and test revisions as needed. Thanks! :smiley:

5 Likes

Good news is, nothing is inherently breaking. Even if your Cron is caught within this change it will just re-write itself on the backend. :slightly_smiling:

1 Like

Sure, but … silent “rewrites” of schedules would be very disconcerting during debugging.

IMHO: I don’t think the above choice is the wisest. If you’re changing code on the fly (even just a small change in the job execution frequency), I think it benefits both the developer and SmartThings to notate Live Logging so that the developer is fully aware of what is happening under the covers.

3 Likes

And just for clarity, this only impacts periodic polling, right? It will not impact one-off runIn commands I hope.

To be clear, I understand that it is not allowed to use runIn to circumvent the timings above. The usecase I am looking at is when changing the setpoint on a thermostat using the arrows in a multiAttributeTile it is very common to hit the arrow more than one time. Using the runIn it is easy to introduce a delay to capture multiple presses and allow for sending a single API call back to the cloud provider of the thermostat.

1 Like

Yep, this effects Cron, nothing else.

3 Likes

So what does this mean to us copy-and-paste-only “developers”? Will I still be able to set a delay in Rule Machine for <1 minute?

Depends how Bruce wrote it. I doubt he used a Cron expression though.

1 Like

Tagging Bruce @bravenel

Rule Machine does not use Cron.

However, RM does allow for times shorter than 60 seconds, as does ST. The admonition from ST is not to create repeating jobs with times of less than 60 seconds. Hence, the mod to Cron to disallow that.

It is surely possible with RM to create loops and whatnot that break this rule. I have always said that this is a bad idea, and practice proves that such a thing will likely fail. None of the timing elements in Rule Machine directly support doing this, but it is possible nevertheless.

4 Likes

Tim,

How would one schedule something at a random hour between 10am and 6pm everyday?

schedule(“0 0 10-18 * * ?”, handler)

This would mean every hour between 10 and 6pm right? How would one specify random in ST’s cron?

EDIT: This is one way but wondering if there is an easier way

Integer randomHour = (new Random()).nextInt(18-10) + 10
schedule("0 0 " + randomHour + " * * ?", handler) // Once a day at a random time between 10am and 6pm

That’s the way you will need to do it.

2 Likes

Tim for the Day of Week, the default is ? which I assume means all days of the week from Mon-Sun.
Does it accept numerical values? If so what’s the range, 0-6 or 1-7 and what would 0 or 1 correspond to respectively? I’m trying to pick a random day of the week.

1 Like

If this is based off of Linux cron both 0 & 7 are valid and both correspond to Sunday.

1 Like

True, I asked because it doesn’t seem to be accepting 0 or any number. The documentation is missing this information @Jim

Edit: Another caveot to days of the week is that they only work if month is not set. If you also populate year with anything but * or ? the days of the week are ignored.

None of these work, they all throw errors:

schedule(“0 0 " + randomHour + " * * MON”, handler)
schedule(“0 0 " + randomHour + " * * Mon”, handler)
schedule(“0 0 " + randomHour + " * * 0”, handler)

Documentation above shows a ? at the end of the statement. Normally that is the command. Not sure if that is what that is saying.

Isn’t that day of week which I want to specify in my examples above

You are correct. Not used to the ? syntax. Apparently that means start time.