I have several different rules that follow the same very simple format:
Trigger: Motion Reports Active and Stays That Way For 18 Hours
[or Motion Reports Inactive and Stays ....]
Action: Notify me about something and set a boolean variable that is used to enable/disable automations.
Two example use-cases that both use this basic structure: (1) warning me when a zone motion controller covering all the common areas of the home has remained active for an extended period -- this is important because we use all motion sensors in the common areas of the house being inactive as a trigger to put the house is Sleep mode at night so I want to know if some motion sensor somewhere is stuck on active so I can fix it proactively; (2) when none of our cameras have seen a dog (triggered from Blue Iris) for an extended period, it means the dogs are elsewhere and all of our dog-related automations can be disabled for now.
The above rule structure always (often?) seems to result in the following error message: java.lang.IllegalStateException: app 1492 has 76 scheduled jobs already on line 9767 (method allHandler)
What does this error message mean?
And is there a way I can structure the rule to prevent this build-up in scheduled jobs?
There was a fix made a version or two before the one you're on that should have helped with this. See if just hitting Done in the rule fixes it going forward, although I don't recall that being necessary for this particular problem.
There are also other ways you could write this, though I'd be curious since I don't think there are any known problems with this kind of trigger anymore.
First of all, hitting Done in the rule should clear this up, at least temporarily. There was a fix for this problem released recently, but there could still be a problem. I'm looking into it...
I “doned” out on all the rules that follow this structure and will monitor closely. Thanks so much for the response. Typical of Hubitat staff and Hubitat community.
IMO you need a different approach than this. It's going to keep scheduling those Stays for 24 hours, and given how many events involved, that's simply a bad idea.
Yeah I was thinking the same thing (if less confidently than you lol). I was considering rewriting using Time-Since-Event condition but you've discouraged that approach in the past, so not so sure.
Curious if you (or anyone) has any suggestions on better approach to triggering when a device remains in a certain state continuously for a certain period of time?
Wait for event: elapsed time --> timeout 24:00:00
Notify: "%device% %value% for 24 hours!"
Sometimes people question if this approach will actually work, and the answer is yes; if it's confusing, the Rule 5.1 docs explain the cancellation behavior that make this work -- a trigger event cancels the "Wait," so you'll only get to that notification if it stays in that state for 24 hours (or whatever you say).
This is a bit easier if you care about getting "stuck" in either state; if you only care about one, you can trigger on active, use "Wait for event: motion inactive --> timeout 24:00:00" instead, then set a local variable to %device%, see if that variable equals "timeout" (this is what will happen if this action was reached due to the timeout, as opposed to the triggering device name -- so you'd also need to modify your notification a bit from my example), and enclose the notification action inside this conditional so it only runs in that particular case.
My approach would be for each device's rule to trigger when motion becomes active and to set a system time variable for now+24 hours, e.g. motionOfficeDeskLast, motionGuestBathLast, motionDiningHallLast. Another rule to trigger on that variable time and send a message with the device name. Clone the pair of rules for each device you have.
If motion is triggered, the system variable for that device will keep getting reset for 24 more hours and the second rule will keep getting rescheduled and never trigger. This way, each rule has it's own independent device subscription (first rule) and independent schedule (second rule) rather than one massive rule that subscribes to 25 devices and triggers a 24 hour schedule every few seconds because 1 of 25 devices became active.
I don't use Webcore, but if it can run a loop on a list of devices (like a foreach), the the variable could be set to "now" and then the "second" set of rules could be combined into one and run, let's say, every hour. It would loop through all of the devices, look for its corresponding variable and see if it's been more than 24 hours to send a message.
To be clear, the solution I suggested would be one Rule for each device, not a single giant Rule for all devices. There would also be at most one scheduled job for each (and it avoids the complexity of introducing a hub variable or something else, which you don't need if the automation as described is the only goal).
Fair point. I use a zone motion controller (ZMC) as a sort of group motion device. So RM5 processes the rule as one device even though it's a couple dozen.
