Triggers and conditions and IFs, oh my!

[oberkc]

I am unsure how you know the various games and TVs are on or not, but the logic is just as you have it.  Use parentheses before first OR and after last.

[Goose66]

Are nested conditions not supposed to create triggers for the program? If they still do, you need to use the two program Trigger/Action approach.

Also, seems to me you want ANDs between the Logitech Hub activity status, not ORs.

Edited May 27, 2019 by Goose66

[TomNow2]

1 hour ago, oberkc said:

I am unsure how you know the various games and TVs are on or not, but the logic is just as you have it.  Use parentheses before first OR and after last.

Thank you, I'm using the Harmony Polyglot server by Jimbo to get the status of the Harmony 'scene'.  How do I actually add the OR's within the parenthesis? When I try to do that it ads everything on a different line and breaks it. I'm doing all this through the admin console programs section, thanks!

[TomNow2]

33 minutes ago, Goose66 said:

Are nested conditions not supposed to create triggers for the program? If they still do, you need to use the two program Trigger/Action approach.

Also, seems to me you want ANDs between the Logitech Hub activity status, not ORs.

I want the conditions to shut the lights when I am pretty sure no one is there, so I'm thinking of no motion is sensed AND not one is watching TV then it should be good to go.  Perhaps something like this?

 

If No Motion

AND

(Harmony Xbox = not on OR Harmony PS4 = not on OR ...)

Then Shut down lights

I guess I am having a hard time writing that syntax into the admin console

[oberkc]

15 minutes ago, TomNow2 said:

How do I actually add the OR's within the parenthesis?

The parentheses option is lower-right of the main admin window, I recall from memory.  Once there, move lines up or down as needed to group items within the parentheses.

[oberkc]

I also wonder same thing as Goose66.  Using "or" would result in lights off if PS4 is off, yet TV still on.   In my mind, all devices should be off to declare basement unoccupied.  Were this me, I would skip the parentheses and join each condition with AND

[Goose66]

Turn Off Basement Lights - Trigger:

If
        'Basement / Motion--Sensor' is switched Off
Then
        Run Program 'Turn Off Basement Lights - Action' (If)
Else
   - No Actions - (To add one, press 'Action')

Turn Off Basement Lights - Action (Disabled):

If
        'Basement / Logitech XBox Activity' Status is Off
    And 'Basement / Logitech PS4 Activity' Status is Off
    And 'Basement / Logitech TV Activity' Status is Off
Then
        Set 'Basement / Lights' Off
Else
   - No Actions - (To add one, press 'Action')
 

 

Edited May 28, 2019 by Goose66

[TomNow2]

10 hours ago, Goose66 said:

Turn Off Basement Lights - Trigger:

If
        'Basement / Motion--Sensor' is switched Off
Then
        Run Program 'Turn Off Basement Lights - Action' (If)
Else
   - No Actions - (To add one, press 'Action')

Turn Off Basement Lights - Action (Disabled):

If
        'Basement / Logitech XBox Activity' Status is Off
    And 'Basement / Logitech PS4 Activity' Status is Off
    And 'Basement / Logitech TV Activity' Status is Off
Then
        Set 'Basement / Lights' Off
Else
   - No Actions - (To add one, press 'Action')
 

 

Interesting! Thank you very much for this, will try it out in the morning

EDIT: Can someone explain to me why we would disable the 'Action' program?  And just cause it's disabled, it'll still get triggered by the trigger program?  I really like this trigger / action approach BTW, very unique!

Edited May 28, 2019 by TomNow2

[Goose66]

The Action program is disabled so that the events of the Logitech activities changing status don't trigger the program. For example, you've been sitting still for longer than ten minutes and then switch from TV to PS4. If the program were initiated, it would go into the else because the motion-sensor was not switched off, so why bother triggering the program at all?

The purpose of the two program (Trigger / Action) approach is to address shortcomings in the ISY's programming model - the programming model is a conditional one, where it should be an event-driven model. To overcome this limitation, in the two program approach, the events that you want to trigger the program go in the first, "Trigger" program's If statement, and the conditions you want to check before executing the steps in the Then or Else branches go in the second, "Action" program's If statement. The Trigger program  is enabled, but the Action program is disabled so that the conditions in the If statement also don't serve as event triggers. You don't always need two programs (such as simple schedule triggers), but if you consistently use the two program approach, it makes for a very neat and tidy model. It is also, IMO, the only model in which the Else branch ever makes sense. 

There is a lot of discussion of this approach and supporting arguments for it (along with a lot of counterarguments) in these forums, such as:

.

Edited May 28, 2019 by Goose66

[Michel Kohanim]

@Goose66,

