Switch/Select Case, Nested If Else, Asynchronous Run calls, Run-time Value to Variable

[CraigG]

As mentioned in the title, here are some common options that I would like to see in the isy994i, listed by importance to me:

 

1) Switch/Select Statements and/or Nested IF/ELSE statements. This one is really the most frustrating. According the other posts I've seen over the years, this has been "coming soon" since 2008, but it's still yet to happen.

 

2) Variable to run time value assignment and vice versa. For example:

int_Temp = Module 'Climate' Temperature

or something like

Set "Pool Light Dimmer" = int_Percentage

 

3) Asynchronous "Run Program (?)" calls. This may be an option that I'm not aware of, but it appears that when you call "Run Program (?)" from within another program that it spins up another thread and executes that program synchronously. An option to run another program and block until it has completed would have obvious benefits.

[larryllix]

As mentioned in the title, here are some common options that I would like to see in the isy994i, listed by importance to me:

 

1) Switch/Select Statements and/or Nested IF/ELSE statements. This one is really the most frustrating. According the other posts I've seen over the years, this has been "coming soon" since 2008, but it's still yet to happen.

 

2) Variable to run time value assignment and vice versa. For example:

int_Temp = Module 'Climate' Temperature

or something like

Set "Pool Light Dimmer" = int_Percentage

 

3) Asynchronous "Run Program (?)" calls. This may be an option that I'm not aware of, but it appears that when you call "Run Program (?)" from within another program that it spins up another thread and executes that program synchronously. An option to run another program and block until it has completed would have obvious benefits.

1) To create a select construct a variable would be required. This has been possible since I joined with v3.xx. Unfortunately it takes a separate program from every case but in a event triggers processing engine like ISY I see no other way of doing it without really disrupting the common syntax.

 

2) V5.x does this just fine

 

3) Yes a Blocking Wait would be good for subroutine calls to ensure completeion before proceeding. Again, in a trigger event based processing environment, this could be done using existing constructs in ISY, one being use of semaphores by variable values or program execution detection.

[MWareman]

ISY is an event driven environment. I'm not sure blocking calls are relevant to event based environments, although I could see the utility.

 

What would happen if the original triggering condition changes? Should the sub-program terminate as well?

[larryllix]

The block would only be for the program making the call, not the ISY engine.

 

More appropriate may be something like...

 

• Run program (if) XXXXX with Wait for return.

 

Good foresight  on exception handling though.

[CraigG]

1) To create a select construct a variable would be required. This has been possible since I joined with v3.xx. Unfortunately it takes a separate program from every case but in a event triggers processing engine like ISY I see no other way of doing it without really disrupting the common syntax.

 

2) V5.x does this just fine

 

3) Yes a Blocking Wait would be good for subroutine calls to ensure completeion before proceeding. Again, in a trigger event based processing environment, this could be done using existing constructs in ISY, one being use of semaphores by variable values or program execution detection.

 

1) Yeah, this is really the only choice, and it's totally unmanageable after a certain point. I won't bore you with details, but in a recent attempt to replace a whole house audio remote control app I was over 50 programs before I said "forget it", and I was only through 5 of 8 speaker locations.  Funny thing is that with nested conditional statements, it would have been roughly 6 programs total. 4 if I had the ability to block until Run Program returned.

 

2) Is 5.x in beta/test? I'm on 4.5.4, and do not have the option to do this.

[larryllix]

1) Yeah, this is really the only choice, and it's totally unmanageable after a certain point. I won't bore you with details, but in a recent attempt to replace a whole house audio remote control app I was over 50 programs before I said "forget it", and I was only through 5 of 8 speaker locations. Funny thing is that with nested conditional statements, it would have been roughly 6 programs total. 4 if I had the ability to block until Run Program returned.

 

2) Is 5.x in beta/test? I'm on 4.5.4, and do not have the option to do this.

My guess is you are trying to track a thermometer reading through every degree it can register.

When you go to V5 you won't need to do that.

 

In V4.x I picked the actual temperature range that would be used and coarser increments outside of those ranges.

In v5 just save the stat reading into a variable, or get some CAO Tags that do it without ISY programs at all.

 

A case/select would require many clauses instead of programs. You just have to get over that one, and work with what it has, unfortunately, for now. The amount of code is the same, only the looks suck.