Goose66

You find many topics in these forums regarding unexpected behavior in programs, and much of it stems from the way the current ISY programming model works regarding trigger events for a program. The trigger events for a program are extracted from the IF condition. So if I have the statement "If Status 'Device' is On" in a program, then the ISY extracts a trigger event for the program to be a status change for 'Device' and if I have the statement "If Control 'Device' is not switched Off" then the the ISY adds a trigger event of command received from 'Device.' Note that the trigger events are inherently ORed, even though the actual IF conditions may be ANDed or ORed. Now, I think most would agree that this fact causes confusion for many new ISY programmers. A classic case is: If Control 'Motion Sensor' is switched On And Status 'Living Room Light' is Off Then Set 'Living Room Light' On Wait 5 minutes Set 'Living Room Light' Off Else -- No Statements -- You see this over and over again, and it makes sense on first blush. What many don't realize is that in addition to the program running when the ON is recieved from the motion sensor, the program is going to run everytime the status of the living room light changes as well. In this particular case, when the program sets the living room light ON, that changes the status of the living room light, causing the program to be run again, this time causing the ELSE branch to run. So the 5 minute WAIT gets cancelled, the light is never turned OFF. Another classic example is: If Control 'Motion Sensor' is switched On And From Sunset To Sunrise (next day) Then Set 'Living Room Light' 20% Wait 5 minutes Set 'Living Room Light' Off Else Set 'Living Room Light' On Wait 5 minutes Set 'Living Room Light' Off Here, the object is to have the light turn on one level when it is dark outside, and a different level in the day time. The problem here is that this program also runs at Sunset and at Sunrise the next day, which from the grammatical reading of the IF statement is not expected. The ELSE branch will be executed at these times, even if no motion control was received. I submit that if I could specify trigger events for a program seperately from the IF conditions, much of this confusion could be avoided. In a conventional event driven environment, you specify the events that will trigger the program explicitly. For example, for the ISY you would specify that you want the program to run when a command is received from 'Device' (either a specific command or any command, perhaps), when the status of 'Device' changes, when a specific time occurs, etc. These events are inherently ORed together. Seperately, you would specify the IF conditions for executiong of the THEN or ELSE branches of your program, which could include status of devices, times within specific ranges, etc. If this were the programming model for the ISY, you would find ELSE branches much more useful, because you wouldn't have the program triggering at different times and entering the ELSE branch just because you included specific conditions in your IF statement. That is why you find that people seldom use ELSE branches when they have multiple conditions.

I also like the fact that subsequent trigger events halt the current running instance of a program in favor of a new instance. While it may not be obvious to a new programmer, I think it is essential for novices, because it prevents them from having to think in terms of multi-threaded execution and semaphores or other mechanisms for synchronizing the execution of multiple instances of the same program. It also makes occupancy sensing much easier with motion sensors that are jumpered to only send ON commands (occupancy mode), which is how I like to use them. As far as the "If 'Device' is not switched On" not working as expected, I am flabbergasted and almost certain that I have at least one program that is not operating as I expect because of it.

Thanks, apostolakisl, that is excellent information. In my opinion, this is a BUG, and a big one! "If Control 'Device' is not switched On" should evaluate TRUE if a command is received from Device for anything other than On. Having it run the ELSE branch only when the device is switched On makes no logical sense whatsoever, short of being the closest thing to the grammatical syntax of the statement. But I don't care about grammar, I care about event driven programming. Control statements should cause the program to trigger whenver a command is received from the Device. Then the IF statement should be evaluated accordingly. Maybe the grammatical display of the Control statement could be changed to "If Control 'Device' is switched not On". Again (and again, and again), being able to seperate trigger events from IF conditions would make this a WHOLE LOT clearer, but in light of the current ISY model, a program with the statement "If Control 'Device' is switched On" should run the THEN branch of the program whenever a command of On is received from Device (and not trigger the program at all if another command is recevied), and the statement "If Control 'Device' is not switched On" should run the THEN branch of the program whenever a command other than On is received from Device. Michel, please comment on this being a bug or the intended design.

