@bobbyD @bravenel are there any known time based bugs that can impact basic rules in 2.3.7.145?
Today my mode change from night to home failed to run @ 6am. My hub was online and working and should have been in a clean state due to having rebooted over an hour before.
No clue why. No, there are no known time based bugs.
As above, my really simple rule failed to run at 6am - could be an edge case tho, as it has been working fine for a really long time. So long in fact, I couldn't recall how i'd configured the mode change over.
Ah, you live in the Southern Hemisphere. What time is sunrise? If it’s before 6 am, your mode might not have been night.
Sunrise shouldn't have anything to do with it, the rule uses 6am as a fixed time.
Maybe totally unrelated and I chalked it up to power outage shenanigans. Buuuutt..... Yesterday, my early morning to home mode transition failed to execute. I noticed at 8:30 that the lights were still reacting like my early morning setup.
Again, the night prior, we had a 5 hour electric and slightly longer internet outage due to severe weather. I chalked it up to the fact that although the hub was on at midnight (assumed the sunrise/sunset check runs sometime around there), the internet was out till around 3 AM. So, I was thinking the hub did not get sunrise/sunset data to know when to run my mode transition which runs at 6 AM also unless Sunrise -15 is later than 6. Right now it is not. Usually around 7:30.
However, now that I think about it, the modes knew to change to early morning at 4:30 AM. They just did not transition at ~7:30, when they should have. So, that throws that theory out unless the Sunrise/Sunset values had been null (I did not check before I rebooted) causing the comparison to error or something. I had no errors in my logs.
I just ran my rule that I kept from way back when the modes did not have the option to set system mode at startup based on time table. After that, it has been running fine (including this morning it ran fine)
Interesting! I have been using Basic Rules to change from Night to Home for ages, just becasue it was easier at the time (several years ago).
The reason I picked on Basic Rules as the possible culprit is Mode Manager only responds to Presence, not time in my config. After my Alarm panel started beeping at me, I went into my HE Security dashboard and manually changed the mode to Home and everything worked after than.
Have you checked the Mode changes in the Logs?
EDIT: Hmm, I didnt look far enough back, there's something odd going on that I need to look into.
Huh, I've never seen that before.... my modes all went haywire. 
EDIT 2: Doh! Device logs dont go back past 6:35am, so I cant see what else was going on. 
However based on the Hub events, Mode Manager changed the mode back to Night at 6:02 am, but I cant find any rules I have that could have done this.
Night mode is manually triggered by us before going to bed.
Could it be the disarm events shortly after 6am? It would a fair delay if it was...
Night mode turned back on a full 2 mins later tho. The thing is, I do not automate Night mode turning on ever - it's 100% manual via voice command or alarm panel.
I've also made no changes to my modes rules in a really long time.
The other thing that confuses me in those logs is the "Security - Osborn Override Mode - Turn On" mentions - that rule requires manual activation????
Feels like turning on logging and keeping it for longer may be all you can do at this stage.. then see if it happens again. That is, if you can't see more details on what triggered the rule....
Without the logs it is a hard one to diagnose.
Agreed. I'm just going to reboot my C8 - to me it feels like something went haywire.
@bravenel I think I found the trigger causing this issue - but I think the root cause may be in Mode manager.
After being woken up at 4:30 am by my alarm panel and seeing lights on that only turn on when the House state changes from Night -> Home, I picked up my phone a look at the logs etc. I then heard Alexa announce that my wife had arrived home. So I checked logging for my wife's instance of advanced combiner, as it manages her "presence" for Mode Manager.
Any way, what I found in my logs was her presence flapping quite badly, as her iCloud presence had stopped updating and showed her as away.
Anyway, it turns out that with her presence flapping, it had given Mode manager a hard time and it was ignoring my presence (which seems fine and is stable) and causing house modes to play up.
What I cant explain is this entry in the logs "Security - Osborn Override Mode - Turn On". This rule requires the keypads on my deadbolt or alarm panel to be physically used.
Anyway, I think there is a bug in Mode Manager that is preventing it from behaving correctly in the case where one presence sensor is misbehaving. I think it should at least be fairly easy to simulate in a dev env.
You would need to show logs from Mode Manager in support of this assertion. It seems as though you have a very complex setup with respect to managing modes, and that won't make it easy to diagnose. You know me, KISS is you want to avoid weird problems.
I didn’t have logging enabled unfortunately.
The setup is not as complex as you suggest. Mode manager relies on 3 presence sensors to detect us coming home, and 2 leaving (daughter forgets her phone sometimes so hers isn’t included).
I was home the whole time and my logs show I did not leave during this issue. As my wife’s presence was relying only on wifi and ble for presence as her iCloud component had stuck, her presence overnight was frequently changing from home to away.
Once I found this was the case and fixed her iCloud presence, everything stabilised.
It should be very simple scenario to independently test, all you need is 2 virtual presence devices, mode manager (configured as shown above) and a rule to cycle one of the presence sensors from home to away and back again every 5 minutes.
Based on my location logs, it took from when we went to bed at 11pm, till around 12:13am for the first issue to occur. And then another 4 hours for the next next issue to pop up.
Again, with no Mode Manager logs there is nothing to discuss here. The testing you suggest has been done and Mode Manager works as expected.
Hmm ok, thanks for looking into it. It must be a confluence of events issue.
Anyway, after fixing my wife’s iCloud presence, the issue has not reoccurred.
If I get bored during the week, I’ll do some additional testing on my spare C7.
The only thing I’m still seeing is this Legacy RM rule is still running.
Despite it supposed to be only triggered by my keypads.
Any idea?
The logs show that it was triggered by Osborn Override Mode Turn On, but you don't have such a trigger. So, either you used to have one and never hit Done, or there is some vestige hanging around. Why don't you simply re-create that in Rule 5.1? That would take less effort than posting here about it and me spending time on it.
Download the Hubitat app
