I think an importance flag may be of value to me. Specifically - like css and the '!important' flag, or like windows 'startup dependencies' routines or a firewalls rule priority, I've recently found that my hub is very loosey-goosey on the rule order that runs at startup.
I was thinking that a toggle on/off switch in rules would be useful. During startup, rules that are flagged for priority at startup get placed at the head of the line before other normal rules run. Maybe even run these rules as part of the Hub startup prior to the web gui coming up.
Obviously an advanced setting but it could resolve some troubles I recently needed to get around.
I recognize my idea doesn't help completely - if it was implemented I can see someone just ticking all their rules as getting flagged as !important then one would have the same problem all over again just with a smaller pool of rules. It's just an idea.
If you have many rules that run at system startup and need them to run in a defined order, wouldn’t you have more control over the exact order in which they run by building that logic into each rule?
As you’ve already pointed out, as soon as more than a single rule is flagged as “important,”
If there's an absolute order in which your rules need to execute at startup, set only the first one to actually start at "systemStart", and then have that first one end by doing "Run Rule Actions" for the second, the second end by doing the third, and so on.
I have only one rule that is triggered by systemStart. It waits for the CPU load to be under a threshold before running the first rule. There is a Boot Status hub variable that shows the current rule or group of actions the rule is executing. Each time the rule could cause a significant CPU load, the rule waits until the CPU load is less than a threshold.
At the end of the boot rule the Boot Status variable is set to done and the time-based rules are started.
I use the Boot Status = done as a Conditional for the triggers of the first rule in the control sequence for the shades and for each event-based condition monitoring rule.
This is my way of letting the hub quickly run the rules that it needs to start and in the proper order.
I appreciate the suggestions - in my case I don't have 'startup' rules per se. I just have rules. Since they fire off randomly at startup, the order of them running at startup I've only recently discovered is important - during normal operation it isn't an issue. I wrote my own mode manager and have other rules that trigger based on mode such as home, away or asleep. it is those that get badly affected during startup until things get sorted.
Anyways. it was just another idea to offer up. I already have to much complexity imho - between rules, apps like Room Lighting, and virtual devices + updating user apps, firmware updates, hub updates - its has become nearly unmanageable as it is now. Yes, it's flexible, I just wish HE could take some of the load off ME managing my hub, not me doing more to make my hub work!
There might be opportunities for you to simplify the complex setup you have created, which could obviate the need to add platform-level features for all users (thereby increasing the potential complexity of using the hub for everyone else).
Some examples of the kinds of rules and the numbers involved may help provide some context to the kind of automation you are trying to deal with, and help progress ideas in this space.
As much as I liked some of the earlier posts that talked about introducing changes into the rules themselves (using existing features), the more I think about it the more I feel that a coordinated approach may be more appropriate, particularly if you have a number of rules that you want to control in this way. To me it would feel a little disjointed to have the single concept of setting rule priority or ordering managed within each rule. A centralised (likely custom) App that could somehow initiate the rules in the correct priority / ordering would allow, I think, easier visibility of this aspect of your setup compared to separate configuration spread across each of the rules involved.
The Schedule Manager App @John_Land posted has the essence of what I am getting at in that it can present an overview of the setup that is managed in a single view / app. It may introduce a layer of abstraction with trigger devices, which may be required in the end. Hopefully you get the point I am trying to make in centralised vs decentralised configuration.
thanks - I'll take a look at the Schedule Manager App sometime - it sounds like it could be impactful and your voice and thoughts have strength with me.
I'm having difficulty understanding the issue. When a hub reboots, no rules should start unless they are triggered, either through Location event: systemStartup, Time, Sensor (motion, leak, etc.) or manually. You can control the first and last, the others not so much.