The IF statement: If Control 'Device' is switched On Or Control 'Device' is not switched On Then -- Statements -- in my experience does exactly what you are saying it should do: any command received from the device activates the program and executes the statements in the THEN branch. I will look through my programs tonight, but I am almost positive I rely on this behavior somewhere. Otherwise, there may be something awry in your communication setup. Check the logs and see if you are indeed receiving the non-'ON' command at the ISY but the program is not executing.

I can confirm that Control conditions in the IF statement of a program will only cause the program to run if the device issues the corresponding command. Here is what I suggest: Program 1 'NoOccupancyState' - a "flag" program with no statements. Program 2 'ResetOccupancyState' - resets the 'NoOccupancyState' flag for 24 hours after any motion detected or manual control of the switch: If Control 'Motion Sensor' is switched On Or Control 'Living Room Light' is switched On Or Control 'Living Room Light' is not switched On Then Run Program 'NoOccupancyState' (Else Branch) Wait 24 hours Run Program 'NoOccupancyState' (Then Branch) Else -- No Statements -- Program 3 'NightLightingOn' - turns the living room light on when no occupancy of the room: If From Sunset - 15 minutes To 10:30:00PM (same day) And Program 'NoOccupancyState' is True Then Set 'Living Room Light' On Else -- No Statements -- Program 4 'NightLightingOff' - turns the living room light off when no occupancy of the room: If Time is 10:30:00PM And Program 'NoOccupancyState' is True Then Wait 60 minutes (Random) Set 'Living Room Light' Off Else -- No Statements -- Note that if the 24 hour period expires between Sunset and 10:30, the changing of the status of the 'NoOccupancyState' program will cause the 'NightLightingOn' program to run and turn the light on. Then the 'NightLightingOff' program will clean it up at 10:30. Similarly, if the light is turned on because of no occupancy, but then occupancy occurs (either motion or switch activated), the the 'NightLightingOff' will not run at 10:30 and the light will remain in the state set by the occupant. This seems likle desireable functionality. I tend not to use ELSE statements because of the amount of analysis that is involved in determining when the ELSE statement may execute. Because you cannot seperate trigger events and IF conditions in a program on the ISY, the use of ELSE statements is rarely ideal.

It's not just a matter of understanding it, it's a matter of how limiting it is. If you could specify trigger events separately from IF conditions, it would not only be easier to understand, you could do a lot more in fewer programs. For instance, ELSE branches could become useful. As it is now, they are rarely usable. This is not just my opinion, mind you. I think anyone with real programming experience would agree. I spent years programming Scara robots and telecommunication switches. In any event driven programming environment, you need to be able to specify the events which will trigger the program.

In my opinion, that makes things a whole lot harder. I consider this a flaw in the design of the ISY program environment.

Another issued caused by the lack of ability to seperate trigger events from IF conditions!

Did you have Command 'X' is switched On or Status 'X' is On? There's a difference in how the ISY will respond to the two. The On command can't be "too short" for the ISY to recognize.

Is occupancy mode enabled by software only? I think I have completely missed this feature. Where can I find more information?

There is a simpler way to do this. Set the KPL button to "Non-Toggle-On" and change your program to have the following IF statement: If Control 'Indoor / Foyer / KPL Foyer Right / Right Front Door KPL.A Gate' is switched On Every press of the KPL button will cycle the gate.

