Goose66

Setting the scene ON turns on all devices to their preset ON levels and preset ramp rates. Setting the scene OFF turns off all devices.

Is there a PC in your vacation home? You could add a program to the PC that when the phone rings 6 times (or get distinct ring feature), turn around and connect to the Internet via a modem and register the IP address through dynamic DNS service. So you would call your house, wait a minute or two, and then access the PC and/or ISY over the Internet through a registered DNS name.

A little less clumsy may be to put a "Run Program 'DoSomething' (Else Path)" as the very last statement of your THEN branch. That way, the Status of program 'DoSomething" will only be True if the THEN branch is running.

Short answer: No If you don't want to use the programs as states (i.e. call their ELSE branch to set them as false), then you are out of luck. With a variable, you could just set the variable to an increasing value for each program, with the variable indicating the current state. But the ISY doesn't support variables.

I definitely recommend changing your ports, at least as far as the outside world sees them. I always set ports up in my firewall anywhere from 20,000 to 64,000 randomly and port forward them to internal IP addresses and ports. Sure the open ports could be discovered by a complete port scan of my firewall. But that would take time and mean that someone was targeting me directly. Hard core hackers scanning ports on the Internet may only scan the first 1024 ports, and most simply scan the 20 or so well-known ports, including 443. If they get no response from the well-known ports, they move on (quickly) to the next IP address.

Why not set the local On level to 30% and the ramp rate to 1 sec. Then add the following program: If Control 'Son's Room Lights' is switched On And Sunrise + 30 minutes To 8:30 PM (same day) Then Set 'Son's Room Lights' Fade Up Else -- No Statements -- in the one second that it takes the light to go to 30%, the program should run and start the light fading on up to 100% at the same ramp rate. Should be fairly smooth. Alternativey, in the program you could just Set 'Son's Room Lights' Fast On to take it immediately to 100%.

I think your question revolves around the fact that while WAITing, if the program is triggered again, the WAIT is cancelled and any following actions are not taken, in favor of the entire program running again with a reevaluation of the IF statement. What this thread is about is what will actually cause the program to run (or run again). So for instance, in your example, if the light is turned Off and the fan is running, the program will wait 10 minutes and turn the fan off. However, if someone manually turns the fan off, i.e. the Status of 'Kid's Bathroom Vent' changes, the program will run again, cancelling the pending WAIT and the subsequent Off command. This time, the program's IF condition will evaluate to FALSE, because the Off for the 'Kid's Bathroom Light' was not received, and the ELSE branch will be executed. In your example, this is not a bad thing, since the fan was turned OFF, cancelling the WAIT and subsequent OFF command doesn't affect anything. However, I am sure you can imagine examples where having the program execute when the Status of a device changes would be a bad thing. That is what we are talking about. We want to be able to tell the ISY to run the program when the OFF for the 'Kid's Bathroom Light' is received, and then check the status of the 'Kid's Bathroom Vent' in order to decide whether to run the THEN or ELSE branch, but NOT run the program when the status of the 'Kid's Bathroom Vent' changes. In other words: When Control 'Kid's Bathroom Light' is switched Off If Status 'Kid's Bathroom Vent' is On Then Wait 10 minutes Set 'Kid's Bathroom Vent' Off Else - No Actions - (To add one, press 'Action')

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.