Rule Machine and ST Schedule Woes

Continuing the discussion from Scheduled Jobs Failing AGAIN:

As many of you are aware, there are ongoing issues with scheduled events in SmartThings. While these are being worked on, some new issues have surfaced. One of these issues concerns the use of unschedule() by SmartApps.

Beginning yesterday or the day before, users have also seen errors thrown that say “Undeclared Throwable Exception”. As far as I can tell, these are being thrown by unschedule().

For over a year, there has been discussion about how unschedule() is not reliable, and sometimes pays a high execution time penalty, so much so that some apps would be killed due to exceeding 20 seconds runtime. Pollster is one app that has had this problem. It became clear, that Rule Machine also was vulnerable to this failure.

So, I have pushed a new release of Rule Machine, Version 1.7.5, that removes its use of unschedule() for delayed actions with cancel and delayed on/off pending cancellation. Instead of using unschedule(), Rule Machine now handles this logic itself.

This should improve the performance of Rule Machine for these types of operations. However, Rule Machine still makes extensive use of ST scheduling, and is still vulnerable to scheduling issues in general.

7 Likes

Thanks @bravenel, do we have to reconfigure any of our rules?

No, your Rules are fine and don’t need to be changed. Updating Rule changes how they function in this one regard.

1 Like

Perfect. Btw - if your app ever does get published, I hope you will continue to update your github repo as its so easy to update.

Don’t hold your breath!! :grinning:

1 Like

No kidding - however, this brings up a very good point… if RM gets ‘published’, the architecture that ST uses, with hardcoded apps in firmware, would require a new firmware update for each new release of RM… :frowning:

While I’d gladly take more stability/speed for RM local execution, this will make it challenging as Bruce finds/fixes things and adds new features. To me, this architecture seems short-sighted - I’d much prefer a way to ‘dynamically’ bring Smart Apps down to the hub. @slagle - any thoughts from ST on maybe implementing that in the future?

Thanks.

1 Like

Soon, RM is next on the list. :slight_smile:

talked about here:

2 Likes

When you say “Soon”, do you mean days, weeks or months?

1 Like

Thanks @slagle - good conversations going on in that thread, and interesting history I didn’t realize about design considerations for hub v2.

I certainly hope that local compilation/caching of Smart Apps and device types can be accomplished. Right now, @Robert_Vandervoort’s device handler for Multisensor 6’s is more reliable for me than the system default one, and I’d hate to lose the potential of local RM execution because my sensor device handler is in the Cloud.

Great to see you folks thinking about and pushing these things. It’s appreciated.

1 Like

Could you let me know more? I’m not sure I understand (though I suppose I could did into the code…).

There’s a lot of SmartApps that use “unschedule()”, and if there’s workarounds, they would really valuable. Thanks!

Simple, just use a state variable. Set it to true when you do the runIn(). Then set it to false where you would do the unschedule(). Then, test that variable in the handler specified in the runIn(), and only run that code when it’s true.

When runIn() is called again, irrespective of the state of that variable, that’s going to wipe out the older scheduled event (if there is one), and set the variable to true again. So, it ends up having the same effect as unschedule(). Still vulnerable to the runIn() scheduled job not running or getting hung in the cloud.

2 Likes

Clever, thanks…!

But that won’t help with “cron” type scheduling, right? There’s a limit of 4 scheduled activities per SmartApp … I don’t know what happens when you attempt to schedule the 5th … does it knock out the 1st, or do you have to unschedule() one of them…?

1 Like

Terry, you are correct. cron scheduling works differently. This only works for runIn().

You have to specify in the runIn() that you want this one to be scheduled in addition to any others, otherwise it overwrites the existing runIn(). The normal use of runIn(), including what RM does, does not request multiple scheduled jobs. So, this works fine for things like motion off, and maybe less fine for something that has multiple future jobs stacked up. [overwrite: true] is the default for runIn(), but doesn’t really work with cron.

Your comment made me realize that it is quite possible to create a rule that attempts to schedule more than 4 jobs. Obviously, such a rule would fail. I’ve updated the documentation to reveal this limitation.

The worst user of this limited resource is a Time of Day condition using sunrise or sunset, which results in 3 scheduled jobs. There’s still room for a delayed action, but nothing more.

1 Like

Is there any warning from rule that a rule exceeds the documented limits?

I’m not sure folks will understand if they have violated one of these use limits.

No, there is not a warning. I’ll look at building a counter and then enforcing the limit by disallowing inputs that would be over, perhaps able to provide a Sorry message there.

I just tested this, and the first scheduled job set is the first one wiped out when there are too many.

This is interesting: I just loaded up a Rule with 6 scheduled events, the maximum possible with Rule Machine. They were all scheduled correctly and the rule executed with one of them, a delay, correctly, reducing the number still scheduled to 5.

Hmmmm. Maybe the 4 limit isn’t what we think!

unSchedule() appears to be completely broken!

Edited to Add: It actually allowed 6, but they were not set correctly.

1 Like

I have updated: http://thingsthataresmart.wiki/index.php?title=Bug:_Schedule_Methods_Cause_Fatal_Java_Error

1 Like

Before you sprint for RM, can you PLEASE fix the Windows Phone app?

1 Like