Just to be clear, ISY is event driven. i.e. it evaluates events and then does something. I am not sure what a conditional programming model is.

With kind regards,
Michel

[TomNow2]

Hi Michel, so with event driven, does that mean that the program will look for that 'trigger' when it changes to 'false' and then run the program once?  Or does it continually keep running the program since the motion sensor is now set at 'false' ?  And if it keeps running it, what's the best way to prevent that, maybe put a wait timer in the after the 'run program' command ?  Thanks again!

[Michel Kohanim]

@TomNow2,

By event driven I mean that programs are evaluated based on events. i.e. if there are NO events (changes in the properties of devices, smart meter, electricity pricing, climate conditions, etc.), then the programs will NOT be evaluated at all UNLESS they are schedule based. Some high level information:

1. Based on whether or not the incoming event makes the If true or false, Then or Else sections are executed respectively
2. You can use Repeat or Wait in Then/Else. But, note that both are interruptible. This means that if the condition changes to false based on another incoming event, then Wait/Repeat will terminate in the Then. And, if true, Wait/Repeat terminate in Else
3. If the status/property of a device does not change, an event is not generated so the programs depending on Status will only work based on change of state
4. Programs based on physical activity are handled by Control. This means that if a device is already on, and you go and physically turn it on again, then the program will be evaluated IF AND ONLY IF it's checking for Control

In short, everything happening in ISY is based on generated and processed events. Of course, you can force programs to run/stop etc. but that's just the means for giving you more control over what should happen and/or reuse of certain constructs.

With kind regards,
Michel

[TomNow2]

@Michel Kohanim

Excellent explanation, thank you very much for replying!

[Goose66]

By “conditional” model, I mean you specify the conditions and the ISY decides what events trigger the program based on the conditions. In an event-driven programming model, you would specify the events that would trigger the program yourself. Think old school C++ Windows event loop or Visual C#.

But, of course, we’ve certainly had this discussion before.

So going back to Tom’s problem, it make no sense to run the program when the status of the Logitech activities change, because the program would always fall into the Else branch. So put those conditions in the disabled Action program, and the program will only trigger when the Motion detector sends an Off command (which is I believe the intention).

Edited May 29, 2019 by Goose66

[Michel Kohanim]

@Goose66,

I still don't get it. What's an event and what's a condition? 

With kind regards,
Michel

[Goose66]

Status of 'Basement / Light' Changes - Event
'Basement / Motion' Sends an On Command - Event
CLIMD of 'Basement / Thermostat' Changes - Event
Time is "3:54:00 PM" - Event
etc.

If 'Basement / Light' Status is Off - Condition
If Time is between Sunset and Sunrise - Condition
If 'Basement / Thermostat' TEMP_C is less than 54 - Condition
etc.

The ISY takes the conditions from the If statement of a program and infers the events upon which to execute the program. It is this inference that has caused some confusion in the past - e.g., Tom's question above regarding the program being triggered when the status of a device changes or continuously when the device is Off. By using the two program Trigger / Action model, the user can specify which conditions should be used as events to trigger the program and those that should not be used as events to trigger the program.

Edited May 29, 2019 by Goose66

[Michel Kohanim]

@Goose66,

Thanks so very much for the details. With sincere apologies, I still don't get it. ISY supports the first 3 (as events) which are published in pub/sub fashion to clients. Now, within ISY, you have a choice: to do something with those events (condition on the event) or not. Apart from subscriptions, are you saying that there are other purposes for "events" without any conditions? If so, what? What do you want to do with those events? 

With kind regards,
Michel

[Goose66]

I am comparing it with a traditional scripting model. For example, if I am programming client-side GUI interaction of a web page in Javascript, I write a function (equated to a Program on the ISY) which may contain evaluation of many parameters from the DOM. But the browser will not automatically execute that function anytime the value of any one of those parameters in the DOM changes, right? I have to specifically tie the function to a DOM event to get the function to execute. So if I have a condition that checks the value of a text box, then I have to tie the function to the text_box_change event for that text box to get the function to run.

If the ISY was a similar event-driven model, I would write the Program with all of the conditions I wanted to evaluate in the If statement, but then I would tie the Program to the events that I was interested in having the program run. This may create some Programs that had no If conditions (e.g., tied to an event of 'Device' is switched On with no conditions in If) and others with seemingly redundant information (e.g. If 'Device' Status is Off condition with the program having to be tied to the 'Device' Status_Change event), but the circumstances under which a program is executed would be clearer. This would help users, especially new users, with the inevitable confusion caused when a Program's Else branch is inexplicably run or where a Program containing a WAIT or REPEAT never seems to finish. This is why I tend to recommend the two program Trigger / Action approach, again especially in the case of a new user or non-programmer user.

