oskrypuch Posted January 6, 2011 Posted January 6, 2011 There have been occasional discussions here (in my extensive archival reading) about the reported initial confusion, as well as lamenting about the programming limitations, given that all items will trigger a program IF statement program to ®evaluate. I appreciate that this reflects the non-procedural nature of the environment, but even in this event driven milieu it would allow for more flexibility if one could have your cake and eat it as well. I would propose, and of course this is a "big" request, perhaps a version 3 item, that you create a toggle that by default would result in the current logic, but with it unticked in a given program statement, it would allow for specifying and narrowing the items that could trigger the program. It may also be that you could widen the catchment, by specifying triggers that are not actually included for evaluation in the program. Here is what it might look like ... Of course the Trigger condition could be allowed to be more complex, much as the evaluations in the IF statement current. THEN, if you could sprinkle in some varables ... Trigger ON ( (month = 6) and (away = true) and 'BTH Light is switched ON') Oh my! With all that in place, the "ELSE" clause becomes much more useful as well. Thoughts? * Orest
oberkc Posted January 6, 2011 Posted January 6, 2011 as well as lamenting about the programming limitations, given that all items will trigger a program IF statement program to ®evaluate. Given that one can already separately specify triggers and conditions (disable the condition program, write a separate program for triggers), the question seems to me to boil down less about program limitations and more about intuitiveness and user friendliness.
oskrypuch Posted January 6, 2011 Author Posted January 6, 2011 more about intuitiveness and user friendliness. ... which is a laudable goal as well. It is the same with variables, I have a number of programs set now labelled ... var home var civil day var sleeptime ... and set/reset them with Program Run IF/ELSE statements. That will work, but is a bit clumsy in terms of syntax and readability. DON'T GET ME WRONG, I am very happy ISY as it exists now. It is a very flexible interface, and can certainly get the job done, but that doesn't mean that it can't be improved a bit as well. In the end, it is a matter of how many developer hours there are in a day. Perhaps this can be packaged in a "Pro+" version, with a small upgrade charge, or maybe there just isn't enough general interest to spend time on it. * Orest
oberkc Posted January 6, 2011 Posted January 6, 2011 which is a laudable goal as well. Indeed, it is. I just wanted to make sure you were not laboring under a false pretense.
apostolakisl Posted January 6, 2011 Posted January 6, 2011 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.
Goose66 Posted January 6, 2011 Posted January 6, 2011 Look at the last couple of posts in this thread: http://forum.universal-devices.com/viewtopic.php?t=5681
apostolakisl Posted January 6, 2011 Posted January 6, 2011 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.
Goose66 Posted January 6, 2011 Posted January 6, 2011 Is all this really easier than a separate section for triggers?
apostolakisl Posted January 7, 2011 Posted January 7, 2011 Is all this really easier than a separate section for triggers? 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. Also, how did you get the image in your post. My attempts using the image tag with a working URL don't work. I uploaded to imageshack.com and used the "direct link" url.
Goose66 Posted January 7, 2011 Posted January 7, 2011 I was just pointing out how the ISY programmers could implement this without changing ISY logic at all. 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.
apostolakisl Posted January 7, 2011 Posted January 7, 2011 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.
oskrypuch Posted January 7, 2011 Author Posted January 7, 2011 The one thing that is critical, if such a change is considered, is to ensure that the default instance directs the prior logic, otherwise of course you will break most every non-trivial program statement. But having the ability to selectively add trigger statements in some fashion to each program clause, will surely enrich the environment, perhaps make it more intuitive, and ease the ability to write easy to follow program statements. It should also reduce some of the newbie gotchas, eliminating unexpected (ill understood) program execution or non-execution, and the whole ELSE clause thing. * Orest
apostolakisl Posted January 7, 2011 Posted January 7, 2011 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).
Chris Jahn Posted January 7, 2011 Posted January 7, 2011 This is an interesting thread, and I have gone down many of these design paths myself. When we prioritize a change to the programs interface it will address these issues. The one thing that is critical, if such a change is considered, is to ensure that the default instance directs the prior logic, otherwise of course you will break most every non-trivial program statement. You are correct, any change will be compatible with existing programs.
oberkc Posted January 7, 2011 Posted January 7, 2011 It should also reduce some of the newbie gotchas, eliminating unexpected (ill understood) program execution or non-execution, and the whole ELSE clause thing. I must count myself among the skeptical regarding this point. While it appears that this may add some flexibility for the advanced user, and may make the ISY more consistent with other advanced programming languages one may be used to, it does not reduce the level of understanding required. On the contrary, I see this as potentially adding one more thing that can go wrong. Example new thread: Hey! Newby here. I just tried writing a program and nothing is happening. Help! One still must understand the concept of triggers and conditions. One must still understand the existing defualt triggers. No....I don't see this forum going out of business any time soon. It is just that the questions will change.
Goose66 Posted January 7, 2011 Posted January 7, 2011 While it appears that this may add some flexibility for the advanced user, and may make the ISY more consistent with other advanced programming languages one may be used to, it does not reduce the level of understanding required. On the contrary, I see this as potentially adding one more thing that can go wrong. 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.
Goose66 Posted January 7, 2011 Posted January 7, 2011 Here's an expansion on the seperate section idea:
oberkc Posted January 7, 2011 Posted January 7, 2011 However, if the program read "When Status 'Device X' Changes, IF Status 'Device X' is Off Then," well, that just makes sense to everyone. I don't disagree with this either, but your proposal for a wholesale change in criteria wording is not (as near as I can tell) part of the proposal to which I was responding.
apostolakisl Posted January 7, 2011 Posted January 7, 2011 One still must understand the concept of triggers and conditions. One must still understand the existing defualt triggers. No....I don't see this forum going out of business any time soon. It is just that the questions will change 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).
oskrypuch Posted January 7, 2011 Author Posted January 7, 2011 This is an interesting thread, Well thanks. ...and I have gone down many of these design paths myself. When we prioritize a change to the programs interface it will address these issues. And thanks! * Orest
oberkc Posted January 7, 2011 Posted January 7, 2011 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). Easier is in the eye of the beholder, I guess. I am just not percieving any of these changes as so. To me, these are just different ways of achieving the same goal...no easier or harder to understand. Sorry...I am having trouble getting excited about this type of change. People have told me that different opinions are what makes the world interesting. In my mind, too, if you are sufficiently advanced to desire (or even understand the purpose of) separate triggers, you are sufficiently advanced to understanding existing trigger mechanisms. This change is not going to benefit those who have no clue about programming (in my mind, at least). But I enjoy discussions on these topics. I guess we will see if, and how, Universal Devices responds.
Michel Kohanim Posted January 7, 2011 Posted January 7, 2011 Hi guys, First of all, thanks so very much for the lively discussion without the types of which we wouldn't have been able to improve on ISY's functionality. The main problem is that for ISY everything is an event. All events are queued up and sent for evaluation. Based on what kingwr is saying, we should now have a separate event class called trigger. In this scenario, it's the trigger that DECIDES whether other events should be evaluated. At a high level this makes sense to those of us with programming experiences and it's kind of like: If (x) then switch (other evaluations) else switch (some other evaluations) From an implementation perspective, though, this has some major regression testing ramifications and might not be as easily backward compatible with previous programs. Of course, we would have to do more investigation on it. Since we are doing variables. we might look more closely into this request and see what we can do to make things more consistent. Again, thanks so very much and with kind regards, Michel
Chris Jahn Posted January 7, 2011 Posted January 7, 2011 ... I must count myself among the skeptical regarding this point. ... The last thing we want to do is complicate the existing interface, therefore any changes we consider would have to contain additional function that you just don't have right now. The main problem is that for ISY everything is an event. All events are queued up and sent for evaluation. Based on what kingwr is saying, we should now have a separate event class called trigger. In this scenario, it's the trigger that DECIDES whether other events should be evaluated. I don't think he is calling for new events at all, just another mechanism for recognizing the existing events. The goal for many of these suggestions is to make it easier to separate conditions that trigger the program vs conditions that do not trigger the program.
Goose66 Posted January 7, 2011 Posted January 7, 2011 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."
ergodic Posted January 8, 2011 Posted January 8, 2011 People DO intuitively understand the concept of conditions and triggers. But they understand them - quite correctly - as two entirely separate concepts. And therein is exactly the problem. Unfortunately the current ISY model and syntax largely conflate the two, making it difficult to write even modest programs. All you have to do is look at the various 6-page posts here discussing how to turn lights on and off with motion sensors to recognize the problem. You can do anything with a Turning machine or assembly code or directly enter the binary p-code the ISY generates internally. Anything beyond that is I suppose 'friendliness.' But obviously most people couldn't. Or wouldn't bother even if they could. Which is to say: there are points where 'friendliness' becomes a synonym for useability. So to me, and I happily presume from this post many others, almost ANY change that provides concurrent conditionals and event triggers of equal stature in the ISY programming would be most welcome. If for no other reason simply than it comports with the way people generally think about these things. Variables certainly would be useful, but to me they are definitely second on the list.
Recommended Posts