Thoughts on starting/ending time restrictions in SmartApps

Developer Programs Writing SmartApps
1

Hey all,

There are a bunch of apps, both community submitted and native that have the notion of restricting the app to running only during certain times. In some cases, I feel like I’ve seen that both fields are optional, but I’m wondering if that makes sense.

For example, can you really have a starting time of say 5p.m. and no ending time? If so, well then technically it’s ALWAYS after 5p.m., maybe the next day, but it’s still technically after 5p.m. Same argument can be made for ending time.

If on the other hand you believe that you CAN have a start without an end (or vice versa), then you are implicitly saying that the missing start/end time is midnight, are you not? I could buy this argument, but I just wonder if it’s better to require neither or both.

On a related note, for these types of apps that are time restricted and/or have some other conditions e.g. mode restrictions, do you all think it’s better practice to run periodically (say once an hour), and each time just check all your conditions (mode, time of day, etc.) or to programmatically determine the next earliest run time for the app based on start time and any other conditions like day of week?

My feeling is that, while a little more complicated, the latter is a better approach because it’s less resource intensive. For example, why check once an hour for a condition that you KNOW will only be satisfied 4 hours a day? I’d say it’s better to schedule the app to run at the next earliest time and then check the mode and/or other conditions.

Just thought it’d be interesting to start a dialogue and see what everyone thought.

Justin

1 Like
3

Hey Bruce,

Thanks for the reply. I have seen some apps that do allow for one or the other as far as a starting and an ending. And I haven’t looked too deeply into their logic, but I THINK they are implicitly using midnight as the missing input. I hear what you’re saying and it sounds like you’re agreeing with my point about which is required, however I think you’re addressing the limitations on how we currently declare inputs as required or not.

What would be great is if we could declare the required attribute on a group of inputs. In that absence, you have to do what you suggest OR use multiple pages to set the required attribute for the ending time to true if they supplied a starting time on the previous page. Same outcome, I’m just trying to make the input validation a little stronger.

Regarding the Lights Turn On Motion, I agree with you in specific example. When the app runs, it runs based on motion and it’s most likely running for a shorter period of time than say when we’re in Day/Night mode. I disagree however that mode or day of week restrictions are the same as motion. You most likely can’t predict when a certain mode will be entered, but once it does enter that mode, you could then figure out when it should run based on time and/or day restrictions.

For example, let’s say I have an app that should only run in ‘Day’ mode, but only between the hours of 1300-1500, twice a week. One could detect the mode change, then schedule it to be run at 1300 the next day it’s allowed to run. Then when the app runs at that time (unless it’s been unscheduled by some other means), double check the mode and run.

The Vacation Lighting Director is a good example. I’m currently making some mods to it and this is one of the things I’m considering changing. It allows lights to be turned on randomly every X minutes. It does this by detecting the mode change and if it’s the right mode, it will call runIn every X minutes until you exit that mode and only act if all the conditions are met. If there are time/day restrictions, that could potentially be a lot of checking without actually running anything.

Is each run and condition check time intensive, in and of itself? Of course not. But because we’re dealing with the SmartThings infrastructure as a shared resource, and given that they have had/are having problems during times of peak load, I think that anything we can do to limit resource utilization could be a good thing.

The Vacation Lighting Director is just one example but you could make same argument for almost anything that takes the polling/service manager approach, like the MyQ Garage Door Opener. If that app had time restrictions, that could actually be a lot of wasted resources since that’s making http calls.

Hell, I still can’t get the Sunset/Sunrise Mode Magic app to run consistently. It frequently misses one or both triggers and from what I’ve read, it seems to be because of load.

Justin

6

Just so everyone’s clear, Bruce is a real person. I’m not speaking to an imaginary friend. He just deleted his responses. I’m not crazy :smile:!

8

It was a good and thoughtful response that I thought was going to lead to some good discussion, but alas…

The gist (and I may be paraphrasing slightly) was to say that a) with the current limitations on input validation, you may have to validate inputs in code/method handlers, rather than the UI and b) restricting an app to run only during certain times doesn’t need to be scheduled, instead giving the example of motion detection – just check all your conditions when motion is detected, hence my point that in certain apps are not triggered by some external event (e.g. a device), but instead run constantly/periodically while in a certain mode and/or restricted by day/time and could be scheduled to run at a future time, making better use of resources.

That should fill in the gap!