Regarding predicates, they are constantly evaluated (well, more accurately, as I understand it, each time a potential trigger event fires). If, at that time, the predicate is true, the trigger happens and the rule fires. If, at that time, the predicate is false, the trigger event is dropped.
Bruce (@bravenel) discussed startup issues before, and, after a lot of thought, I came to understand and agree with his position.
If you think about it, with the variety of configurations of hubs, there's no way that a standard under-the-hood operation works for startup. You have to think about how you have your Rules designed, and just run through an appropriate set of actions in a systemStart rule. If you design the systemStart rule appropriately, it can handle the case of restart or reboot at any time of day.
For example, I do a refresh on all the Ring Extender Gen 2 devices because the "switch to mains from battery" event has probably been dropped if it's a reboot after extended whole home power fail. The Ring Extenders will come up before the Hub reboots. While the Hub is on a UPS, you really don't know in advance how long the power fail will be, and, at least in our city, the power may flap up and down several times while it is going down, and the same may happen when it comes back on. So, I've got a shutdown rule (triggered as Ring Extenders switch from mains to battery) that waits a few minutes before deciding to shut the hub down cleanly. In addition, occasionally someone (not me) might knock a Ring Extender out of the socket while cleaning or moving furniture. To handle this, I've got a voting rule that only starts the shutdown process when at least 5 of the 6 Ring Extenders have seen power failure, and which recovers when Ring Extenders come back online. If you think about the concurrency issues, designing such a set of rules is a bit complex because you can have multiple "fail / power up" triggers happening at near the same time. The only thing you can count on (hopefully) is that the events are queued in the order they occur. So, another thing my systemStart rule does is to initialize all the variables in this voting set of rules.
Another thing that my systemStart rule has to do is to get the Mode in the correct state. Basically, you have to run through all the ways that your Mode might be set.
Then, you have to replicate the actions, as you note, of turning lights, etc., on/off if they are controlled by time events or sunset/sunrise.
Then, I've got a complex set of rules that monitor our Litter Robot (controlled by Dominick Meglio's (@dman2306's excellent driver port)), turning the Under Vanity lights green, yellow, red depending on the level of litter in the Litter Robot drawer (using the concept outlined in Jared Zimmerman's (@jared.zimmerman's) post in the forum), and that starts flashing the Under Vanity lights when the Litter Drawer Full indicator is triggered. All of that state information has to be reset correctly because the cats might have been pooping while the power was off, etc.
I just don't see how this could be done any other way than have your systemStart rule make no assumptions and run down how your home should be configured on a restart or power up.
