add an else if

[apostolakisl]

Here is I think a simpler way to do what you want.

"Lights on At Sunset to Sunrise Program"

If 
time is from sunset to sunrise next day
Then
Set light to 100 percent
Else
Set light off

"Light Brightness Step Down Program"

If
Time is 10pm 
Then
set light to 40 percent
wait 3 hours
set light to 15 percent
Else
---

 

This would be thinking more as an event driven logic rather trying to force logic that works better in other environments.

Ahhh, seems like that could actually be simplified further into the ultimate goal of having just one program per task!

"Lights on At Sunset to Sunrise Program"

 

If

    time is from sunset to sunrise next day

Then

    Set light to 100 percent

    wait 3 hours

    set light to 40 percent

    wait 2 hours

    set light to 15 percent

Else

    Set light off

End

 

(Sorry, didn't mean to turn this into a "I can code that in 5 lines or less" competition .)

 

 

I had thought of that but the trouble is that I thought 10pm was a fixed time and sunset plus x hours would be changing all the time. But that may not be your intent.

 

And no need to apologize for "I can do that in 5 lines or less", that is always fun.

[Xathros]

Ahhh, seems like that could actually be simplified further into the ultimate goal of having just one program per task!

 

"Lights on At Sunset to Sunrise Program"

 

If

    time is from sunset to sunrise next day

Then

    Set light to 100 percent

    wait 3 hours

    set light to 40 percent

    wait 2 hours

    set light to 15 percent

Else

    Set light off

End

 

 

(Sorry, didn't mean to turn this into a "I can code that in 5 lines or less" competition .)

 

Keep in mind that sunset is a moving target. Right now where I am, sunset is at 4:22pm. Sunset+3 is 7:22pm and at 9:22 the lights would be at 15%. During the summer months, the lights might not reach 15% till 1am or later! I think in this case, the 2 programs make more sense (without the IfElse construct of course ).

 

-Xathros

[apostolakisl]

An elseif wouldn't fix your problem. The problem is that the primary program is only triggering twice. At Sunset (true) and 10pm (false). So an "elseif" would only get a chance to run at 10pm, just like your "else run program 2" is only running at 10pm. Either way, it won't work. Your issue is with the event driven logic of ISY, not the existence (or lack thereof) of elseif.

An implementation of ElseIf should look something like this (logically):

If From Sunset to 10PM Then

    Set lights to 100%

ElseIf From 10PM to 1AM (Next Day) Then

    Set lights to 40%

ElseIf From 1AM to Sunrise Then

    Set lights to 15%

Else

    Set lights Off

End If

An Implementation of ElseIf would also (naturally) require the isy994i to analyze each ElseIf statement for additional triggers.

 

I fail to see why this wouldn't be a much more appealing arrangement than having two, three, four, or five, separate programs cobbled together.

 

It kind of is multiple programs cobbled together, you are just putting them all on the screen at the same time. It makes logical sense to be able to view programs like that when they all are part of the same fundamental task. But making a folder structure isn't really that bad is it?

[G W]

The problem is perception. It would help if the ISY had a TRIGGERS section. Then users would get a better understanding of what is going on. A TRIGGER would then call a PROGRAM that would test for CONDITIONS and act according.

 

Coding the ISY is not intuitive, but that does not make it wrong or unusable. One just needs to understand how it functions.

 

I had not done a lot of programs in the ISY but now I'm building more functions onboard and understanding what is really goung on.

 

Had I set this in the beginnig, I would have Event Watchers, Cron Watchers, and Programs. It's a simple system to maintain and I do a lot of this with an external server sending commands to the ISY.

 

Sent from my GT-P5210 using Tapatalk 4

[apostolakisl]

The problem is perception. It would help if the ISY had a TRIGGERS section. Then users would get a better understanding of what is going on. A TRIGGER would then call a PROGRAM that would test for CONDITIONS and act according.

 

Coding the ISY is not intuitive, but that does not make it wrong or unusable. One just needs to understand how it functions.

 

I had not done a lot of programs in the ISY but now I'm building more functions onboard and understanding what is really goung on.

 

Had I set this in the beginnig, I would have Event Watchers, Cron Watchers, and Programs. It's a simple system to maintain and I do a lot of this with an external server sending commands to the ISY.

 

Sent from my GT-P5210 using Tapatalk 4

 

I agree. The biggest issue I have with ISY and really the only thing that keeps requiring work-arounds is the fact that you can't control the triggers. I would love to see the if section divided into two parts. Trigger conditions and secondary conditions.

[Goose66]

It would help if the ISY had a TRIGGERS section.

+1. I have been advocating this for years:

 

viewtopic.php?f=39&t=4852

 

I even posted an example UI for the triggers section (although I can't figure out how to post an image on here anymore).

 

I don't think we will ever see this change, though.

[apostolakisl]

The vast majority of the trigger issues come when using status of an Insteon device and every change of that device is a trigger.

 

So, even if we could get that one if condition split into two. In other words, in the pull down menu you would get two choices.

 

1) Status trigger

2) Status state

 

It might look like this:

 

 

Or something like this, where you get to pick if it is a triggerable condition.

 

[Michel Kohanim]

Thank you all for the feedback.

 

Since we are working on enhancements to programs/variables we might take another look at this feature.

 

With kind regards,

Michel

[apostolakisl]

Thank you all for the feedback.

 

Since we are working on enhancements to programs/variables we might take another look at this feature.

 

With kind regards,

Michel

 

Good to hear. I know you guys work your tail off trying to make this thing better all the time.

 

If you were going to start with anything, I would start with device status and from/to time. In fact, if those were the only 2 things that you could optionally disable as triggers, that would probably take care of 99% of all unwanted triggers.

[Michel Kohanim]

Thank you. That makes sense!

 

With kind regards,

Michel

[larryllix]

ElseIf may not be possible in a real-time event driven environment. It's been a while since I did my experience with another real time system and my mind may not be as clear as it was after grinding out code for a year on the real-time system I worked on.

 

"Case" construct may be a better option. The event triggers may be simpler for the ISY guys to implement and the user code is simpler to write and look at. It can accomplishe the same things as multiple "ElseIf" line constructs.

 

Some system variable access may be required.

 

Select $system.time

Case: Sunset to 10PM Then

. Set lights to 100%

Case: 10PM to 1AM (Next Day) Then

. Set lights to 40%

Case: 1AM to Sunrise Then

. Set lights to 15%

Else

. Set lights Off

End Select

[bsobel]

Thank you all for the feedback.

 

Since we are working on enhancements to programs/variables we might take another look at this feature.

 

With kind regards,

Michel

 

Good to hear. I know you guys work your tail off trying to make this thing better all the time.

 

If you were going to start with anything, I would start with device status and from/to time. In fact, if those were the only 2 things that you could optionally disable as triggers, that would probably take care of 99% of all unwanted triggers.

 

Agreed with one caveat, modification to wait to allow wait (retriggerable) wait (do not retrigger) With that I think all the use cases that are important are covered.

[larryllix]

It would help if the ISY had a TRIGGERS section.

+1. I have been advocating this for years:

 

viewtopic.php?f=39&t=4852

 

I even posted an example UI for the triggers section (although I can't figure out how to post an image on here anymore).

 

I don't think we will ever see this change, though.

After some experience with this I have come to the same conclusion. Triggers should be isolated from conditions. The ISY system is event/trigger driven and to combine it's main feature with condition testing is the major source of needing "workarounds" in the programme code writing.

 

"Elseif" would be nice as I find the programme call (subroutine) too slow and it shows up in the lighting responses with motion detectors.

[Goose66]

I have attached an image file with the UI I came up with a while back.

[larryllix]

I have attached an image file with the UI I came up with a while back.

I completely agree except I would call the section "Event Trigger".

 

The "Control" option in the "Action" section pull-down could be eliminated (would only needed as a pull-down option in the trigger section then) and it would simplify programming and understanding greatly.

 

Sure would be a lot less posts asking "why do I get random operations?"

[Goose66]

For "When" or "Event Trigger" you would need:

 

1. Command received

2. Network Event

3. Time

4. Device Status Change

5. Program runs

6. IR

7. Module events

(I'm not including variable value change because it is lazy -- the programs already control the variables. But it's a possible)

 

For "If" you would need:

 

1. Time Range

2. Device Status = specific status

3. variable = value

4. Module variables/values - value

(Again, program = value is lazy because it could be done with variables, but possible)

[apostolakisl]

All "when" statements would be by default "if" statements, but the converse is not true. So a programmer could put all conditions into the "when" section and things would be exactly the same as they are now. By having the 2 sections, you could have the option to moving triggerable events out of the "when" section and into the "if" section.

 

If you wanted to make it very clear to a novice programmer you could title them more obvious.

 

"When these events happen"

 

"And if these conditions are also met"

[larryllix]

All "when" statements would be by default "if" statements, but the converse is not true. So a programmer could put all conditions into the "when" section and things would be exactly the same as they are now. By having the 2 sections, you could have the option to moving triggerable events out of the "when" section and into the "if" section.

 

If you wanted to make it very clear to a novice programmer you could title them more obvious.

 

"When these events happen"

 

"And if these conditions are also met"

 

Agree with the better labels for section to simplify. There are a few places I think need that.

 

I believe the programming could be even simpler than that:

The "When/trigger" section would not require the "status" option as it causes no trigger without constant programming loop attention. Statuses only change with a semaphore arriving from a dynamic device arrives. I believe that is what is happening now. The conditions stated is not the triggering event but a change in the device gets the attention. Then the status is check according to the user's specification (ON/OFF). This means that two distinct actions are being addressed in the code already. They just aren't shown to the user in separate sections. (ON/OFF/DIM etc..) would not even need to be specified in the "When/trigger" section. I believe it doesn't function now but rather only in the "if/Condition" section as a second and only logic test.

 

The "If/condition" section would not need a (currently) "switch" option as an instantaneous change isn't being tested for when the logic is being tested by the user spec.

 

In short: Only devices (PB presses, MS dark, Time=, Sunset, ) would be listed and cause "when/triggers/events". Clock time is a grey area there. but each second would be evaluated for event causing. The "If/condition" section would only determine which way the programme would go. "Then" or "Else".

 

There will be other examples of differences ad nauseum but too complex to rattle here, before commitment from UDI and more thought from users.

 

So we would have something like this:

 

When:

. Motion_detector (changes)

 

If:

. Motion_detector is ON

. AND

.Time is after Sunset

. AND

. Time is before Sunrise (next day)

 

Then:

. Do_dark_things

 

Else:

. Do_nothing '*** must be day time or MS just turned OFF

[Goose66]

I think your use of the term "semaphore" is a poor choice in a programming context -- it doesn't mean what you think.

 

Regardless, the Insteon command that causes the status of a device to change could vary quite a bit - one of a number of group or scene commands that include the device, for example. AFAIK. the ISY device doesn't receive a direct command indicating the status change, but determines the status change from it's knowledge of the relationship between devices. That is why if you turn a scene off via the ISY, it will show all the devices as off, even if some of the devices don't actually turn off.

 

So given that fact, I think it is still important to be able to trigger a program based on the change in status of a device. To remove this trigger would be rather limiting.

 

As far as the "And if these conditions are also met" language, I think that imparts the wrong impression, because there is no nexus between the trigger events and the if conditions. The program will run when any of the trigger events listed occur (essentially having an implied OR between them). The If conditions drive whether the Then branch is executed or the Else branch is executed. That simple.

[apostolakisl]

 

As far as the "And if these conditions are also met" language, I think that imparts the wrong impression, because there is no nexus between the trigger events and the if conditions. The program will run when any of the trigger events listed occur (essentially having an implied OR between them). The If conditions drive whether the Then branch is executed or the Else branch is executed. That simple.

 

I don't think that this is a very good way to do it. You are saying that the "when" section carries no value in determining true/false. You would then need to duplicate your when conditions into the if section since most anything you would put into the "when" would also play a role in true or false. I can not think of something you would have trigger a program that you would also not want to play a role in the true/false nature of the program. In your construct, a simple program like:

 

If

status of device x is on

Then

do something

 

Becomes:

When

status of device x changes

If

status of device is on

Then

do something

 

 

It would also be a much bigger re-write of ISY code. My construct allows for all of the exact same language, it just renders all of the lines of code after the "and if these conditions are also met" impotent as far as triggers. Functionally no different than a disabled second program that got called by the first.

[larryllix]

So given that fact, I think it is still important to be able to trigger a program based on the change in status of a device. To remove this trigger would be rather limiting.

"change in" This is why the state of a status would not be required in the trigger section, as it is currently. Static states should not (and currently do not) cause triggers, only changes to status states.

 

Without the current dual purpose, as detection of a change attempt, and detection of the static state of a status, crammed into one section, we would have no need for both constructs in either the "trigger" or the "if" section. Only one style of detection can function in each section.

 

I see no change in limitations, only more freedom of usage style where the dual functionality is separated.

 

Just semantics of perceived meaning. I think we see the same thing. As a matter of fact I just got reading your original posts on this and you understand the current construct problems perfectly IMHO.

[Goose66]

I don't think that this is a very good way to do it. You are saying that the "when" section carries no value in determining true/false. You would then need to duplicate your when conditions into the if section since most anything you would put into the "when" would also play a role in true or false. I can not think of something you would have trigger a program that you would also not want to play a role in the true/false nature of the program....It would also be a much bigger re-write of ISY code. My construct allows for all of the exact same language, it just renders all of the lines of code after the "and if these conditions are also met" impotent as far as triggers. Functionally no different than a disabled second program that got called by the first.

 

The duplication of conditions would only be for the limited example of status changes or variable changes that you presented. For most programs that I have (and can conceive of) the trigger events have no bearing on the if conditions. For example, most of my programs are:

 

When

Device X Command "On" is received

If

Time is between Y and Z

-- OR --

Variable = K

-- OR --

Status of Device A is On

Then

Do Something

Else

<-- No Action -->

 

What I am trying to avoid is the program running (and the Else branch being executed) when the time changes, or variable K changes, or the status of A changes even though Device X Command "On" was not received. I will concede that a large percentage of programs will become simply:

 

When

Device X Command "On" is received

If

<-- No Conditions -->

Then

Do something

Else

<-- No Actions -->

 

As far as it requiring a large re-write of ISY code, I believe quite the contrary. The way the ISY works today, the trigger event is already being separated from the IF conditions. For example, if you have a program with "If Status of X = On" then the ISY parses that program to pull out Status X Change as a trigger event for the program. When the program is run, i.e. the status of X changes, then the ISY will evaluate the conditions and run the Then branch if Status of X = On, and run the Else branch if Status of X is otherwise. I think the way I suggest just makes it much more evident exactly when the program will run and exactly when the Then and Else branches will be executed. In the current implementation, the "If Status of X = On" condition may suggest to users that the program will only run if the Status of X is turned On, not on every status change of X.

[apostolakisl]

The thing is if you changed ISY to this new format. Many programs would require re-writes.

 

In my construct, the ISY firmware update would create a new section in each program, the "if" aka "and if the following conditions are also met". What is currently in the "if" section would simply be moved to the "when" section and the program would run exactly the same with no need for user to edit anything (just leave the new "if" section blank). The "when" section would still work the same with the same language as the current "if" section, only the second section (the new "if") would now contain conditions that don't trigger.

 

I also suspect that in your scheme, use of "is not" would result in logic errors on trigger conditions requiring re-writing of that as well. But I would need to think about that a little bit and my brain isn't into double negatives right now.

[larryllix]

The thing is if you changed ISY to this new format. Many programs would require re-writes.

 

In my construct, the ISY firmware update would create a new section in each program, the "if" aka "and if the following conditions are also met". What is currently in the "if" section would simply be moved to the "when" section and the program would run exactly the same with no need for user to edit anything (just leave the new "if" section blank). The "when" section would still work the same with the same language as the current "if" section, only the second section (the new "if") would now contain conditions that don't trigger.

 

I also suspect that in your scheme, use of "is not" would result in logic errors on trigger conditions requiring re-writing of that as well. But I would need to think about that a little bit and my brain isn't into double negatives right now.

I don't know if that would be avoidable in a major upgrade. Casualties of upgrading? Would we perpetuate lack of progress in that endevour? Probably not.

 

Let's see if this could work:

 

When 
 ~~ not triggers specified ~~
If
       Control  'Motion' is switched On
   And From    Sunset  -  1 hour 
       To      Sunrise +  1 hour  (next day)
Then
       ....

 

Nope, no trigger. I don't think portability is going to work well here.

 

Wait! We need a checkbox that specifies combined or separate trigger/If sections (new/old). Makes an extra processing test each event test delay though. Would we put it as a global checkbox condition or an individual program module condition?

Now when the new ISY firmware is installed all programmes would get installed in the If or in the Trigger section with the "Combined Logic (v4.1.2 and earlier)" checkbox enabled. It would be up to the user to disable and separate the logic sections, if s/he wanted to. Until disabled the other section could be non-existent in the GUI too.

This could also keep all the "old boys" happy as they could continue to support their bad habits.

[apostolakisl]

The thing is if you changed ISY to this new format. Many programs would require re-writes.

 

In my construct, the ISY firmware update would create a new section in each program, the "if" aka "and if the following conditions are also met". What is currently in the "if" section would simply be moved to the "when" section and the program would run exactly the same with no need for user to edit anything (just leave the new "if" section blank). The "when" section would still work the same with the same language as the current "if" section, only the second section (the new "if") would now contain conditions that don't trigger.

 

I also suspect that in your scheme, use of "is not" would result in logic errors on trigger conditions requiring re-writing of that as well. But I would need to think about that a little bit and my brain isn't into double negatives right now.

I don't know if that would be avoidable in a major upgrade. Casualties of upgrading? Would we perpetuate lack of progress in that endevour? Probably not.

 

Let's see if this could work:

 

When 
 ~~ not triggers specified ~~
If
       Control  'Motion' is switched On
   And From    Sunset  -  1 hour 
       To      Sunrise +  1 hour  (next day)
Then
       ....

 

Nope, no trigger. I don't think portability is going to work well here.

 

Wait! We need a checkbox that specifies combined or separate trigger/If sections (new/old). Makes an extra processing test each event test delay though. Would we put it as a global checkbox condition or an individual program module condition?

Now when the new ISY firmware is installed all programmes would get installed in the If or in the Trigger section with the "Combined Logic (v4.1.2 and earlier)" checkbox enabled. It would be up to the user to disable and separate the logic sections, if s/he wanted to. Until disabled the other section could be non-existent in the GUI too.

This could also keep all the "old boys" happy as they could continue to support their bad habits.

 

You did that backwards. The old program "if" would move to the new program "when". The "when" things would be triggers and conditions and work exactly the same as the current "if". No need to change anything if you don't want to. All programs would run exactly the same with no changes needed. In fact, if it were me, I would only use the new section on new programs. There is no reason to change programs that already work as intended even if it means getting rid of a couple.

 

If you have a firmware update that renders a bunch of programs non-functional, you are going to really really annoy a lot of people.

 

It would be a little like Elk. In an Elk rule, the first condition is also a trigger, all subsequent conditions are only tested if the first condition occurred. The only difference is that in ISY we get the option of having multiple "first lines"