I'm not sure what Rand means by 1.1 motion detectors will not support "occupancy mode." The 1.1 motion detectors support the same functionality as the 2.0 detectors, except that the timeout is fixed at one minute and cannot be modified with a potentiometer. I use my 1.1 and 2.0 motion detectors to send ON commands only. This is set with a jumper on the motion detector. On the 2.0 motion detectors, I also set the timeout to 30 secs (full counter-clockwise on the POT 1). In this mode, the 1.1 and 2.0 motion detectors will send on commands every 1 minute or 30 seconds, respectively. The program posted by Oberkc is the simplest and will work in most cases. For example: If Control 'Outdoor / Driveway Motion-Sensor' is switched On Then Set Scene 'Outdoor / Driveway Floods on Motion' On Wait 8 minutes Set Scene 'Outdoor / Driveway Floods on Motion' Off Else - No Actions - If you don't want the program to run (or, more accurately, don't want the light to turn off after 8 minutes) if the light was already on, then you may try this: If Control 'Outdoor / Driveway Motion-Sensor' is switched On And Status 'Outdoor / Driveway Floods' is not On Then Set Scene 'Outdoor / Driveway Floods on Motion' On Wait 8 minutes Set Scene 'Outdoor / Driveway Floods on Motion' Off Else - No Actions - However, you will find this program has a problem: because turning the light on in the program changes the light' status, the program will re-enter and cancel the pending Wait. So the light never turns off. To fix this issue, you need multiple programs with flags (empty programs) and it gets quite complex, even more so if you want to cancel pending waits with subsequent switch usage. You can find examples of it on this site.

How 'bout Program1: If Control 'EntryMotion-Sensor' is switched On And Status 'EntryLights' is Off And From Sunset To Sunrise (next day) Then Run Program 'Program2' (Then Branch) Else - Nothing - and Program2: If Control 'EntryLightsSwitch' is switched On And Control 'EntryLightsSwitch' is not switched On Then Set Scene 'FrontPorchControl' On Wait 3 mintues Set Scene 'FrontPorchControl' Off Else - Nothing -

No, I agree with your assesment. While the scene may not be referenced in another program, could another program be calling the THEN branch of this program? EDIT: Yes, this makes the most sense, because it appears for the log entries that it is not just the scene 'Daily Maintenance / Nightly All-Off' that is being triggered but the entire THEN branch of the 'Nightime All - Off' program that is running.

You are going to need more information Does it always occur 5 seconds after the program executed by the Garage motion detector? If so, we need to see the contents of that program.

I understand your problem, and it is frustrating. The issue is that the keypad button is a controller in the scene (Scene A) that controls the light, and therefore the keypad button status light reflects the status of that scene, not the status of the light. My solution has been to add the keypad buttons as responders to the All Lights scene. A keypad button can be a controller in one scene (Scene A) and a responder in other scenes, such as the All Lights scene. With 4 keypads and presumeably six or seven buttons each, that is a lot of responders in one scene. It should not be a problem, though.

If you want the originally posted sequence, then you are going to have to have two or more status programs, e.g. PanicStage1, PanicStage2, etc. You will have to set each to true with sucessive commands. The other problem that you have, as pointed out by the first responder, is that the first down-down may be two sucessive offs, or a fast-off, depending on how quick they are done, so that adds at least one additional program. So, in pseudo-code, you have: Three status programs with no conditions or code: 'PanicStep1', 'PanicStep2', and 'PanicStep3' Program 'PanicSeqTimer' with the following: If - No Condidtions - Then Wait 5 seconds Run Program 'PanicStep1' (Else Path) Run Program 'PanicStep2' (Else Path) Run Program 'PanicStep3' (Else Path) Else - No Actions - Program 'PanicSeq1' with the following: If Control 'ToggleLinc' is switched off And Program 'PanicStep1' is false Then Run Program 'PanicStep1' (Then Path) Run Program 'PanicSeqTimer' (Then Path) Else - No Actions - Program 'PanicSeq2' with the following: If Control 'ToggleLinc' is switched off And Program 'PanicStep1' is true And Program 'PanicStep2' is false Then Run Program 'PanicStep2' (Then Path) Else - No Actions - Program 'PanicSeq2a' with the following: If Control 'ToggleLinc' is switched fast off And Program 'PanicStep1' is false Then Run Program 'PanicStep1' (Then Path) Run Program 'PanicStep2' (Then Path) Run Program 'PanicSeqTimer' (Then Path) Else - No Actions - Program 'PanicSeq3' with the following: If Control 'ToggleLinc' is switched on And Program 'PanicStep1' is true And Program 'PanicStep2' is true And Program 'PanicStep3' is false Then Run Program 'PanicStep3' (Then Path) Else - No Actions - And finally program 'PanicSeq4' with the following: If Control 'ToggleLinc' is switched off And Program 'PanicStep1' is true And Program 'PanicStep2' is true And Program 'PanicStep3' is true Then - Panic! - Else - No Actions - Not my cup of tea, but it should work. Note that this will detect any 2 downs followed by an up and then a down in the 5 seconds, regardless of other interspersed commands. For example, down, up, down, down, up, up, down in 5 seconds will trigger the panic. You would think the way to remedy this would be to put Else branches in the programs to clear all the status programs if something is out of sequence, but this would introduce a horrendous circular logic issue since you cannot seperate trigger events of a program from IF statement conditions in the ISY programming model.

Try this: If Control 'Guest Bath Vanity' is Switched OFF And Control 'Guest Bath Vanity' is not Switched ON Then Set 'Guest Bath Tub & Toilet' 1% Set 'Guest Bath Toe Kick' 80% Set 'Guest Bath Vanity' 20% Wait 2 hours Set 'Guest Bath Tub & Toilet' Off Set 'Guest Bath Toe Kick' Off Set 'Guest Bath Vanity' Off This should do exactly what you want

Yes, control. That one was freestyle. Normally, if I am suggesting a solution, I will code it up and test it first, to make sure I am not crazy. But in this case, I was just brainstorming on Jack's idea.

Ooh...I like the idea of Fast On/Fast Off enabling or disabling the moiton sensor programs. Expanding on the idea, there may be times when you turn the light on and don't want it to turn off 5 minutes after motion. For example, when I am working on a project in my garage, I turn the light on when I go into the garage, but my entry also triggers the motion sensor. If I sit still for 5 minutes, like tinkering with some part for example, then the light turns off. So you could use both Fast On and Fast Off to disable the program: If ( Command 'Garage Light' is switched Fast On Or Command 'Garage Light' is switched Fast Off ) And Command 'Garage Light' is not switched Off Then Disable Program 'GarageMotion' Else Enable Program 'GarageMotion' This program would allow the light to stay on or off regardless of motion in the room. Further, disabling the program should cancel any running instance of the program that may be in a Wait before a pending Off (for example if motion was detected before the switch was double tapped). A subsequent Off (or any other command) would turn the light off and re-enable the motion program. Very Nice!

One of the things to think about in picking an approach is the quirks in the event-driven programming model of the ISY (yes, the inability to differentiate between trigger events and IF conditions being an imporant one). Your programs need to be clear so you can figure out what you were trying to do six months from now when something starts misbehaving. For me, clarity comes from simplicity; that is why I favor the single program approach with all the conditions for triggering the program and appropriate responses right there in one place. The politically correct thing would be to say each approach has merits, but my aversion to political correctness (and the anonymity of this forum) oblige me to point out that the approach provided above, while I understand how it works, is anything but clear or simple. Further, doesn't the multi-layering of the programs exacerbate the slower response of the ISY program approach to motion sensors over Insteon linking?

Why would you need a seperate program to turn the light off? You want to turn it off 5 minutes after the last motion (the last "switched on"), right, regardless of what motion detector sent it? Rand's three programs allows the light to be turned off after the last Off is received from one of the motion detectors. This really doesn't make any sense, in that it would depend on the respective settings of the motion sensors and then add five minutes to it for the off. Simply jumper the motion sensors to send Ons only and set the pot for the timing all the way counter-clockwise. The motion sensors will send Ons every 30 seconds while motion is detected. With the single program suggested above, the light will turn On on first motion from either sensor, and then will turn off 5 minutes after last motion is detected by either detector.

TechGuy, You are right. This seems most practical to implement as a single program. The second of your programs is the way I would implement it, and should work just fine, except for one catch: If the program is running, and sunrise occurs, then it will stop running, and you may miss the off. In other words, if motion triggers the light less than 5 minutes before sunrise, then the program will turn the light on. However, because you cannot differentiate between IF conditions and triggering events in the ISY programming model (a serious limitation, IMO), the program will be triggered again at sunrise, cancelling the current running program (which is waiting for 5 minutes to send the off) and executing the ELSE portion of your program. So you can do the three programs and folder conditions that oberk suggested, or simply have one additional program that cleans up your outdoor lighting at sunrise. Because this situation arises a lot in my outdoor lighting programs, I have one program that turns off all outside lighting at sunrise to account for this "boundary condition."

The SHN Utility Suite and SmartHome drivers run on Windows 7 just fine. However, I have a 2414 PLC and not a 2412U PLM. I do not have to set any COM port address, it justs finds the PLC and connects.

Because of the programming architecture of the ISY, you will find that using ELSE is rarely the right solution. This is something I have complained about for a long time (trigger conditions vs. IF conditions), but there doesn't appear to be any improvements coming anytime soon.