Have an app that turns the house off if there is no motion in 24 hours. Every time there is no motion, a stayshandler task is scheduled. This is resulting in a huge number of these scheduled events - one for every time motion times out. I do not believe this was the case before and after a while it starts causing Hubitat errors:
2025-05-23 06:49:26.852 AM
error
java.lang.IllegalStateException: app 41 has 76 scheduled jobs already on line 9768 (method allHandler)
do you have an unschedule() prior to the schedule??
An example from a recent app....
unschedule(reschedule)
schedule('7 7 0 ? * *', reschedule) // reschedule the midnight run to schedule that day's work.
In this example, I have more than one scheduled event, so I explicitly unschedule. If I only had one, I'd just unschedule() to remove all.
OR
schedule() has an option:
options- Optional values to control the scheduling of this method
- overwrite - defaults to true which cancels the previous scheduled running of the handler method and schedules new, if set to false this will create a duplicate schedule.
Documentation for both schedule() and unschedule() is found here:
I've found that unschedule() aligns with my brain better 
Did you write a custom app or are you talking about a Rule? The only clue that it's the latter is that this name matches one Rule 5.1 will create, though there's no reason some other app couldn't...
If so, sharing a screenshot and logs of the Rule in question would be good, along with what hub platform version you are running (check Settings > Hub Details).
Sorry I should have said RULE not App - my mistake.
Hub version is 2.4.1.174
Rule in question is:
After restarting the hub, after a while the log starts showing exceptions:
And I believe it is caused by the excessive number of scheduled jobs for the rule shown above:
Every time there no motion, a new stayshandler job is scheduled for 24 hours out but none o the previous are cancelled. I never saw this before the update to the current version.
You're a couple builds behind, and each has fixes for Rule 5.1, one of which might be related to your issue. Release 2.4.1.176 is current:
Does upgrading change anything?
You may also need to hit "Done" (or "Update Rule," no difference aside from the fact that the former takes you back to the previous page) in the rule after upgrading -- maybe not for this problem, but it was necessary for some others and can't hurt if you aren't in the middle of the actions or otherwise have a reason to care about re-initialization.
The problem here is that every time there is motion, it starts a Stays timer for 24 hours. So during a 24 hour period, that adds up to a lot of timers. You need to rethink how you are approaching this automation. Your rule is simply an example of one that won't work for practical reasons -- in this case, too many Stays at the same time.
updated hub and updated rule, but no help. But thanks...
I am sorry but I have to take issue with your reply because:
1. this rule had been working fine for a long, long time until I updated the hub
2. Why offer the ability to set the "stays" rule setting for any large number of hours(I tried 999 and it was accepted) if it only creates a problem?
3. If old/prior "stays" handlers are not cancelled when a new one is issued, that effectively make the "stays" functionality useless since even with a small number of hours specified and a lot of motion a huge number of timers will be created in a short period of time.
I have to believe this is a bug and should be addressed primarily because it worked before.
I hear you, and I will look into it. There were a lot of changes made to Stays triggers in 2.4.1, and it looks like your case is one that was a victim of that. We will get it sorted out.
Thanks, I appreciate it!
Fix for this has been made; next release...
Great! Thanks for the update.
Download the Hubitat app
