In several my rules where I use delayed actions, I get the following error code:
I also get this in every one of my apps that use runIn()
It all started yesterday while I was working on one of my custom apps but when I saw today it was also happening in RM (while my apps are deactivated), I figured it had more to do with Hubitat.
Also happens in device drivers such as Generic Z-Wave Dimmer:
Let me know if you need more detailed info. Here is a snapshot of one of the rules returning this error:
Your last If doesn't make any sense. You have the light being off as a condition and the only action is to turn the light off.
Also, I don't think you realize that the two main IFs in the first part of the rule are going to happen simultaneously. It is possible that a contact sensor will be open and a motion sensor will be active at the same time. The concequence being that the you will schedule the off and then turn the light on then cancel that schedule and schedule another.
Also, what are you using the schedulesOn variable for?
I would recommend the following, you construct your rule with a simpler If-then, Else if-then method. I would re-write it as follows:
If Any contact is open or Motion is active THEN
Cancel Delayed Actions
If Light is off THEN
Turn light on
End-If
Else if (All motion inactive )
If (contact closed) THEN
delay actions by 10 seconds
Else
delay actions by 5 minutes
Turn off Light
END-IF
Now, why you are getting that error, that sounds like you are getting the error because it is trying to schedule two delayed actions.
Indeed. Not sure it's related to the issue, though.
For a very good reason: making sure the light never stays on for any reason but events.
Yes, and that's on purpose. If the door was opened, but no motion happened, then don't leave the light on for more than 10 seconds. If it was opened AND there was motion then cancel the 10 seconds and schedule off for 5 minutes.
But, again, I'm not sure this addresses the problem I'm referring to since the above mentioned error code is also thrown by built-in drivers.
Well, I did quote an error code from the driver too... in the same first post. As I said, this was just an example of the fact that it happened to every app using schedule() . Just wanted to give as much info as I could, not knowing where that was really coming from.
This is why a screenshot of the error is always better because it would show whether the error was linked to a device or an app. But if it's happening for other things, not associated with this rule, why would you think something in this rule is at fault?
But it may do, because your rule doesn't run like you think it does. There is loads of holes and edge cases in it and the last part doesn't work at all. If the light was ever off when the rule ran (which it never will be because the rule will only ever turn it on) scheduleON will be false. You then say IF it's false and motion active and the lights ON (which it can't be for schedule to be false) turn off the light.
Your logic is flawed so could it be your other code are flawed?
BTW one of the edge cases is, what if you go in and constantly trigger the detectors so none ever go in active. The lights will still go off after 5 mins.
Point being if we can help you build this rule and it doesn't show errors you can then whittle down your issues.
Yes it will, because your trigging an off with a delay on the active, the only time that delay would get cancelled is if the rule runs again on a active. The only way to get the rule to trigger is on a change event from inactive to activate for what I said IS correct.
That just means you haven't hit the edge case yet, it still makes your rule poorly written and likely to cause your issues.
I think your looking at this from a program point of view this isn't how rules work it's basically a macro with conditions. So unless your willing to let us help you out with this, which inturn should help you out with your error I don't know what we can do!
Other than pull in the big guns to hopefully support my theory or tell me I'm wrong. @bravenel any suggestions here? As my post were flagged and restored I believe I'm at a impasse with this one.
The rule is definitely problematic from a flow perspective in that it is unlikely to actually do what you want (unless there's another rule we aren't seeing that might act on this one in some way), with it falling to the common "turn lights on then off after x minutes when motion active" problem instead of "turn lights on when motion active then off after x minutes when motion inactive" flow that most people actually want. @BorrisTheCat has accurately pointed this out twice above; Ryan780 has provided an example that will flow in the way most people would actually want this to work.
That being said, I'm not sure this should actually cause the errors you see in your logs. The fact that it happens in both an app and a driver is one additional clue. Since Bruce was tagged, I'm sure he'll chime in. But my guess is something may have gone corrupt (though this is not an error I've seen before in that case), and a restoration to a hub backup from before you saw this problem may help. If your hub "knows" the database is corrupt, my understanding is that it will restore the last known good version on restart, so that is something you could try if you haven't already (but I'd recommend downloading multiple backups from various times. especially times when you think it was good, locally before trying anything so you have something to fall back on--a good idea regardless). You could also manually restore something yourself. But you may wish to wait to hear what staff think first.
As I said, there are indeed other factors to be considered that you don't have and the device driver issue WAS the clue that INDEED makes it irrelevant to the issue at stake, as you say it yourself @bertabcd1234.
I maintain this rule works exactly as needed, several times a day and has been doing so for months. Again: not the topic here.
What this rule does, and does very well:
if contact is open -> turn on the light for 10 seconds only.
if motion is also active -> Cancel 10s schedule, keep on, schedule to 5 min and remember there's a schedule
if light is off you can forget the schedule
but if there is NOT a schedule (so wasn't triggered by recent occupancy) and light is on while there is no motion (anything turned on the light from another app, a random signal, anything... ) make sure to turn it back off immediately (because it is also relatted to an electric heater that mush NEVER run when there's no contact/motion events).
The only edge case I see is that the light might be scheduled to turn off in 10 seconds while there's occupancy but that would involve someone pooping with a door wide open. Usually people are quite decent in my family.
This is the bit I can't see. A you would have to trigger the rule from another rule so that all contacts are closed and the motion is inactive then everything would skip untill this bit.
Then if the lamp was OFF and the rule was ran by another rule it it would set the variable to false, that's it, on that run, nothing else would happen. Then if you ran it again after the light was turned ON by something else then it would turn OFF the lamp. That's how it works. So that would mean you would have to constantly trigging this rule else where, in order to check it? That's not a good idea and it just wasting resources, essentially making a on event driven system, no longer one, which isn't a good idea. It could be done much more efficiently and only running a rule IF it gets turned on elsewhere. This may be connected to your error.
I'm happy to be proved wrong, I'm just trying to get to the bottom of it and currently you seem to want to hide the rest of the story?
I might also suggest this: can you create a minimal rule where you also see this problem? I doubt it's related to a specific app or driver, and I might suggest a restore to a known good time if this is a pervasive problem (or faulty code like a custom driver might have) and you don't hear anything from staff.
Guys, I've forgotten to mention that the error doesn't happen anymore and stopped happening after a fresh reboot and hasn't happened again since then. Also, have I forgotten to mention that it was triggered by buit-in device drivers? I think I did paste an error code mentioning it was from the generic z-wave dimmer driver, did I? LMAO
Sorry, can't help it, this is very funny to me! Even if you were right about the logic of my app, you wouldn't be assessing the issue since I had evidence the error code was also triggered from a driver, which was not even related to the rule.
Now, to conclude, I think I found the origin of the error and it was from a an app I am developing. It's an attempt to work from a 3 dimensional array of weather values so it can learn from user inputs (I think some call that machine learning...). The whole challenge is to make it work without taking to much resources.
@bravenel, the error code is happening again, pretty much everywhere on my platform. It looks like something like scheduler.deleteJob(Key) isn't working somewhere and I wonder if it's not a bug in the firmware itself. I'm saying this out of courtesy to inform you in any case it could be effective and useful to you.
Thanks.
