Mode problem, but not with Mode Manager

[neonturbo]

So I have been having a slight annoyance with modes. I would call it a bug of some type.

To start out with, I have not used Mode Manager for over a year now. It didn't do what I expected it to do, and it isn't even installed. So I hope we can exclude it for being the cause of this issue.

Instead, I use Rule Machine. It has done a fantastic job for a year or more now. See attached rule.

So recently after a hub update (not sure which one, events don't go back that far), this seems to have some type of bug where it switches to Sleep mode properly, then at midnight exactly it switches to the incorrect Night and Away mode. It does this consistently night after night.

So stepping through the events.

• At 8:24 it was sunset, so it went into night mode.
• Then at 10:00 it went into Sleep mode.
• I rebooted at 11:36 to try and resolve a lock issue with the .135 firmware update. This doesn't relate to this issue. This mode bug happens without me rebooting.
• At 12:00 it incorrectly goes back to Night and Away mode.
• The polling by time kicks in, the rule runs, and it correctly goes back into Sleep mode.

Initially I had a much longer polling for this rule at 15 minutes. I only shortened it to try to catch and correct this sooner, otherwise all the lights and whatever would be doing the wrong thing when the house was supposed to be in a "quiet" mode (Sleep).

Other things I have tried is checking the time zone, changing to a different time zone, checking hub time, resetting my location, along with the numerous recent firmware updates, and literally dozens of reboots due to updates and other unrelated issues.

Logs don't seem to show anything unusual. All they catch is the rule running correctly, and the mode changing to the correct mode, and not the midnight glitch. I don't think it is my rule as I don't think it would be not be easy to hit midnight exactly every night with that 3 minute refresh. Also this rule did work previously.

Sunrise and sunset seems to always be correctly set in the events. This glitch only happens literally milliseconds after midnight every night.

@bravenel any thoughts?

[bravenel]

@neonturbo

any thoughts?

First step to trouble shoot is always to look at logs...

This is a crazy way to do what you want to do! Polling is a lousy way to do this.

Why not just use Mode Manager? The only thing you're doing that it doesn't support is two different Away modes. Add a simple rule to decide whether it should be Night and Away or Day and Away for that single case (add Away mode, and have Mode Manager flip to Away for all leave). Mode Manager would work for this without all of the gymnastics of this rule.

[neonturbo]

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.

[bravenel]

@neonturbo

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.

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.

Mode Manager would look like this:

And the rule would be this:

I don't know why your rule doesn't work.

[neonturbo]

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.

@bravenel

I don't know why your rule doesn't work.

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.

[bravenel]

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.

[neonturbo]

@bravenel

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!

[bravenel]

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.

[neonturbo]

Caught the lil bugger. First time I have been able to catch it. Stayed up late and I guess I got lucky.

Why the heck does it think that it is between sunset and 10 PM when the time on the hub and rule shows midnight?

Uh, no it isn't between those times! Naughty hub!

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.

Summary

The same course of events shows in Hub Events like in a previous post, but here is the matching screen capture to the log in this post.

Summary

[Hasty1]

I am going to guess this has something to do with how the sunset time is calculated. If so I hope @bravenel and team can get it fixed!

[neonturbo]

@Hasty1

how the sunset time is calculated.

Maybe, but only at midnight exactly?

Edit: it could be, but wouldn't sunset time affect more than just that one particular moment in time?

[njanda]

Nothing external coming in that might be changing Mode, like IFTTT ???

[sburke781]

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.

[jrfarrar]

I'll bet right at midnight sunset is now "yesterday's" sunset...which then makes between sunset and 9:59pm true.

[starcom]

You maybe right. I believe Sunrise is set at midnight, Sunset is not; likely set at Sunrise event..

[bobbles]

@starcom

I believe Sunrise is set at midnight,

I thought Bruce has said in the past the surise is set at 00:10 not at midnight.

[sburke781]

If sunset was not set at midnight I would expect the same behaviour at 12:03am as well.... which I don't think is what is happening.

[neonturbo]

@njanda

Nothing external coming in that might be changing Mode, like IFTTT ???

No, not even installed.

[neonturbo]

@sburke781

Perhaps try and offset the rule so it doesn't run at exactly midnight,

I have tried prime numbers like I mentioned above (7, 13 minutes) and it still seems to somehow hit midnight.

@sburke781

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.

Well I could, but it would be nice to figure out why it is happening. I doubt this is intended behavior.

@sburke781

I would expect the same behaviour at 12:03am as well.... which I don't think is what is happening.

It is not. Only midnight.

[starcom]

bravenelStaff

May 11

@ogiewon

I believe Hubitat will not schedule a future Sunrise with offset event until midnight each day.

This is true only for the day the setting is first setup. After that, sunrise for the next day is sent at sunrise (sunset for next sent at sunset).