Improving the scriptability and debugging

[MrWorf]

Hi!

 

I really love the ISY994 and what it adds to the table, and now that I'm starting to use the REST api to hook up external things (such as my weather station for irrigation decisions) I like it even more. But as an avid developer myself, there are three things I really, really miss.

 

1. Improved program logging.

Right now, I can see it what order things were changing (ie, device X goes to 100%, device Y is off, etc..) but there is no easy way to see how the program tree is executing. It would be awesome if one could obtain a log for programs which looks something like this:

23:55:12 - Program X - IF statement returns true
23:55:12 - Program X - THEN block executing
23:55:20 - Program X - Invoking Program Y: ELSE block
23:55:20 - Program X - ENDIF
23:55:22 - Program Y - ELSE block executing
23:55:24 - Program Y - ENDIF

That would give the user a MUCH greater idea of when something is wrong and shouldn't be too much work to add (I hope )

 

 

2. ELSE IF

I really, REALLY would love this, since now I need to add two programs in my irrigation setup for each station just to deal with this scenario, let me show you:

 

Today:

Program 1:

IF $Sprinkler.Station is 3 AND $Sprinkler.Station3.Skip is 0 THEN
 ...do some sprinkler stuff...
  Run Program NextSprinkler
ELSE
END IF

Program 2:

IF $Sprinkler.Station is 3 AND $Sprinkler.Station3.Skip is not 0 THEN
  Run Program NextSprinkler
ELSE
END IF

I tried having an else, like so:

IF $Sprinkler.Station is 3 AND $Sprinkler.Station3.Skip is 0 THEN
 ...do some sprinkler stuff...
  Run Program NextSprinkler
ELSE
  Run Program NextSprinkler
END IF

But that meant that in all the cases where $Sprinkler.Station ISN'T 3, NextStation program would run. And with 8 sprinkler stations, that messed things up REALLY bad. Took a while to see the logic error (since no #1).

 

With IF/ELSE IF/ELSE IF/.../ELSE/ENDIF, it's possible to:

IF $Sprinkler.Station is 3 AND $Sprinkler.Station3.Skip is 0 THEN
 ...do some sprinkler stuff...
  Run Program NextSprinkler
ELSE IF $Sprinkler.Station is 3 AND $Sprinkler.Station3.Skip is not 0 THEN
  Run Program NextSprinkler
END IF

Much cleaner and VERY powerful. I understand the problem of it though, since $Sprinkler.Station is a state, what happens with:

IF $Variable is 3 THEN
  ... do stuff ...
ELSE IF $State is 1 THEN
  ... do other stuff ...
END IF

I say, do what you do today. In the above example, it won't trigger since the first testcase is a non-state variable. If you swap it around (so IF contains a state) it would execute on change. Combined with #1 this would not be so hard to follow. And in most cases, all cases would likely test something using the same state/variable making this a non-issue.

 

3. WAIT and REPEAT action takes variable

 

PLEASE MAKE THIS HAPPEN! I hate that I have to run a loop with 1 minute delay just to simulate the desired behavior. I can't see why this should be difficult. If you're worried about the variable/state changing during the WAIT/REPEAT block, make a local copy, so even if the variable that the action depends on changes, the action will continue execution as if it hasn't changed.

 

Finally, if you don't mind, please add a "Copy/Paste" functionality to the Program section so it's easier to duplicate functionality.

 

Thanks!

/Henric

[Michel Kohanim]

Hello Henric,

 

Thanks so very much for the feedback. Let me start backwards:

1. Wait/Repeat using variables ... already in 5.0 

2. If/then/else if ... unfortunately not only this is a major change but also it breaks our event driven logic

3. Program debug information ... not precisely as you have but we have started adding more information to the Event Viewer (D2D Event) and will add more to programs in 5.0

 

Thanks again and with kind regards,
Michel

[MrWorf]

Thanks for the quick reply When can we expect early betas of 5.0 ? Do you need early bird testers?

 

Also, since we can't get IF/ELSEIF/... any chance of a switch statement? Basically the program can be a IF/THEN/ELSE or a SWITCH/CASE/CASE/... ? Might be simpler to implement since it's very similar to your existing event logic. Of course, I'm just guessing, but if you could it would be very helpful. Again, just trying to cut down on the overuse of programs to work around issues like this.

[Michel Kohanim]

Hello MrWolf,

 

We'll certainly consider. This said, the only reason that it was not included was because switch statements require binary logic whereas ISY can have multiple events contributing to the logic.

 

With kind regards,
Michel