Disable program - without terminate

[larryllix]

@Michel KohanimThis would be  handy in some instances  for programs to be able to self- disable further triggers without terminating themselves. This would enable programs to disable triggers and still process Wait timers and users knowing they will be atomic and complete their mission.

This is currently done and commonly using two programs with the second program disabling the first one. Of course the synchronisation can get out-of-whack when power outages, reboots, or other programs interrupt the process and the original does not get re-enabled.

If
    control switchlinc is switched on
Then
    Disable self ( disable program without terminate)
     Set lights to On
     Wait 1 hour   <----- guaranteed delay with no interruptions or retriggers
     Set lights off
     Enable self

Else
    ----

[kclenden]

6 hours ago, larryllix said:

for programs to be able to self- disable further triggers

Since there are only a couple commands that allow interruption, perhaps your goal could be accomplished with two new commands:

• Uninterruptible Wait
• Uninterruptible Repeat

These might be easier to implement than changing how the current "Disable Program" works.

[larryllix]

2 hours ago, kclenden said:

Since there are only a couple commands that allow interruption, perhaps your goal could be accomplished with two new commands:

• Uninterruptible Wait
• Uninterruptible Repeat

These might be easier to implement than changing how the current "Disable Program" works.

That could get some into trouble with things like Repeat 999,999 times but the "uninterruptible" may just not be the exact word for it, yet.
I would think we would still want it to be interruptible (by the system) but just no triggers to the If section. The system still has to multi-process.
That also implies that other programs could not use "Stop" and "Run Then" to force overrides.

[apostolakisl]

12 hours ago, kclenden said:

Since there are only a couple commands that allow interruption, perhaps your goal could be accomplished with two new commands:

• Uninterruptible Wait
• Uninterruptible Repeat

These might be easier to implement than changing how the current "Disable Program" works.

I had made a similar type request years ago.  It might be better named "wait - protected".  It would be protected from it's own "if" section.  Otherwise, a different program or a manual intervention could still stop it.  It would actually be exactly the same thing as "disabling" a program where the program keeps running instead of terminating.  

Or you could call it "atomic wait" where the wait no longer is an atom splitter.  In this way, the things on each side of the wait are joined into a single atom and execute to completion unless there is a "stop" command executed.  

[kclenden]

5 hours ago, apostolakisl said:

It might be better named "wait - protected".  It would be protected from it's own "if" section.

15 hours ago, larryllix said:

I would think we would still want it to be interruptible (by the system) but just no triggers to the If section.

Agreed.  I imagined that the "Wait" would basically give up all OS time slices until the desired time arrived or the desired length of time expired.  In the Repeat case, I imagined that each time the end of the Repeat section of code was reached, it would give up control to the OS so that other things could be accomplished before the OS ran the Repeat code again.

15 hours ago, larryllix said:

That also implies that other programs could not use "Stop" and "Run Then" to force overrides.

Yeah, that's a problem with calling it "Uninterruptible".  Certainly not what I imagined or would want implemented.  Unfortunately, it seems like whatever you call it there will be potential for misunderstanding what it actually does.

[Michel Kohanim]

All,

I think uninterrupted wait and repeat would accomplish the same (as @kclenden suggested).

With kind regards,

Michel

[jfai]

Instead of trying to find elusive intuitive statement names, why not make the intent clearer by adding an options argument, e.g. 

WAIT 10 minutes, unconditionally

[larryllix]

7 hours ago, Michel Kohanim said:

All,

I think uninterrupted wait and repeat would accomplish the same (as @kclenden suggested).

With kind regards,

Michel

But I think it should be interruptible by other programs, just not it's own If triggers. There needs to be some way to stop or cancel the program externally. What would the external program do if processing a disable or stop Program X when Program X is processing a Wait Uninterrupted. It must only be an internal lock-out only.

The parameter "self" could be used for other constructs in ISY but may not be descriptive enough.

@kclendenlater admitted he wouldn't want to see that phraseology. I think that was based on being too long and clumsy wording. I agree. There must be a shorter and yet concise phrase.

Wait Uninterrupted should give more usage options than Disable Self,  when triggers are still desired, but just not during that Wait Uninterrupted period.
We can't have ISY go multi-tasking dead while a Wait Uninterrupted 15 minutes is being processed though,

What about the Repeat?
Can we apply the same thing to Repeat Uninterrupted while x>y ? That would further the need  NOT to block external Program Stops or Disables.
Repeat Uninterrupted 9,999,999 Times needs some method of aborting it, for ISY's sake.

[Michel Kohanim]

@larryllix,

Thank you very much for the details. I don't want to say that this is not useful and I don't want to say 'but'. So, I am left with a dilemma of how to answer. In short, based on everything we have on our plate, at the moment, this feature is way down on the list.

With kind regards,
Michel

[HABit]

What about just a "Disable IF Trigger" statement (or call it whatever everybody wants), that prevents the event/trigger logic from re-evaluating the Program IF clause. That takes care of everything (unless I missed some context here). The Program could automatically "re-arm" the IF evaluation, after it terminated. This would allow what @larryllix wants, and could allow an external program to Stop, or Run (if/Then/Else) the disabled IF Program, as well.

[apostolakisl]

40 minutes ago, Michel Kohanim said:

@larryllix,

Thank you very much for the details. I don't want to say that this is not useful and I don't want to say 'but'. So, I am left with a dilemma of how to answer. In short, based on everything we have on our plate, at the moment, this feature is way down on the list.

With kind regards,
Michel

Probably . . . well no, I think for sure, the biggest PITA programming ISY is having to write multiple programs with disable/enable stuff just so you can stop the old "re-trigger" problem.  I think it has to be the single most common reason for a newbie to post a program that "isn't working".  While new features are great, I think this may be an old feature that might want to have a solution sooner than perhaps some of the new stuff.  

Though I don't agree with the idea that a wait/repeat becomes completely uninterruptible.  I think it should work exactly the same as a "disable".  It simply blocks a self-trigger.  I would still want to have the option to purposefully end a wait/repeat from another program.

[larryllix]

4 hours ago, SeeGreen said:

What about just a "Disable IF Trigger" statement (or call it whatever everybody wants), that prevents the event/trigger logic from re-evaluating the Program IF clause. That takes care of everything (unless I missed some context here). The Program could automatically "re-arm" the IF evaluation, after it terminated. This would allow what @larryllix wants, and could allow an external program to Stop, or Run (if/Then/Else) the disabled IF Program, as well.

@Michel Kohanim @kclendenI like this idea even better. I think that gives better control of things people want to be controlled. It also would be more clear what function it performs and a smoother, more compact syntax.
@apostolakisl elaborated above, on this same syntax style with further explanations of why it is needed, that syntax.

The problem with the  current Disable is that it also stops any program it is used on. We need a DisableOnly Program  XXXX as a simple extension of what we already have. Then it could be used on any program within  itself, or externally from other programs.

EnableOnly Program XXXX (the reciprocal) should not be needed, as Enable Program XXXX should work for both Disable styles.

Auto EnableOnly, at the end of a program will not work as a separate program may be wanted to re-enable a disabled program.

eg.

ThisProgram [enabled]
If
    control switchLinc is switched On
Then
    DisableOnly Program ThisProgram         <---------- no stopping. eliminates dual programs required now.
    Set Light On
    Wait 2 minutes             <----------- guaranteed to not be interrupted and always times out
    Set Light Off
    Enable Program ThisProgram        <---------- works for both disable styles, can be used from other programs
Else
    ---

 

[apostolakisl]

And there it is again!  Newbie with same issue.