ISY Program Structure Enhancement

[fahrvergnuugen]

I'm new here, new to ISY, but old to programming. I was absolutely stumped for a while on why my first couple simple programs would not trigger, and it's because of the way in which the ISY works which is counter intuitive to anyone from a programming background.

 

I think to make things much more transparent and user friendly, the program structure should be changed by separating events from conditions, similar to the way JavaScript (or any other event driven programming language) works.

 

Today, ISY programs have three blocks:

CONDITION

THEN

ELSE

 

The trap that lots of people fall into is that just because they have a condition that evaluates to true (or false for that matter), their program may not necessarily run. Coming from a programming background, I was really confused by this behavior. How can I have a program that says:

 

If SWITCH is ON

THEN variable = 1

ELSE variable = 2

 

And somehow my variable value remains at the init value of 0?

 

Of course now I realize that my program simply wasn't matching a valid event and therefore the ISY wasn't even running it.

 

 

To fix this confusion I would suggest that they separate the EVENTs and CONDITIONS. In other words, put the event that triggers the program to run into it's own block so the code structure would look like this:

 

EVENT

   (list all events which would cause this program to execute, allow AND / OR logic)

IF CONDITION

  (normal condition statements to check the state of devices, variables, etc)

THEN

  (block of code to run if condition is true)

ELSE

  (block of code to run if condition is false)

 

 

If that change is too drastic and would break backward compatibility, then another solution could be to setup an Events tab where the events are mapped to the programs. The code could be backfilled easy enough since the events can be derived from the existing conditions in everyone's legacy programs.

[MWareman]

Or how about having the UI color code conditions that are also triggers? (Say, red)

[oberkc]

I'm new here, new to ISY, but old to programming. I was absolutely stumped for a while on why my first couple simple programs would not trigger, and it's because of the way in which the ISY works which is counter intuitive to anyone from a programming background.

 

I think to make things much more transparent and user friendly, the program structure should be changed by separating events from conditions, similar to the way JavaScript (or any other event driven programming language) works.

 

Today, ISY programs have three blocks:

CONDITION

THEN

ELSE

 

The trap that lots of people fall into is that just because they have a condition that evaluates to true (or false for that matter), their program may not necessarily run. Coming from a programming background, I was really confused by this behavior. How can I have a program that says:

 

If SWITCH is ON

THEN variable = 1

ELSE variable = 2

 

And somehow my variable value remains at the init value of 0?

 

Of course now I realize that my program simply wasn't matching a valid event and therefore the ISY wasn't even running it.

 

 

To fix this confusion I would suggest that they separate the EVENTs and CONDITIONS. In other words, put the event that triggers the program to run into it's own block so the code structure would look like this:

 

EVENT

   (list all events which would cause this program to execute, allow AND / OR logic)

IF CONDITION

  (normal condition statements to check the state of devices, variables, etc)

THEN

  (block of code to run if condition is true)

ELSE

  (block of code to run if condition is false)

 

 

If that change is too drastic and would break backward compatibility, then another solution could be to setup an Events tab where the events are mapped to the programs. The code could be backfilled easy enough since the events can be derived from the existing conditions in everyone's legacy programs.

My suspicion is that there will be confusion regardless. It will be, simply, that it will be others who are confused, rather than you.

 

I have not run into any functional limitations with the way programs currently trigger. My perceptions are that there is learning curve, but it is quick and relatively painless. I am not sure that your suggested approach will do much to help with this.

 

This has been suggested before, I recall. I am not sure whether UDI has it listed as an "enhancement" or not.

[Michel Kohanim]

Hello fahrvergnuugen,

 

First of all thanks so very much for your feedback both on the limitation of to being able to set variables to device states (coming very soon) and this suggestion.

 

As oberkc suggested we have had this feature requested before and it did get a little non-trivial and quickly out of hand. We are however taking another look while we are currently doing surgery on the code for 5.0.

 

Thanks again,

With kind regards,

Michel

[larryllix]

ISY currently has a few  work-arounds for this problem.

 

Variables are categorised into State and Integer = triggering and non-triggering.

 

Programs can be enabled and disabled = triggering and non-triggering.

 

 

Many solutions were previously suggested including a (non)trigger checkbox for each line of code, a separate "Condition" section as you suggested, getting rid of the else section altogether, and making all time framing conditions non-triggering.

[fahrvergnuugen]

Hello fahrvergnuugen,

 

First of all thanks so very much for your feedback both on the limitation of to being able to set variables to device states (coming very soon) and this suggestion.

 

