HS Startup script.

[Wadenut]

I have a logical conundrum. A problem I've been tracking for some time has led me to this question.

In HS3 settings, we have "Power Failure Recovery settings" --> "Do not allow scripts to run during recovery"

The script Startup.vb 'should' always run during startup, and does seem to regardless of this setting, however I have occasion to run another one time script within Startup.vb to initialize some hardware.
I've noticed sometimes my script hasn't been running and I believe the above option being set may be the cause.

Are there any consequences to NOT setting this option so that scripts other than Startup.vb are allowed to run during startup?
I would think rather than HS preventing scripts running, that preventing events running during startup would make more sense, or is it the case that HS does this by default?

[Krumpy]

My understanding is that the startup script will always run. The option that you refer to is part of the recovery processing which occurs some time after HS has started.

i would think that they are two different subjects.

[Wadenut]

My understanding is that the startup script will always run. The option that you refer to is part of the recovery processing which occurs some time after HS has started.

i would think that they are two different subjects.

Yes, it is understood they are two different things.
The question is:
1. Do events process during the startup period, or are they inhibited during startup regardless of the setting?
2. Is there a further consequence to allowing standalone 'scripts' to run during startup from the startup.vb script? Generally, scripts aren't executed other than by events, or in this single case as a function called within Startup.vb.
If events aren't running during Startup, there's not a problem with setting the option False, however if Events do run during this time, there could be issues raised which I'd need to keep in mind.

I could get around all this within Startup.vb by reading the options from settings.ini and delaying execution of my initialization script, but it would add quite a bit of complexity to the startup.vb script. Alternatively I could add a ridiculous hs.waitsecs to startup.vb, but there are other scheduled events that depend on the initialization having been fully completed. Without the initialization having been properly completed, those events can, and do have unpredictable results.

[Wadenut]

I think I've found a fool proof solution.

The problem I had was an event/script which processes data from a couple of serial ports. If the ports had failed to initialize in Startup.vb, the script would error out. This happened sporadically.

Rather than depending on Startup.vb to run my initialization, in the script that reads the port, I'm now using...
If hs.CreateVar("InitializeSerialPorts") = "" Then InitializePorts("16,17")

If the variable exists, the function returns an error so I skip initializing the ports.
If it returns an empty string, the variable hasn't been created yet, so go ahead and initialize the ports.

Genius. Sometimes I scare myself.

[randy]

I have a logical conundrum. A problem I've been tracking for some time has led me to this question.

In HS3 settings, we have "Power Failure Recovery settings" --> "Do not allow scripts to run during recovery"

The script Startup.vb 'should' always run during startup, and does seem to regardless of this setting, however I have occasion to run another one time script within Startup.vb to initialize some hardware.
I've noticed sometimes my script hasn't been running and I believe the above option being set may be the cause.

Are there any consequences to NOT setting this option so that scripts other than Startup.vb are allowed to run during startup?
I would think rather than HS preventing scripts running, that preventing events running during startup would make more sense, or is it the case that HS does this by default?

To answer your initial question I think I tested and proved that "Power Failure Recovery settings" --> "Do not allow scripts to run during recovery" stops only scripts that are called within power fail recovery Events from being run, all other actions will be run. Additionally scripts called from your startup script and scripts from Events triggered other than by power fail recovery will still be run.

[randy]

Yes, it is understood they are two different things.
The question is:
1. Do events process during the startup period, or are they inhibited during startup regardless of the setting?
2. Is there a further consequence to allowing standalone 'scripts' to run during startup from the startup.vb script? Generally, scripts aren't executed other than by events, or in this single case as a function called within Startup.vb.
If events aren't running during Startup, there's not a problem with setting the option False, however if Events do run during this time, there could be issues raised which I'd need to keep in mind.

I could get around all this within Startup.vb by reading the options from settings.ini and delaying execution of my initialization script, but it would add quite a bit of complexity to the startup.vb script. Alternatively I could add a ridiculous hs.waitsecs to startup.vb, but there are other scheduled events that depend on the initialization having been fully completed. Without the initialization having been properly completed, those events can, and do have unpredictable results.

I have not tested if normal Events will be run if triggered during power fail recovery, but power fail recovery occurs very quickly, since it will only run time triggered and marked for power fail recovery Events that were missed during the time HomeSeer was down (within the timeframe in General>Number of hours to catch-up). Even dozens of affected events would run within seconds. Even if normal Event processing is suspended, they must be queued as my system always runs all Events, even one called in my startup script, even when power fail recovery was used. I no longer use power fail recovery, instead opting for cleanup events that will get lighting, power and other controls setup for the time of day HomeSeer is started.

[drhtmal]

The user guide at https://homeseer.com/support/homeseer/HS3/HS3Help.pdf has the following info on Power Failure Recovery. The do not allow scripts to run during recovery seems a little vague to me. My interpretation is that it prevents the function hs.TriggerEvent from running the event being triggered by the function.




There is also a check box in event options for each event. This options includes the event in the Power Failure Recovery processing. It is disabled by default.



Here is how I think this works or at least how I would do it if I were writing HomeSeer. Perhaps someone from HS can comment on how it is actually done.

1. Power is lost and HS is not shutdown properly. HS know this because the shutdown command was not called.
2. Power is restored and HS begins to initialize. HS checks if it has been shutdown properly. HS probably has a bunch of stuff it does after an unsuccessful shutdown that it is required to do.
3. At some point it runs the Startup script. If the startup script calls any events via and "Do not allow scripts to run during recovery" is enabled those events are not run.
4. At this point HS has been initialized and is running.
5. HS starts the power failure recovery after waiting x seconds for the delay, this includes any event catch up.

[Wadenut]

drhtmal You're quite right, it is quite vague.

My experience has been that, in this particular case at least, the script called within Startup.vb would run "sometimes", but not 100% or the time. There happens to be a Writelog at the beginning of the called script I'd added to troubleshoot, and recently noticed from time to time is not written to the log at all. If the script does run, that logged event is of course always present.

Nonetheless, my CreateVar solution solves the problem completely and doesn't require that the script run from Startup; it can wait until the event engine starts processing events normally.
Naturally, there is the fact I hadn't mentioned up until now, that I'm using this function in both HS2 and HS3. HS2 definitely was a problem, and I've seen evidence from time to time in HS3 as well that made me suspicious enough to spend time on it today.

The solution works in both versions of HS without modification at the cost of only a few bytes in memory.