Gradually turn on lights.

[vezinpi]

Hi all,

I am running MSR along HA on a RPi-4. MSR is talking to HA as well as my vera plus. Following a power outage MSR is showing a bunch of error messages complaining about entities not being available along with a yellow triangle besides my rules. My guess is that upon power restoral, MSR becomes ready before vera or HA.

Question:

• Assuming that the devices/system used by MSR becomes fully functional, will the rules still properly works or the initial error and the yellow triangle means that they are not operational?

I underatand that the ideal situation would be to install UPS (several in my case) on everything related to automation. Falling short of that, I was wondering if there would be a benefit to have something in the MSR configuration to pause its startup, providing dependencies enough time to become ready. This would prevent a bunch of (unnecessary) error message following a power outage. In my case, following a power outage, waiting a couple more minutes is not really an issue.

Tx

[toggledbits]

Reactor starts pretty fast, but it does wait up to 60 seconds for all configured hubs to come ready. If you're getting warning triangles on a reboot, it means either Hass or Vera (or both) are taking longer than 60 seconds to start up.

However, Reactor keeps trying to connect to your hub, and once the hub comes up, the update of device states will cause any related rules to be evaluated at that time. The only trouble you might run into, I think, is if you have a rule that starts a (rule-based or global) reaction that needs to run against both controllers when only one of them is ready -- the rule will change state and start the reaction, but the reaction may not be able to manipulate all of the devices in that moment. When the delayed hub finally comes ready, the rule may or may not evaluate again, depending on whether its conditions include devices on the delayed controller or not.

So, you'll get warning triangles, but Reactor will recover... but you can still have issues depending on your rules/reactions.

There is a configurable startup delay available, however. If you set startup_delay in the engine section of reactor.yaml (your configuration file) to a >0 number of milliseconds (1000 = 1 second), then Reactor will pause during startup and give that much more time for the controllers to come up.

[vezinpi]

Hi Patrick,

Thanks for the quick and very exhaustive answer. It does explain the startup behaviour very clearly. As for the startup_delay, why am I not surprised that you had already something up your sleeve... This is great I will give it a try.

Thank you for all your good work.

[toggledbits]

As I was explaining it to you, I realized that I wasn't very happy with my solution. Two problems I see, that I will fix in a future build:

1. startup_delay is a fixed time that is spent no matter what. Even if all of the controllers come up ready, the full length of the delay is expended. I suspect most of the time, you really just want to wait for all the controllers to be ready, and then get on with it as soon as possible, so what you really want is to have the controller wait (60 seconds) be configurable.
2. The controller wait isn't configurable. It's a fixed 60 seconds, which wasn't very forward-thinking of me at all.

In a future build, startup_delay will continue to do what it does, but startup_wait will be added control the amount of time the engine waits for all controllers to come ready. If you set startup_wait for 5 minutes and they're all ready in 90 seconds, then the engine will start after 90 seconds and get on with the business directed, so startup_wait is a maximum. In your case, you would then want to set a longer startup_wait, and remove startup_delay, so you get the best performance (fastest startup).

[vezinpi]

The startup_delay seems to be doing the trick for me but it is true that the extra delay is a bit anoying and inefficient when simply starting or re-starting MSR. Before seeing your answer I was thinking that the start_delay should only apply when an improper shutdown is detected (kinda equivalent to power loss) but your solution with the startup_wait is much better. I will be on the lookout for it.

Thanks again.