apostolakisl

I had to change the "gaps" setting to 3 to get codes to work properly on my dish vip 622. I figured this out by trial and error. I wish I could help you out more, but I just haven't been able to find any good descriptions of exactly what the various settings change and when you might want to change them. You could also look at remotecentral.com and see if they have your unit in hex format. Global cache has a program that will convert it to their format.

Yes, I am quite certain I had deleted at least a couple network resources prior to doing the backup from which I did the restore. Keep in mind that the "restore" part was not a simple click "restore" and go.

Michel, I thought you might like to know the follwing: I don't know what the ID numbers were to start with, but I do know that I had deleted some which my recollection tells me should have left empty ID's. After the restore, the id's are now contiguous. The programs that referenced network resources all refrenced the wrong ones after the restore. Thanks, Lou

After moving a bunch of switches around and replacing a bunch of bad switches with new ones I found things to be not quite right. I went through the house and did a factory reset on every single device then a "restore devices" from the file menu which rewrites all of your devices. I also restored my PLM. The factory reset is a sure fire way to remove all links in a device and the 'restore devices" makes the reprogramming somewhat easy. It is a very time consuming thing to do as it can take hours for ISY to rewrite everything (depending on the size of your install). During those hours the ISY won't respond causing great anxiety. But when it finished everything worked well again.

Michel, Yes, first I ran restore, the system hung and after about an hour I task managed out of it and re-opened ISY. The network resource tab was empty at that point. I tried again, same result. I tried from a different computer, same result. I tried a hard reboot of ISY, same result. The only difference was that sometimes it would load a variable amount of the contents of network resources before hanging. I have 90 items and it might load 6, or 36, but then would freeze up and never finish. At this point a task manager exit of ISY and re-open of ISY would still be blank at network resources tab. I did try doing "import" on one of those tries to see if I could import that backup file, but that one failed the same as the others. Finally I had success on about the 10th try. I don't know why it worked becuase I just kept doing the same thing each time (I like beating my head on the wall). I suppose it is possilbe that I hit "import" instead of "restore" on that last try but I am 99% sure that I didn't.

Yes, 2.8.10. And I definitely did a restore, not import.

I need to emphasize to anyone following this thread that the you do have this today, it just requires 2 programs. The issue being addressed in this thread is not functionality, but user interface, in that requiring multiple programs seems cumbersome to many. This is exactly the point I was trying to make with my early post with the big giant photoshoped screenshot that is making this thread so hard to read! (sorry). ISY is 100% capable of having non-trigger conditions and trigger conditions right now exactly as is, it just need two programs. A relatively simple solution to this (I think), is for the guys at UD to manipulate the user interface such that two programs are merged into what appears to the user as one program, hiding the non-needed items. Since the ISY language would not be changed, there is no risk of introducing bugs where there were none. Edit. .. woooohoooo, pushed it to a new page so the super wide screen is gone.

Also now I see that doing a restore doesn't assign the network resources the same id so my programs have gotten scrambled. I think that is something that you might want to look at fixing in future firmware upgrades.

After about 10 tries it worked. Not sure what is up with that.

I made some changes to my network resources and it wasn't working like I wanted so I went to restore from a backup of network resources I made before the changes. Upon doing the restore, the system hangs. I have an hourglass and no ability to do anything. I can't log off or anything. I have to use task manager to exit it. When I go back to it, the network resources is empty. I tried adding new files manually and it works. But, the restore function once again hung it up. I tried rebooting the computer and the ISY, same result. I know the backup is good because I had sent it to Michel to look it over and he was able to open it. When I activate the restore, the items I had start to show up, not all of them, but at least a few. Some of the times I tried the restore most would show up, other times only a few, but regardless, it hangs after that. What should I do?

You are correct. But when the words "trigger condition" and "non-trigger condition" are presented to you every time you go to write a program, you can't help but figure it out quickly and remember it easily after a programming hiatus. It sure is easier than trying to explain the concept of writing two programs, disabling one of them (but still understanding that a disabled program will execute when called by another program).

