You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am considering introducing the following options for running scenes and activities within Reactor. Before diving in, a bit of background: currently, Reactor runs activities as fast as Vera will take them. If an action uses the 'run' tag exclusively, it is run "in line," meaning Reactor (or really Luup) waits for the action to complete before moving on to the next step. If the action uses a 'job', however, Luup submits the job to its job queue and runs it later (Luup's scheduling algorithm is not documented, but appears to be FIFO). If an activity contains a delay, the delayed actions are detached to a separate task in Reactor, and Reactor immediately moves on to other business. The delayed actions are then run at the scheduled time with the same heuristic as above. By example, if a Reactor sensor has three eligible group activities, they will run sequentially at the end of condition evaluation.
Now then, the options:
Detach -- the entire activity would be run as a Luup job. This would not change Luup's scheduling of the actions within (run vs job, etc.), but it would affect Reactor's performance in getting to its next evaluation or starting its next group activity: this would reduce the time required by Reactor to start group activities. Using the above example, if the first of the three eligible group activities is long-running, and the second is time-critical, the second will, currently, always be delayed by the first, perhaps to its detriment. By being able to "detach" the first group activity, the second group would be able to execute almost immediately, and the actions of the first group will run as soon as the Vera/Luup scheduler allows.
Serial -- If an activity contains an action that Luup runs as a job, Reactor would wait for the job to complete. If within an activity, the successful completion of a later step is dependent on an earlier step, and the earlier step runs as a job, the job may not run at all prior to the later step being run. By turning on the "serial" option, Reactor would see that the action was queued as a job and wait until the job completes. Additional options would allow a timeout (Reactor would continue the activity if the timeout was met before the job signalled an exit status), and continue-on-error, by which the user could specify if the remaining actions in the activity should execute if a job fails.
The text was updated successfully, but these errors were encountered:
I am considering introducing the following options for running scenes and activities within Reactor. Before diving in, a bit of background: currently, Reactor runs activities as fast as Vera will take them. If an action uses the 'run' tag exclusively, it is run "in line," meaning Reactor (or really Luup) waits for the action to complete before moving on to the next step. If the action uses a 'job', however, Luup submits the job to its job queue and runs it later (Luup's scheduling algorithm is not documented, but appears to be FIFO). If an activity contains a delay, the delayed actions are detached to a separate task in Reactor, and Reactor immediately moves on to other business. The delayed actions are then run at the scheduled time with the same heuristic as above. By example, if a Reactor sensor has three eligible group activities, they will run sequentially at the end of condition evaluation.
Now then, the options:
The text was updated successfully, but these errors were encountered: