HS4 4.2.16.7 is ready for Beta testing!

[rjh]

Scripts can access plugins so I think the script needs to run after everything else has been started. Sounds like you need a "pre-startup" script, something that runs before plugins are started. The init code before plugins are started does not take much time, most of the startup time is starting up scripts.

Note that there is an option on the Labs tab in Setup that allows plugins to start in the background. This might do what you want. If a plugin depends on another plugin, this might not work unless the plugin waits for its dependent plugin to start. Not sure there are many plugins that depend on other plugins.

I'm thinking this only effects Linux versions but I could be wrong.

rjh It would also be nice if the Startup script was run first, or at least before loading plugins.
Mine takes about 14 seconds from actual startup to when the script runs. I can actually watch it running with the last startup time and then the script runs and it restarts at 0.

[Demusman]

Scripts can access plugins so I think the script needs to run after everything else has been started. Sounds like you need a "pre-startup" script, something that runs before plugins are started. The init code before plugins are started does not take much time, most of the startup time is starting up scripts.

Note that there is an option on the Labs tab in Setup that allows plugins to start in the background. This might do what you want. If a plugin depends on another plugin, this might not work unless the plugin waits for its dependent plugin to start. Not sure there are many plugins that depend on other plugins.

The only reason I need any of the startup/shutdown scripts is because of UltraGCIR3 plugin. It sees sensors as on when they're off and off when they're on.
So at once the plugin loads it sees the sensors as "active" ( I reversed on/off in the device itself ) which triggers events.
With the startup script taking 14 seconds to run, all the plugins are already loaded causing my issue.
The workaround I used was the shutdown script so if you can get that working I'd be good.
Would like to have the plugin fixed but I don't think that'll happen.

but the user will need to add their own delay if they are doing something that takes longer than that. Lots of things get queued so there is really no way to know for sure if actions started by a script are finished.

Not sure I understand this, add a delay to what? Are you saying we can delay the shutdown somehow?
I don't see how delaying our script is doing the right thing here?

[racerfern]

Odd this never came up before.

There are soooo many things that need fixing, this is a small piece of fruit at the very top of the tree. That's how I see no one including myself have never said anything.

[rjh]

The delay is in reference to your shutdown script running events, or possibly other script calls. Some of the calls get put in a queue so when the script returns the action does not get a chance to run. This is because the system immediately shuts down when the script finishes so the queue does not get processed. Since you are calling runevent the event action may not get a chance to run. So, in your script add a hs.waitsecs(5) as the last line. This may fix the issue you are seeing. I have put in a request to fix this in the next update so a delay will not be needed.

Not sure I understand this, add a delay to what? Are you saying we can delay the shutdown somehow?
I don't see how delaying our script is doing the right thing here?

[Demusman]

The delay is in reference to your shutdown script running events, or possibly other script calls. Some of the calls get put in a queue so when the script returns the action does not get a chance to run. This is because the system immediately shuts down when the script finishes so the queue does not get processed. Since you are calling runevent the event action may not get a chance to run. So, in your script add a hs.waitsecs(5) as the last line. This may fix the issue you are seeing. I have put in a request to fix this in the next update so a delay will not be needed.

I don't think it's the delay that's causing this problem. Events just aren't running correctly. I say that because sometimes they do run.
See here:

The shutdown event did run 2 hours ago. But a minute and a half ago it didn't. This is with a 60 second delay in the script.
That's what I meant above, adding a delay to the script isn't stopping the shutdown. Sure it delays the final shutdown but the other processes involved in the shutdown are still running, aren't they?

I think having the shutdown script run first, and waiting until it finishes to 'start' the system shutdown may be the way to go.

[Walnut2000]

rjh randy TC1 - I've been out of circulation, so apologies for not replying to you all sooner, wrt post #34 - "an event that runs multiple other [conditional] events"

My requirement is exactly the same as TC1's, as he outlined in post #37 - "truly single thread execution when needed" because, like him, "I use a lot of Run Event (with test for condition true) actions to compensate for the fact we don't have conditional logic at the present. It's a kludge."

The wait actions in the test events were simply used to check if the second event triggered immediately after the first had started or after it completed.

The conditional sub-events do not typically include, or need, a wait statement like that. They just have a number of actions that need to complete before moving to the next set of actions in the main event. One of those actions might be to speak something using the HS speech client with "wait for speech to finish" set, but I don't know if "A quick fix would be to run a simple script that does the wait" would help with that?