Edited May 29, 2019 by Goose66

[Michel Kohanim]

@Goose66,

Thanks so very much for the detailed explanation. I think what you are looking for is a full featured programming/scripting language (such as JavaScript/Lua/pawn) and I am almost certain that, even though you might love it, we'll have to have all non-programmers having to take programming courses. Cases in point … take a look at our competitors. 

Also, it's pretty much an impossibility for Wait and Repeat not to finish. They both have a limit and, if the condition changes, then they will stop.

Anyway, I just didn't want to let "shortcomings in ISY's programming model" to be left unanswered. Yes, perhaps shortcomings for a programmer. The same way that Java fixes the shortcomings of C++ (e.g. garbage collection) and C++ fixes the shortcomings of Java (e.g. no interpreter required) and on and on …. 

With kind regards,
Michel

[Goose66]

Perhaps "shortcoming" was a little passive-aggressive. But I do think after hanging around these forums for the last twelve or so years that the current model has caused some consistent confusion with new users because it's not entirely intuitive what events will cause the programs to run, nor is it intuitive what events will cause the program to be preempted and start again when it is already running. Thus the confusion around programs with WAITs and REPEATs seemingly not "finishing" is caused not by the WAIT or REPEAT not finishing but the program has been preempted by an occurrence of an event during the WAIT or REPEAT (and probably dropped into the Else branch) without the initial run of the program ever completing. 

But it's just a difference of opinion on approach, and I think the two program Trigger / Action model bridges the gap. I seem to recall that this was Chris Jahn's invention originally, wasn't it?

Edited May 29, 2019 by Goose66

[Michel Kohanim]

@Goose66,

Thank you!

I think the best approach would be to have a scripting language extension for those who want to program. Perhaps in our next lives :).

With kind regards,
Michel

[apostolakisl]

20 hours ago, Goose66 said:

Perhaps "shortcoming" was a little passive-aggressive. But I do think after hanging around these forums for the last twelve or so years that the current model has caused some consistent confusion with new users because it's not entirely intuitive what events will cause the programs to run, nor is it intuitive what events will cause the program to be preempted and start again when it is already running. Thus the confusion around programs with WAITs and REPEATs seemingly not "finishing" is caused not by the WAIT or REPEAT not finishing but the program has been preempted by an occurrence of an event during the WAIT or REPEAT (and probably dropped into the Else branch) without the initial run of the program ever completing. 

But it's just a difference of opinion on approach, and I think the two program Trigger / Action model bridges the gap. I seem to recall that this was Chris Jahn's invention originally, wasn't it?

 

3 hours ago, Michel Kohanim said:

@Goose66,

Thank you!

I think the best approach would be to have a scripting language extension for those who want to program. Perhaps in our next lives :).

With kind regards,
Michel

Absolutely 100% agree that people new to ISY consistently make the same incorrect assumptions about what will trigger a program to start/restart and the ensuing unexpected outcomes.  I don't think this is a problem with the language, it is a problem with preconceived notions.  I understand JAVA GUI is now in its last days.  Perhaps when the new GUI interface is being developed, a "beginners mode" could be included with pop-ups or bubbles or whatever that give friendly reminders about how things are going to behave and common incorrect assumptions that result in unexpected program behavior.  For example, if you include a "Wait" in your program, a bubble pops up and says "remember, the wait will terminate upon a condition in the "If" clause changing during the wait"

[mwester]

2 hours ago, apostolakisl said:

 

Absolutely 100% agree that people new to ISY consistently make the same incorrect assumptions about what will trigger a program to start/restart and the ensuing unexpected outcomes.  I don't think this is a problem with the language, it is a problem with preconceived notions.  I understand JAVA GUI is now in its last days.  Perhaps when the new GUI interface is being developed, a "beginners mode" could be included with pop-ups or bubbles or whatever that give friendly reminders about how things are going to behave and common incorrect assumptions that result in unexpected program behavior.  For example, if you include a "Wait" in your program, a bubble pops up and says "remember, the wait will terminate upon a condition in the "If" clause changing during the wait"

 

I'd agree that there's huge confusion about what things are triggers and what are not.  I'd second this idea -- some sort of markup or annotation or perhaps just auto-adding comments to the program that would indicate with certainty what the ISY considers to be triggers would save a lot of trouble.

(If one were to start all over, I would strongly suggest a program structure other than "if (events and conditions) then (something) else (another thing)" -- perhaps something like "when (events) do if (conditions) then (something) else (another thing) -- which would allow one to simplify most real-world programs to the very clear and very obvious "when (events) do (something)", which even the most basic beginner would find obvious.  JMO)