[2.2.6.140] C-7 RM4.1
What am I missing in the first rule ?
In this rule, the Off:Vacuum --> delayed: 0:00:30 (cancelable) does not execute.
However this variation does:
1 Like
Lol, we just posted effectively the same issue within 10 minutes of each other - I've been seeing the same issue in RM4.0 with previously working rules.
Weird. Your rule definitely isn't missing anything (though there's no reason to mark the delay as "cancelable" since you're never cancelling it--but it shouldn't matter either way). I just tried this quick rule and it worked fine:
As seen by:
For fun, I tried it with "cancelable," too and it worked. But, of course, my action is a log and not a switch. But I see the other rule is a thermostat, so I'm not sure there's much else in common. These were all manually triggered by me clicking "Run Actions."
Ultimately, Bruce will probably have to comment on what he'd find helpful to troubleshoot this. In the meantime, I'd be curious: when you are in the delay period, do you see a scheduled job on the "App Status" page? (This would be the gear/cogs icon for that particular rule; under "Scheduled Jobs," you should see something for "delayedActCancel" or "delayedAct," with a scheduled time for when your delay was up--as far as I can tell without really knowing more of the implementation details.) If you don't see that, something is definitely wrong, but at least there's an explanation; if you do and it doesn't fire at that time (does it disappear afterwards? might also help troubleshoot), then there's still something weird, but at least it's supposed to happen...
Have you tried a longer delay? Not a solution, but may help understand what is happening...
The cancelable was included because I have more actions to be added to this rule. The Vacuum is a simple Zooz ZEN15 switch.
I believe I first noticed it then testing with "run actions". I don't recall if I ever tested by allowing the rule to run via its schedule.
My RM4.0 delays range from 5 seconds to 9 hours, it’s broken AF! These rules worked perfectly for months before 2.2.6 .
That makes it clear cut then, was wondering whether 30 seconds could have been a little short if the hub was under load or something like that. Very much a shot in the dark and highly unlikely, but your situation rules anything like that out I suspect.
1 Like
I would again suggest looking at the "App Status" page when the delay should be counting down to see if you have a scheduled job listed there. It won't help you solve the problem either way, but it will likely be helpful for staff to figure out whether the problem lies with creating the schedule itself or in its execution. I forgot to mention turning on action logging (as well as anything else you might want), but that would be a good idea, too. I suspect staff may have additional ideas.
Other than that, if you believe it's new in 2.2.6, you can use the diagnostic tool to downgrade to 2.2.5. Obviously this is not a fix per se, but something you can try to get things working again if something here is indeed a problem.
1 Like
It gets worse (I think).
New rule (Lucy is a Sengled Classis bulb)
Rule: Created ~12:15 AM
Schedule shown:
So the schedule is not getting set to the correct time. It should be about 12:35 when I took the screenshot.
Right now the alternate configuration is working for my original need.
Maybe I'll have more time tomorrow to recreate this rule and watch it for a cycle or two.
It may be doing what it is meant to...? I am thinking you need to set the minutes to be each of the minutes throughout the hour you want it to run, or maybe there is another option for every 10 minutes? I was literally playing around with CRON myself in a driver I am writing, here's how an online site interpreted the schedule from your last screenshot:
From Free Online Cron Expression Generator and Describer - FreeFormatter.com
So it is saying at minute 10 of every hour, not every 10 minutes. I'd have to check in RM what option you may need to choose for every 10 minutes, but like I mentioned earlier, I am thinking you could just select the times throughout the hour you want it to run.
Simon
If you take a look at my examples:
You'll see that in Rule 1 the rule is running and the action prior to the delayed action is firing as it should (there isn't an action after it) and turning the TS to Heat mode.
And in Rule 2 the item after the delayed action is also firing and turning off the Virtual switch, but it is not setting the fan mode back to "Auto" (the Delayed action).
In summation, it's the "Delayed" actions that are broken, the rest of RM works as it should AFICT.
I did, but I looked again and didn't see a check of App Status. This may be helpful because:
Yes, the scheduled job I mentioned above would relate specifically to the delayed action. Again, it won't really help you (or us) solve it since the rule appears to be written correctly, but it could be helpful for staff to pinpoint what might be going wrong where with delays (is it not getting scheduled or just not running?).
Yep! (And regarding the job above, that would be for the trigger, not the delay, and I agree that that much looks fine.)
1 Like
Well yes, they are written properly - these 2 examples (I have others that are doing the same thing, but I wanted to provide 2 examples that showed before and after behaviors + both possible uses of a Delay in RM) had been working for months without modification prior to 2.2.6.
The Scheduled job appears to be created (from example Rule 2) - this is the 1 Hour delay.
If I use my programmatically created cancel (turning the 1 Hour Virtual switch off), It behaves as it should and sets the Fan mode back to Auto. It just wont do it after 1 hour (or the other time options) if I leave it alone.
As I've attempted to point out at great length, the timer is running, it's just not performing the Action when the timer / Delay completes. This is proven by the before and after actions running.
This is really only possible to prove in your second rule, and not just because (as you note) there aren't an actions after the delays. The delays on on action, as you may know, get scheduled for later, while the rule continues immediately with the next action, so it wouldn't help even if there were. Since the OP suggested that these delays were problematic and had a different experience with "standalone" delays like the in your second rule, I thought it may be helpful to determine if the one that is problematic for both of you is getting scheduled at all. Again, nothing any of us can really do about it either way, but it will likely be helpful for staff to troubleshoot. I apologize for any frustration you may have experienced with explaining your rule(s) more than one time.
So what's odd is that both kinds of delays are problematic for you, only the former are problematic for the OP, and I can't seem to reproduce the problem at all. 
These were new Rule 4.1 instances I created on the last build of 2.2.6, so if you wanted to try re-creating any of these to see it that helps, I suppose it can't hurt (but might be time-consuming for no reward if it doesn't--and is, of course, not something you should have to do, but may or may not fix a problem). Otherwise, again, I might suggest a rollback to 2.2.5 if these problems are getting in your way. But hopefully staff can figure out what's going on! (@bravenel if it's RM-specific, maybe Victor if it's something with the scheduler?).
I have seen the scheduled action be created for the 1st example rule, I just didn't screen capture it at the time.
If there was a way to upgrade rules to 4.1 i'd happily test this.
As a subscriber to the Hubitat Protect service, I'd rather not roll back to 2.2.5 and lose my cloud backups etc.
My suggestion was to create a new rule to see if starting from a blank slate helps, so that's the same as the "upgrade" path anyway: creating a new rule. 
But again, not a guarantee, more just something that I may ir may not help.
1 Like
Just to add data, this appears to only affect some rules and not others.
I can’t find any rational explanation as these rules l all worked perfectly pre 2.2.6 and use the same logical structures (I have 3 thermostats and the rules all work the same way).
I'm 3 for 3. Every rule I created (all from a clean start, ie no cloned or modified rule) had an issue with this syntax.
The rule in my post #9 is as simple as I can imagine. A light on a schedule with a delay for off.
UPDATE see next post.
