My latest project is a Hue-based notification SmartApp.
Part of it includes turning red to indicate that a door is open and then changing to green when the door closes. Currently, my only option is to do a runIn(60, …) which makes for a very long and somewhat random length notification.
Since Hub 2.0 will be doing most processing locally, is there any chance we could get access to groovy’s sleep() command or have an app timeout length of longer than 20 seconds?
Alternatively, I could loop through a bunch of slower commands as a sort of no-op, but calling that a hack is beyond generous.
I totally understand restricting sleep() on the cloud platform, but maybe give us access to a wrapper function that only lets it work if it’s running on a local hub?
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
4
I fear that SmartThings would be opening up a huge can of wormthings if they introduced anything that has a fundamentally different semantics when running locally vs. Cloud.
So while I’m making architecture decisions for ST, how about a flag for SmartApps to force them to run locally?
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
6
Opening an old thread, I agree that there needs to be an option to sleep or pause etc. runIn is a major problem since ST limits only 4 schedules at a time. Some apps could possibly have 5 or 6 functions which are called using runIn and in a potential condition if they happen to occur together the apps will stop working reliably. Either increase the limit to a higher number (say 100 or so) for runIn or provide access to alternative mechanism for small delays, say upto 10 seconds.