The rule as noted, works (or did) flawlessly up until recently. Mode manager did not work correctly for me when I tried it last. I could never get it right no matter what I did or how I set it up. And I did try multiple ways and multiple times with Mode Manager.
I think my main problem with mode manager and the built in home vs away mode is that with swing shifts and with two people doing so, there is never a fixed time or day when we might be home except from maybe about 10PM to 4AM. That causes huge issues with lights and other things that rely on having specific modes to work properly. That is why I have the "convoluted rule" as you call it. I am sure that if you have a more of a fixed 9-5 schedule MM works fine, but it was always in some wrong mode and breaking automations for me.
I did say above that logs don't show the midnight thing happening, only the rule running after midnight and the correction to this weird flip-flop of modes. I am not sure what else I can show you if the logs don't show anything?
This is something internal to the hub that I cannot see anywhere except in the events logs shown above.
I suppose I could try Mode Manager, but I am nearly certain it will not do what I want or need it to do, just like when I previously tried it.
I guess the best thing to do is make polling even shorter, and just let the hub do it's thing.
But I do believe there is something odd going on that did NOT happen say a month or two ago.
Based on what your rule does, it will definitely work for you. But, you need an extra away mode, and a rule triggered by it becoming that mode to decide whether to set the mode to Away and Night or Away and Day.
I will try this when I have some time, but I don't see how that is a whole lot less complex than my rule. Now I will have a rule AND Mode Manager to deal with and troubleshoot.
I still strongly believe that it is something that is happening in code somewhere.
Again, I don't think it is a rule problem or a Rule Machine issue. It is happening exactly at midnight, and not on 3 minute or 7 minute or 13 minute polling, or any other timing where it would be likely to hit 12PM exactly on the nose every night. I mean, it is within a millisecond of 12 PM every day!
It is only has this one strange thing happening and I don't see the rule doing it in logs or any place else I can see. The rule works great other than this one glitch. I never had this midnight issue until recently.
OK, probably those mode changes at midnight have nothing to do with your rule. Something else in your system is setting the modes at midnight. It's not a hub issue, or we'd be seeing it from every user on the same build. You can rule out that it has to do with that rule by turning on logging. in the rule.
I already did that, and nothing shows at midnight in the rule logs day after day. It logs all other events just fine though. It basically shows the rule running and then suddenly I am in the wrong mode, and the rule runs its periodic poll where it switches back to the correct mode.
I am not sure what else could be doing this, the only thing setting modes is this rule!
Try this: Delete Night and Home mode from your system. Then create it again with a slightly different name. Check all of your automations that use that mode to change them to the new name. For the most part, automations use the mode name -- a couple use the mode id (a unique number per mode), specifically Rule Machine and Thermostat Scheduler. Obviously, this rule would have to be changed also, for the changed mode name.
The times before and after in the logs don't show it changed or has an incorrect time. Sorry for the small print, but I was trying to catch a lot in a row there.
Perhaps try and offset the rule so it doesn't run at exactly midnight, or perhaps see if you can disable the rule for say 5 minute either side of midnight, just in case it's something to do with that exact time.
Edit:. Alternatively, if it is possible, store sunset in a variable in the if statement from your last screenshot. It would be interesting to see if sunset is derived once at the beginning of the rule, so perhaps it is comparing sunset from the day before and 9:59pm on the next day. Just a theory... Probably completely wrong.
At midnight on the dot, mistakenly, sunset still refers to yesterday's sunset, and 9:59 pm refers to the new days time. So at midnight, that test is true, as you see. The change for sunset time in the hub doesn't happen until 30 seconds after midnight. This was a mistaken change recently made, that we will reverse. Not sure how that slipped in there. It's a platform bug.
@bravenel as much as you all have done in the couple of months i've been an HE user, plus ALL the code updates, i can see how a 3 and a 0 could have slipped into a line of code among the millions lof lines there are. I consider this a very impressive thing that you all can say "OPPPS!, we fat fingered something" that shows me that your only human and own up to the mistakes and fix them!! This is something that most people/companies won't do and that is a downfall in my book. So kudos to you all for owning the "boo-boo" and working to fix it! Keep it up and thank you for all you do.
