Order Of Execution On systemStart... Questions

I am curious,
On systemStart availability in RM4, is the system fully functional and on line?
When the system has started, has Mode Manager run and configured the mode prior to RM4 becoming active and running rules?
How would MM be affected by the system being in "Away" mode, when set to configure modes by time of day, when it was re-started? {E} Set to not change on "Away"
Would it return to the away mode, or be set to the time settings in MM?

{EDIT} or is it possible to run the logic of MM from RM4? (to set the proper mode)

Thank you for your help.

No Hope,Eh?

There is always 'hope' :wink:

You bring up a good question...which most of us don't know the answer to. Personally, I just keep my Hubitat hubs plugged into a UPS so they are always up and running and basically never miss a scheduled event.

Mode Manager probably just schedules its time of day actions, like most every other app. I do not know what happens if the hub is down during the time one of these events is supposed to fire, and then later comes back online. @bravenel could answer this best.

I also do not know whether Hubitat Apps have a startup order or not. My guess is they basically all start up at the same time after a hub restart. There is a location event for hub startup that can be used as a RM trigger if you need to make sure things are set correctly after a restart.

It won't do retroactive operations, meaning, the missed schedule will be rescheduled for next time, at least that is my experience with it

Mode Manager does not "catch up" with anything that might have happened during hub down time. Use a rule to set the mode appropriately on hub startup.

1 Like

Here is a rule how I manage my modes:

vEvening is a switch that get's set either at 7pm or at sunset-30, whatever comes first, but I use that switch also some other place..

Does this have holes, yes! But only holes I can live with. You can always make it more complicated. One item that makes it easier for me is that I don't use an "Away" mode and there is no presence involved

Here's mine:

Beyond that, I use Mode Manager.

2 Likes

See @woodsy - there is always hope! :slight_smile:

1 Like

All I was asking was this.

I ran into this problem recently. I had a hub reboot right around the time of my transition to night mode. I don't use mode manager, all in Rule Machine. So, in my System Start rule, I just fire off the actions for those rules that take place periodically. You don't have to put the functionality into the startup rule, you can call the others from that. Just don't go crazy and call EVERY rule or something like that....then you're going to get a lockup. I've also found that it helps boot up if I delay those actions by a minute or two to let the hub settle itself.

I do find it interesting that you're using "Waits" for an event like a mode change. I find this to be the most problematic. If you have a hub reboot at any time it's going to cause you to miss your mode change, not just if your hub is off during the switch. You might find it less problematic to have the rule trigger at sunrise rather than waiting for sunrise. Similarly, rather than waiting for 9:30 pm, have the rule trigger at 9:30 PM. Right now, if you reboot your hub at all during the day, nothing is going to work correctly because all those waits are going to be gone when the hub reboots.

Simple reply, to a simple question, with as much detail as I could provide.
Thanks, @bravenel.

Yes and no, the way the rule flows helps to get the waits get reestabilshed at systemStartup. I reboot my hub quite often especially during beta testing and I never have to worry about it. The only time it really doesn’t work is if I reboot the hub when it is in evening mode. At that point it wouldn’t go to night mode and would wait for the next morning to go to day. However, for me, that really never happens unless there is a power outage which is a whole different scenario.

It has been pretty stable for me with the waits.