I have recently updated my hub to the most recent version, and noticed one of my old rule is not working as it should (I wrote this rule about 2 years ago and never missed a beat until the recent update).
It is a basic rule to switch between Night mode at 0100, and Home mode at 0600.
After the recent update, I noticed the 0100 trigger and action will work as it should, but the 0600 trigger would not trigger and therefore action not performed.
I then updated the '0600' to '0601' in an attempt to update the rule and hoping it will kick it back into gear.
I went away for two days, and came come to check on the log and found the following:
As you can see from the log, the 0100 trigger event and action did run at 0100 as intended, but the 0601 event for some reason ran at 0707 instead.
I couldn't figure out what would have caused this, any help would be appreciated. Ideally I would like to avoid re writing this rule in RM5.1 as I won't be able to set the value of Global variable in RM5.1
One idea: look in the "App Status" page (gear icon) under "Scheduled Jobs." You should see something at 01:00 and 06:01. If not: did you hit "Done" (or "Update Rule"--same thing, but it doesn't close the app/page) after you changed the triggers? If not, you'll need to do so for the trigger changes to take effect. Even if you don't change anything, it can still be helpful to "re-initialize" these schedules, so I might try it anyway.
Assuming that all looks correct, the only other thing I can think of is that perhaps your hub was severely busy at this time and the execution was quite delayed for that reason. A reboot of your hub might fix this, at least temporarily. You may want to check out the "Logs" page and look at "App Stats" or "Device Stats" to see if anything seems to be particularly resource-heavy, which might ultimately be the cause of this--if that is indeed the case (this is just a guess). Another guess: I'm not sure database corruption could cause this specific problem, and nothing in your logs suggests it, but a reboot might help with that too, or a soft reset and restore if you want to be extra-sure (all your devices will remain paired as long as you don't do a full reset, which is now difficult to find).
As an alternative, you could clone the rule, then edit the rule and copy to only have a single trigger each (0100 or 0600), then delete the time dependencies in each rule so that each rule only does what it should when triggered. That would remove any hub load scheduling issues.
I have definitely updated the rule and hit done after every change, and I have also checked the job schedule and it appears to be correct (I have changed the trigger back to 0600 for now)
I don't think the hub was busy would be the reason for my problem, as you can see in the log from my first post, the rule triggered at 0707 on 15/12 as well as 16/12. If hub load was the issue I doubt the rule will trigger exactly at 07:07:00 both days.
It could potentially be a database corrupt issue, I have just updated the hub to the most recent version (2.3.0.120), which of course means a reset during the process. We will see how this goes and report back. However I am not holding my breath at this stage, as my hub has a scheduled reboot every 3 days and I have been having this issue for the last week or so, so the schedule reboots did not fix the issue for me. Hopefully 2.3.0.120 would change this.
It is very strange as this rules has been rock solid for the last 2 years and a bit, it is only recently playing up for unknown reasons.
Anyway, if it fails again tomorrow, I will try to split the rules into 2 separate rules as @672southmain suggested.
There was an urgent update about a week ago to address some issue (never fully disclosed) that could cause database corruption on all prior 2.3.0.x versions. If this is your issue, then I would suggest trying a backup download and restore, which apparently prunes bad records out of the database.
I like that idea, too! I didn't notice that the actions in the original rule were a bit more complex than they needed to be. To be clear, either way shouldn't cause any problems, but if you only trigger when needed, you can avoid some work for yourself (and the hub) by not needing to use a conditional to check why it triggered.
You can do this will still keeping everything in a single rule if you want:
Trigger:When time is 01:00
Actions to Run:
IF (Mode is Home) THEN
Mode: Night
END-IF
Wait for event: Time is 06:00
IF (Mode is Night) THEN
Mode: Home
END-IF
Set Kitchen Blinds Override to false
Set Living Room Blinds Override to false
Thus, even if some major delay does happen and that 06:00 action doesn't get executed until some later time, it won't matter--it will happen when it is reached.
No harm, but you do only need to do one or the other if you're interested in saving a click or two.
You're probably right (or at least that is strangely coincidental), but if you look at the app and device stats, you can at least take some of the guessing out of this. Might be the DB issue mentioned above, too, though I'm also not clear on exactly what issues those were.
I don't believe RM4.0 or RM5.1 makes a difference, as I have made a copy of my rule in RM5.1 to test it out but my 0601 trigger still fail to fire at the correct time.
I believe something strange is going on where the hub is 'confused' about the time when a rule has two time trigger (at least that's what i suspect anyway).
I have other rules that trigger at 0700 and that runs fine, however as mentioned above, my rule in question suppose to trigger at 0601 but it somehow triggered at 0707 instead.
Ok, since both of you say this failure occurred after the 2.3.0.120 update, have you done a regression rollback test to the prior version to see if it works with that version?
and...trying it now. Dang-did the wrong hub first time. But, did the right one.
Interestingly, I'm still seeing only one schedule job (bypassing the morning run).
It was just a mess tonight. I had a whole slew of lights that didn't come on tonight, when I entered the house, it didn't detect me unlocking the door. When I ran the scene to turn on the lights--very few turned on. All in all, .119 was nearly perfect--and my first experience with .120 was a disaster. Not sure if that was random bad luck or not (suppose it could have been)???
I may leave things back on .119 for a bit and see how it goes.
Personally, I’m not noticing any difference between 2.3.0.119 and 2.3.0.120, but I don’t have any rules with Sunrise/Sunset and offsets as triggers, and no rules with two certain time triggers.
I do have Sunrise/Sunset and offsets and/or times of day, in Rule 4.0, 4.1 and 5.1 and haven't seen any issues. And there don't seem to be many reports of this issue.
Maybe clone that Set Outside Lights rule twice so you can reenable the original unaltered rule if necessary before you do the folowing:
Pause the original rule (don't touch it otherwise), and put the sunrise trigger in a one of the new cloned rules, while deleting that from the other 2nd cloned rule, and see if it works then?
Then add the unlock to the first clone, then add the button, (removing each from the 2nd cloned rule as you go) and see what it takes to make this fail.