As oberkc suggested we have had this feature requested before and it did get a little non-trivial and quickly out of hand. We are however taking another look while we are currently doing surgery on the code for 5.0.

 

Thanks again,

With kind regards,

Michel

 

Thats good to know Michel.

 

I've given the design some more thought and here's a mockup (for what its worth)

 

Under "Programs" have 4 tabs:

"Summary","Scripts","Variables","Events".

 

The events tab would contain an folder for every device and an entry in each folder for every possible device event, like this:

 

• Device
  • Event
    • <Script(s) To Fire>

 

So a toggleLinc light switch which fires My Program 1 whenever someone turns the switch on would look like this:

• Bedroom Light Switch
  • switchedOn
    • <My Program 1>
  • switchedOff

While a SwitchLinc Dimmer has more capabilities, therefore more events to hook into:

• Kitchen Light Dimmer
  • switchedOn
    • <My Program 1>
  • switchedOff
  • fastOn
    • <My Program 1>
    • <My Program 2>
  • fastOff
  • onBrighten
  • onDim

In this example, turning the light on by either taping once or double tapping for fast on would fire My Program 1, while My Program 2 only fires when double tapping for fast on.

You can set as many programs as you want to any event.

 

Another example of what a MotionLinc's events might look like:

• Driveway Motion Sensor
  • motionDetectedOn
    • <Brighten Porch Light>
  • motionDetectedOff
  • onDusk
  • onDawn
  • onBatteryLow

 

Then there would have to be a special section for time based events where the user can add arbitrary time slots (I would suggest stealing from cron since their 5 character syntax covers any schedule you could ever want)

• Schedule
  • onSunset
  • onSunrise
  • 30 23 * * MON,WED,FRI # 30th minute of the 23rd hour every month of every year on monday wednesday & friday

 

 

 

Separating the events from the conditional logic would eliminate the need for nonsense like this (in bold):

 

PROGRAM1
IF
       Control 'Mo-Sensor-Sensor' is switched On
    And Control 'Mo-Sensor-Sensor' is not switched Off
THEN
    Light On
ELSE
    Light Off

 

Instead it would be

 

Event:

• Motion Sensor
  • motionDetectedOn
    • <PROGRAM1>
  • motionDetectedOff
    • <PROGRAM1>

 

And a much more readable, much easier to understand script:

PROGRAM1
IF
       Status 'Mo-Sensor-Sensor' is On
THEN
    Light On
ELSE
    Light Off

[Michel Kohanim]

Hi fahrvergnuugen,

 

Thank you. Your suggestions completely ignores complex event based logic and won't work except for the simplest events.

 

And pretty soon you will have to blur the boundaries between events and conditions to address those.

 

With kind regards,

Michel

[oberkc]

Nor does this strike me a more transparent, more user friendly, or less confusing. I also dont see how this eliminates the possibility of having a program condition that is true (or false) yet the program not necessarily run. If an event does not occur to trigger a program, how is that any different than the current state of affairs?

[fahrvergnuugen]

Hi fahrvergnuugen,

 

Thank you. Your suggestions completely ignores complex event based logic and won't work except for the simplest events.

 

And pretty soon you will have to blur the boundaries between events and conditions to address those.

 

With kind regards,

Michel

 

Can you please give me an example?

 

The conditional part of the code can handle any "complex" situation by checking the status of other devices.

PROGRAM1
IF
       Status 'Mo-Sensor-Sensor' is On
    AND Status 'Kitche-Light' is On
THEN
    Light On
ELSE
    Light Off

Events are instantaneous and happen in series, both in the physical world and in software. The Event driven model I described above powers 99% of UI software in the world (Windows, Mac, iOS, Android, SAP, Web, etc). The insteon light switch in your house is no different than a button on a web page. The trick is to elegantly and intuitively provide a way for the consumer to program his own logic and hook into the event.

[fahrvergnuugen]

Nor does this strike me a more transparent, more user friendly, or less confusing. I also dont see how this eliminates the possibility of having a program condition that is true (or false) yet the program not necessarily run. If an event does not occur to trigger a program, how is that any different than the current state of affairs?

 

Because it makes it absolutely transparent which events trigger which programs to fire. Look at your program list in your ISY - how do you know which programs are running when you trip a motion sensor or flip a light switch? The only way you can tell is to watch the program log or read (and comprehend) every condition block in every program.

[Techman]

fahrvergnuugen

 

attached is a post that stusviews put together that should help address your last post. there's no need to look at the log to see what the program state is. just set your status to "detailed " view under the programs tab and your status will display in real time.

 

 

 

Insteon program status icons.pdf