Uninterruptable programs?

[ergodic]

Writing another batch of ISY programs this afternoon I was puzzling over the problem that seems to afflict me, as well as more than a few of the posters on this forum.

 

Specifically, why ISY programming runs so counter to the way I think.

 

By far and away, the largest problem I see is simply that status changes effected by a program can stop it executing and cause it to be re-evaluated and restarted.

 

This one semantic leads to all kinds of baffling behaviors from all but the very simplest of programs. And the programming subterfuges required to work around this lead to some rather long debugging sessions and let me gently say 'baroque' sets of programs.

 

So I'd like to suggest something I think is relatively simple: an inheritable folder option I'll call "uninterruptable". When an uninterruptable program runs, it cannot be interrupted by a condition re-evaluation, unless that evaluation changes the true/false state of the program.

 

So, if a program is running it's "then" part, and does something or something happens asynchronously that causes the program's condition to be re-evaluated, and that evaluation is still true, the program continues on without restarting. Likewise for the (rarely-used) "else"/false.

 

The only thing I can see that should be able to interrupt an uninterruptable program is an explicit "run" from another program, or an explicit action in the UI. There might be some use for a "do not interrupt" option on the run statement - I truthfully haven't thought that out.

 

This flag would of course have to be optional since it changes fundamental ISY semantics. Although I can tell you personally that less than 1 minute after having it I would apply it to "My Lighting" and then tear out all the programming hair I've cooked up over the last couple of years to work around this. As would I suspect 99% of the rest of the ISY-loving population. Most of what I've looked at wouldn't be affected since I have to program it out anyway.

 

More to the point, I think this is much closer to how people intuitively expect programs to act. I can't really think of any instance where I've desired the current, interruptable behavior, and I seem to spend the bulk of my programming effors trying to defeat it.

 

I'm sure there are implementation issues I don't know about, and no doubt there are various other issues that have to be thought through. This may well not even be the best way. But something along these lines seems really imperative to me.

[Michel Kohanim]

Hello ergodic,

 

Yes, I do understand what you are suggesting and personally I think it's a good idea. The only problems I see are time/resource constraints on our side ...

 

With kind regards,

Michel

[Chris Jahn]

I understand the frustration, and we are looking at different solutions to the problem. The goal being of course; make it easier for you to do what you want to do.

 

One of the biggest complaints is having a program run based on status, only to have it interrupted when the program changes that status. For coming up with the best overall solution, the more concrete examples we get, the better.

 

 

... There might be some use for a "do not interrupt" option on the run statement - I truthfully haven't thought that out ...

 

I would guess that most programs that use a timer would not use this option. For example, take a program that switches off a light 5 min after you press a button to turn it on. In this case you would expect the 5 min timer to be restarted whenever you press the button (i.e. by restarting the program).

[jwagner010]

What a great idea. Simple (from users perspective) yet provides flexibility.

[ergodic]

Chris:

 

I think that's right.

 

(I first have to acknowledge honestly I didn't realize until reading your post that pressing an on button while the device is already on did anything at all, though as I think about it now it seems prefectly sensible.)

 

I did go through my programs this morning to have a look. The vast majority of timers I have in programs relate to motion or occupancy sensing of some sort. The programs reset when an on command is received. Most of them are in complicated sets, but here's a simple one that affirms your point:

 

If
       Control 'D/S Guest Bath: Shower Motion' is switched On
Then
       Stop program 'DSGB-Entry Motion On'
       Run Program 'DSGB-Set Room State' (Then Path)
       Wait  10 minutes 
       Run Program 'DSGB-Set Room State' (Else Path)

 

I wrote this of course understanding the current semantics. I would probably either rewrite something like this (more likely) or mark it "interruptable."

 

If you can tolerate a little more of my musing: the core of this problem to me has always seemed that trigger "events" and condition "tests" are all stirred together in the same testing pot when in fact they are conceptully (to the program-writer) entirely, 100%, totally, different things. And this, I believe, is the heart of why people seem to have so many difficulties writing and getting ISY program sets to behave the way they expect.

 

So if the ISY had a true if-then-else, separate from trigger conditions, then I think that would do job even better. I however fully appreciate this is a lot of development-making.

 

But as much work as I assume it would be, I'll tell you for myself I would 10 times over rather have this before something like, say, variables. As much as I'd love to have that feature, I'd still be dealing with the core programming frustrations, only with variables.

 

Another way at this might be to provide a few "non-interruptable" tests. For example a "Status"-type condition ("If Status ... Changes"?) that can't affect ongoing execution if it doesn't change. I'm not sure how that would play out in development or practice, mainly because I haven't thought it through.

 

Ahh, the advantage of being an armchair developer.

[Chris Jahn]

This would likely be part of any upgrade that we do for programs. As Michel had mentioned though, getting this done is based on time/resource constraints.

[sanders2222]

I was aware some of my programs would not fully execute, now I know that it happens, but where in the code? Debugging programs is difficult with existing tools. Why doesn't the ISY have a debugging tool that allows users to step through the code line by line to find the one that stops the execution. Most program compilers provide this option.

[apostolakisl]

I think you can get around this problem by putting your "if" statements and "then" statements into two programs.

 

The first program would contain all of the "if" stuff just the same as before. The "then" section would only execute the "then" section of the second program.

 

The second program should be blank in the "if" section. You make the first line of that "then" section be to disable the first program and the last line to re-enable it.

 

I tested it with a simple disable program, wait 10 seconds, enable program and it seemed to work.

[sanders2222]

Thanks for the work around tip:

I think you can get around this problem . .

I added the disable and enable lines to my 2nd program, but it still did not complete execution (leaving the 1st program disabled). There are no "if" conditions in the 2nd, but both programs belong to a folder that has "if" conditions. So I'm wondering if that has something to do with it?

Folder 'Away'

If
.   Program 'Flag Away' is True
Then
.  Allow the programs in this folder to run

1st Program 'Arrival Motion' - Activated when garage door opens and motion is detected

If
.      Control '_Garage/_Garage 11.A3.B8-Sensor' is switched On
.  And Program 'Flag Garage' is True
Then
.   Set Scene 'Utility Room/Away' Off
.   Run Program "Arrival' (Then Path)

2nd Program 'Arrival'

If
.   No Conditions  (To add one, press 'Schedule' or 'Condition')
Then
.   Disable Program 'Arrival Motion'
.   Run Program 'Flag Away' (Else Path)
.   Send Notification to 'Cell Phone'
.   Set 'Utility Room/Hall Util Load' 55%
.   Set Rec/Hall Main Load' 55%
.
.
.   Enable Program 'Arrival Motion'

The notification was sent and the lights came on but somewhere between the beginning of the program and the end, the program stopped executing.

[apostolakisl]

So you are saying it completed all of the then stuff except the last step, reactivating the original program?

 

I would definitely try moving the second program outside of the folder. It doesn't need to be a folder since the "if" statements aren't contained in that program.

 

The simple program I programmed to disable/reenable worked fine, but it was not in a folder with any conditions (though I did put it in a folder I keep and call "test" which I use to do stuff like this)

[sanders2222]

..you are saying it completed all of the then stuff except the last step

To clarify, some of the first lines in the 2nd program executed, but a number of lines at the end of the program did not, which included the last line.

I would definitely try moving the second program outside of the folder.

That is what I will try next. I have set up a new 'Arrival' folder that does not have any conditions and moved my 'Arrival' program there. Hopefully, that will solve the problem I am experiencing. If not, I'll be back. Thanks for your help.