The good news is that all of this can be done manually at present without a great deal of extra work. If you create a folder and put the two programs in one folder it will assist in keeping track of things when you come back a year later or whatever to edit it. Just consider the second program's "if" conditions to be an "and" extension of the first program's (except that they aren't triggers).

It would be best if the two programs were saved under one filename so the user never even realized there were two programs there at all.

That is what this is. I was just pointing out how the ISY programmers could implement this without changing ISY logic at all. The end result is exactly that. I uploaded to imageshack.com and used the "direct link" url.

Not to be outdone by ostrypuch, I have photoshoped up a diagram. What you see here is the user console. It is actually two programs but ISY shows it to the user as one program. The highlighted areas would not be shown to the user but would still exist on the back end.

The logic already exists in ISY (you can create the exact same results by using 2 programs). What it would require is the ISY developers creating the programming interface such that, hidden in the brains of ISY, the multiple program language is written based on the logic expressed in the above faux screen shot. I hope that sentence made sense! So, specifically, when you uncheck that box, ISY internally creates two programs. -The second program contains the if/then/else where the "if" stuff is not the trigger. This program is internally disabled (but it wouldn't show you that). -The first program contains the "trigger" in the "if" section and the "then" section says "run if statement on second (disabled) program". But ISY only shows you the "if" section of the first program (but lables it "trigger") and the entire second program as per usual.

Using the little boxes and having them default to checked means, that for the most part, programming ISY would be exactly the same as currently. Unchecking the boxes would be available to those who want to venture into it. And I think I may have made it too complex to have a "condition" box and "trigger" box since I can't think of any logic that would allow something to trigger a program and not at least be an "or" condition. So just one box needed, a "trigger" box. Using a separate "trigger" section would require that you have to write your conditions twice for the majority of your programs. It would sort of be like the current situation where you use two programs. Along those lines, perhaps a solution to this issue that wouldn't require redoing the logic of ISY, would be to allow opening multiple associated programs at once on the same screen. It would be easier to keep track of what you are doing in the current scheme if you could see both your trigger program and execution program at once.

That would be very nice. Two little check boxes next to each item 1) use as trigger, 2) use as condition. They would default to being checked. My suspicion is, however, that doing this would be like throwing a gigantic monkey wrench into the guts of the ISY code.

Actually that was me with "super awesome ISY programmer" comment. Anyway, I thought I would summarize this "control is not" and compare to "is". Tiggering "control is" and "control is not" both act as triggers for a program exactly the same. For example, "if switch xyz is (or is not) switched on" acts as a trigger only when the switch is physically acted on by pushing "on". Evaluation 1) When the "control is/is not" statement is the trigger - "is" evaluates to true - "is not" evaluates to false (keep in mind that only physically acting on the switch in the way listed (ie "on") is a trigger, any other action on the switch is not a trigger and the program will sit idle short of some other independent trigger. 2) When something else triggers the program - "is" evaluates to false - "is not" evaluates to true (keep in mind that the status of the switch is irrelevant, on/off/dimmed/whatever. . .no difference) Simply put, "is" and "is not" behave exactly the same except the outcome (true/false) is opposite. So, it seems the usefullnes of an "is not" statement is to have the program evaluate to the opposite state as an "is" statement when presented with the exact same trigger. In a single line program simply swapping the "then" contents with the "else" contents is functionally identical to swapping "is" with "is not". In a multi-line program it might be easier to get the outcome you want using "is not" so that your "true/false" outcome more easily jives with the "true/false" outcome of the other conditions. I can not think of a situation where "is not" allows for an ultimate outcome that you couldn't get to in some other way, but, there it is, use it if you like it.

Here is the most important unique feature that I can see with the "control is not" It evaluates to "true" when nothing is done to the switch. In other words, if something else triggers the program it will evaluate as true (this is why it worked the same in the "and/or" situation previously discussed). This is in contrast to "control is" which evaluates as "false" when something else triggers the program and no action is taken at the switch. I am not sure how to use it exactly, dnr had pointed out that the there is no use for a statement that is always "false" (I agree), but we were wrong, this can be "true". I have a feeling that you could use this feature to turn what otherwise would have been two programs into one. It would probably not be worth the confusion, however, unless you were just super awesome ISY programmer.