Randy understands what we're trying to achieve and, as he suggests in post 36, a possible solution is "an option "Wait for Event to complete prior to running the next Action" on each "Run another Event" Action, not to just "Run Events in Order"" (although I confess, I was operating on the misunderstanding that "Run Events In Order" would wait for the event to complete before moving on rather than just triggering then in the chosen sequence. Randy's clarification is much appreciated)

However, as TC1 suggests in post 37, "Having the ability to have conditional logic at the Main Event level, with Run Events in order, would eliminate most of my sub-events needs." With conditional logic at the main event level I'd probably move all the conditional sub-actions into the main event and eliminate a lot of those sub-events. With all the logic in the main event, rather than spread across sub-event conditions, the events would be much clearer and tracing problems would be easier, so that would be my ideal solution.

On reflection, I'm using conditional events like a subroutine in a conventional programming language and expecting it to execute then return control to the main event. I don't know, but it feels like this could have a bearing on any eventual implementation of conditional logic in HS4 too. Will "conditional logic" in make HS4 feel more like a programming language, and will new users assume that (eg) any sub-events within an IF block of actions will behave like a subroutine and complete within that block of logic? I'd certainly appreciate some clear documentation on how that would work before I start changing stuff.

I hope that helps clarify where I was coming from, and many thanks for your help.

Ok, I see. It's only the wait action that will cause an event to run in a new thread so it runs in parallel with the other actions. A quick fix would be to run a simple script that does the wait. That would cause the events to run in order and honor the waits. An option on the wait action is probably the best way to allow the user to select whether they want to action to thread the entire event.

[rjh]

I am pretty sure I see what the problem is. There is a race condition with running events in that it could run the event you specified but if the timing is just right the event processing could exit before processing the queue. So adding a delay will not help.

There is a way you can test this though. Try to restart the system from the tools menu. That restart will not shut down the event processing. See if the script runs ok each time.

I don't think it's the delay that's causing this problem. Events just aren't running correctly. I say that because sometimes they do run.
See here:

The shutdown event did run 2 hours ago. But a minute and a half ago it didn't. This is with a 60 second delay in the script.
That's what I meant above, adding a delay to the script isn't stopping the shutdown. Sure it delays the final shutdown but the other processes involved in the shutdown are still running, aren't they?

I think having the shutdown script run first, and waiting until it finishes to 'start' the system shutdown may be the way to go.

[Demusman]

Try to restart the system from the tools menu. That restart will not shut down the event processing. See if the script runs ok each time.

That's the way I always restart and has been the way I've been testing this.

[rjh]

Ok, I will have to investigate some more.

That's the way I always restart and has been the way I've been testing this.

[rjh]

Ok, I will run more tests here.

It looks like the security offset is still not working. The event fired at 3:17 every day.

1/22/2023 3:17:00 PM HomeSeer Event Event Trigger "HomeSeer Demo securityOffset"
1/21/2023 3:17:00 PM HomeSeer Event Event Trigger "HomeSeer Demo securityOffset"
1/20/2023 3:17:00 PM HomeSeer Event Event Trigger "HomeSeer Demo securityOffset"
1/19/2023 3:17:00 PM HomeSeer Event Event Trigger "HomeSeer Demo securityOffset"

[rjh]

Sneak preview, conditional actions coding is done and we are doing some testing, so you will have it soon! We need to get 4.2.17 posted (scheduled for Feb 7th), then right after we will post a beta of 4.2.18 with the conditional actions.

There you go!



Just kidding. I am anxious as well.

[randy]

Yesterday it changed. It was the 8th run.

[randy]

Sneak preview, conditional actions coding is done and we are doing some testing, so you will have it soon! We need to get 4.2.17 posted (scheduled for Feb 7th), then right after we will post a beta of 4.2.18 with the conditional actions.

We’ll anxiously await

[TC1]

Sneak preview, conditional actions coding is done and we are doing some testing, so you will have it soon! We need to get 4.2.17 posted (scheduled for Feb 7th), then right after we will post a beta of 4.2.18 with the conditional actions.

Be still my heart...

[spud]

Yesterday it changed. It was the 8th run.

Does your HS4 system always run at midnight? This is the time at which the security offsets are supposed to be reset