Goose66

But everything is NOT an event. Currently everything is (inherently) an event AND a condition. For instance, consider the following: If Control 'Motion 1' is switched On And From Sunset To Sunrise (next day) Then - No Statements - Else - No Statements - This program will run when 'Motion 1' is switched On, at Sunset, and at Sunrise (trigger events). However, when 'Motion 1' is switched On, the program runs, and the "IF time is between Sunset to Sunrise" is evaluated to determine if the THEN branch or ELSE branch statements are executed. Similarly, at Sunset and Sunrise, the program always falls into the ELSE branch because If Control 'Motion 1' is switched On condition evaluates to False. I don't claim to have any knowledge of how the ISY code works, but from looking at the XML that stores the programs, it seems that, upon initialization, the IF conditions in each program are read from the program XML and an event table is compiled in memory for each program. Perhaps this is the event queue to which Michel refers. In addition, when the event queue is built, there is some inferring that takes place. For example, if the condition is "If Status 'Device 1' is On," then the actual event placed in the queue is likely "Status of 'Device 1' changes." Similarly, if the condition is "If Control 'Motion 1' is not switched On," the event is "Control 'Motion 1' On received." What I am saying is get rid of the inferring for events from the conditions in the program XML that take places during initialization, and store the events along with the conditions in the program XML. The user interface would be changed (as demonstrated above) to allow a user to specify both trigger events and IF conditions seperately. Upon initialization, the ISY would just read the trigger events into the event queue (no inferring necessary). I realize it seems like a "wholesale change," but it seems to me the amount of change is actually quite small. The only other thing that would have to be done is a script (or XML transform) would have to be written to pull the events from the current IF conditions and store them in the program XML when upgrading an ISY from the current version to the new version containing the new programming model. The other thing that I disagree with is this idea that we are advocating for this because we want more flexibility or functionality for the ISY. In fact, I am advocating for it because I believe it is a better design that will remove a lot of confusion from both new programmers and those coming from other, similar environments, like HomeSeer. It will make the product better for everyone, IMO, not just "advanced programmers."

Here's an expansion on the seperate section idea:

I just have to disagree, here. Thread after thread in this forum has programmers asking "what went wrong" in the case where the program was initiated at sunset because "If From Sunrise to Sunset" or on the change of status of device X because of "If Status 'Device X' is off." There is nothing about the statement "If Status is Off" that implicitly suggests "Run this program when the status changes" in the mind of a non-programmer. However, if the program read "When Status 'Device X' Changes, IF Status 'Device X' is Off Then," well, that just makes sense to everyone.

Ah, got it. I think that a simple backend change to the program storage XML structure and triggering of programs would be easier than a complex UI change. Of course, I have always hated UI programming and prefer back-end stuff. EDIT: OK, now that I look at it again, its not really complex at all. Not bad, but you still have two programs. Maybe a programming naming convention (which I think you referred to earlier) could pseudo-hide the fact that there are two programs involved.

Is all this really easier than a separate section for triggers?

Look at the last couple of posts in this thread: http://forum.universal-devices.com/viewtopic.php?t=5681

I was thinking of something like this: http://cid-9429f89896e797d8.photos.live.com/self.aspx/Public%20Folder/ISY%20UI%201.png For those that cannot view this picture, here is the jist: When Control 'Outdoor / Driveway Motion-Sensor' is switched On If From Sunset To Sunrise (next day) And Status 'Outdoor / Driveway Floods' is Off Then Set Scene 'Outdoor / Driveway Floods on Motion' On Wait 8 minutes Set Scene 'Outdoor / Driveway Floods on Motion' Off Else - No Actions - (To add one, press 'Action') You would put a "Trigger" button down below in conjunction with the "Condition," "Action," and "Comment" buttons in the interface below (I think the "Schedules" button/interface should be absorbed under "Triggers" and "Conditions"). You wouldn't have to write your conditions twice, because most often your triggers and conditions would be seperate. For example, a condition of "Time is 4:30 PM" in the current model would just become a trigger, because it wouldn't make sense to test for this in the IF once the program was triggered, in most cases. Note that this is an ideal implementation, that provides maximum flexibility and ease of understanding, in my (humble?) opinion. That being said, I would be exceedingly happy with the checkbox!!!!

A more intuitive option would be divide the sections of the UI. One section to specify trigger events for the program, another to build the IF statement (which wouldn't change much). As far as the guts of the ISY, it's being done inherently, so making explicit should simplify things in the code, but may add to the XML used to save each program. In addition, a very simple, one-time-execution method of transforming the XML for existing programs upon upgrading could be devised that would pull out the trigger events inherent in the programs and explicity list them in the trigger events, thus no ones programs would break upon upgrading. It would be a definite improvement to the ISY, IMO, and a little bit of near-term pain for longer-term benefit. Using two programs (one disabled) is doable, but unless you use two programs in every case, you don't really get the overall simplification to the programming model that would come with actually splitting the specification of trigger events and IF conditions. OK, I've beaten this (possibly dead) horse to death. I suggested this in the suggestions section a year ago. It is there if they ever want to do it, and I would be glad to provide whatever assistance to its implementation, including interface design (I believe in the ISY that strongly). But, I'm ready to move on.

I think you understand it but your preference is to continue to use it. That's fine. ELSE clauses are confusing in the ISY programming model because every condition in the IF statement implies a trigger event for the program, and that may not be clear to the novice programmer. So the novice programmer may find that the ELSE clause of their programs are being executed at unexpected and inappropriate times. I consider myself not to be a novice programmer, but I probably use ELSE clauses in 1 out of 15 ISY programs because of this behavior. It is my preference. It is my contention that if trigger events and IF conditions were seperated, I would use ELSE statements much more often, I would probably have half the number of programs I have now, the programming model would be much less limiting, and the whole thing would be cleaner and easier to understand.

Its "use" seems to be limited to create trigger events for a program with the evaluation of the corresponding IF statement forcing programs into the ELSE branch. This is the epitomy of the confusion caused by combining trigger events and IF conditions into a single statement. Since ELSE branches are basically useless in the ISY model, I agree with Rand that two programs is a simpler and more effective approach. I think most "super awesome ISY programmers" would agree, as well.

No offense. Just frustration.

Someone finding a use for it doesn't make it "useful." I agree with the assesments of others that this completely counterintuitive and I see very little use for it. But they can leave it in there, it doesn't hurt anything. However, I think someone may want to request a new condition for control: 'If Control 'Device' is switched Any." I would request it, but it seems my requests/suggestions are always answered by "here is how you can accomplish it using five different programs in the current ISY model."

Well, it may not be a bug, but it is not very useful. Again, I have to jump through a lot of hoops to make the simple trigger event "Any command received from 'Device'" take effect. I understand this. I think it is clear from my posts in this topic that I understand this. My point is that I shouldn't have to. UD's response to every post I have submitted on this subject has shown a clear lack of understanding of the point I am trying to convey (from lack of reading, not lack of intelligence, I imagine). I guess I just need to shut up and use the product as is until I find something better.

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.