I think theoretically at exactly 7:44 it would behave differently. If you used "or" and managed to turn the light "on" at the exact same instant as the clock hit 7:44 it would evaluate to "true" instead of "false". But I think that is only theoretical because I am not sure that ISY can process 2 things as happening exactly at the same time.

OK, now I don't get it. By my understanding this program should be false always. My new understanding is the "is not" terminology allows a "true" outcome if no action is taken at the switch and a second statement is "true". Would this program run differently if you used "or" instead of "and"?

dnl, "What is the intended purpose of a condition that can only evaluate to False?" The only possible purpose would be as a trigger of that program. In the event that you use an "or" statement with an "is not" control and something else, it will allow a "true" result if the other statement is true and a false outcome if the other statement is false. So, if you had some situation where you wanted the true/false status of the other statement to drive the result after controlling a switch to a particular state, this would do it. I can't think of when I would need that, but it is the only situation I can think of that the "is not" would be helpful. But, you could still get that same result by having two programs where the first program contains "if xyz is switched on" "then run the other program" were used. In short, I totally agree with you in that "control . . .is not" is poorly conceived. Edit: I just realized you can use "control . . is" combined with another statement using "and" to allow controlling of the switch to a particular state to trigger a program where the other parameter is in charge of the "true/false" outcome. So I now believe that there is no use for the "is not" in a control program at all.

I think dnl is right on the money here. In effect, this syntax creates a situation where using "is not" or "is" simply changes whether you put the desired action in the "then" or the "else". Except during the actual button press, "control" commands are always false whether you use "is" or "is not". This means that having the "is not" language does not affect a program differently than "is" language in the event that something else triggers it. So I am having a hard time figuring out when using "is not" would ever provide a function that can't also be done using "is". "is not" would be useful in the event that any action taken on the switch allowed for evaluation of the statement and a "true" response in the event that it were anything but the stated parameter (on, off, whatever).

Here are some sample programs and what happens. If Control 'Kitchen / Kitchen Intercom/Puck L' is switched On Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched On Then Send Notification to 'dr-apo' content 'then' Else Send Notification to 'dr-apo' content 'else' The above executes the "then" clause when you turn the switch "on". It does nothing when you switch the light "off" If Control 'Kitchen / Kitchen Intercom/Puck L' is not switched On Then Send Notification to 'dr-apo' content 'then' Else Send Notification to 'dr-apo' content 'else' the above executes the "else" statement when you switch it "on" Does nothing when you switch it "off. This follows with the logic as described by IndyMike. Not to be confused with If Status 'Kitchen / Kitchen Intercom/Puck L' is not On Or Status 'Kitchen / Kitchen Intercom/Puck L' is On Then Send Notification to 'dr-apo' content 'then' Else Send Notification to 'dr-apo' content 'else' Which executes the "then" no matter what you do to the switch. Of course it also executes the "then" if anything changes the status of the switch, not just physically pushing it. The following executes the "then" no matter what you do to the switch. If Control 'Kitchen / Kitchen Intercom/Puck L' is switched Off Or Control 'Kitchen / Kitchen Intercom/Puck L' is switched On Or Control 'Kitchen / Kitchen Intercom/Puck L' is switched Fade Down Or Control 'Kitchen / Kitchen Intercom/Puck L' is switched Fade Up Or Control 'Kitchen / Kitchen Intercom/Puck L' is switched Fast On Or Control 'Kitchen / Kitchen Intercom/Puck L' is switched Fast Off Then Send Notification to 'dr-apo' content 'then' Else Send Notification to 'dr-apo' content 'else' And this also executes the "then" no matter what If Control 'Kitchen / Kitchen Intercom/Puck L' is not switched Off Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched On Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched Fade Down Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched Fade Up Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched Fast On Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched Fast Off Then Send Notification to 'dr-apo' content 'then' Else Send Notification to 'dr-apo' content 'else'