3PNTSTech Posted January 1, 2014 Share Posted January 1, 2014 Hi Everyone, Question for you... bit of a strange one if you ask me. It was working a few days ago after not working at all, this occur just after I prucahsed the network moduel for my ISY. I have this program If Elk Zone `Back - Walk Door` is violated and Control `Patio Switch` is not switched on Then Set `Patio Switch` On Wait X Minutes Set `Patio Switch` Off Else Blank Now a few weeks ago it was working fine, as many months of not working. so I'm not sure what the issue is. I open the Walk Door, it triggers the lights and the light go on. After X minutes the lights are still on. Program is Activity "Idle" Status "False". I have some similar, but nothing that is tied to my ELK system thou, but they are all working as they shoot. Open Door, Triggers, Light, Lights stay on for X minutes, then turn off etc. I thought it would be communication, and or device. So I tried deleting, Renaming, re-installing, but nothing seems to fix the issue. Not even sure why it stated working after so long that it didn't. I just gave up on it to be honest. Any suggestion or thoughts would be greatly appreciated. Kevin Link to comment Share on other sites More sharing options...
LeeG Posted January 1, 2014 Share Posted January 1, 2014 The Wait allows the Program to be reevaluated when the door is no longer violated. The If is now False so the Else clause runs, bypassing the statements after the Wait. Simple solution is to make two Programs. The current Program Then section invokes Program 2 which has a null If and a Then with the current Then logic. This way when the door is no longer violated the reevaluation of Program 1 does not affect Program 2 Wait. Link to comment Share on other sites More sharing options...
3PNTSTech Posted January 2, 2014 Author Share Posted January 2, 2014 The Wait allows the Program to be reevaluated when the door is no longer violated. The If is now False so the Else clause runs, bypassing the statements after the Wait. Simple solution is to make two Programs. The current Program Then section invokes Program 2 which has a null If and a Then with the current Then logic. This way when the door is no longer violated the reevaluation of Program 1 does not affect Program 2 Wait. Yeah I figured you guys were going to mention that. However, how do I that when... oh wait, I'm thinking now. Ok i'll try something. I just figured it would work normally like all the other features... but maybe because of the Wait feature it doesn't act like when it has a insteon product. Kevin Link to comment Share on other sites More sharing options...
LeeG Posted January 2, 2014 Share Posted January 2, 2014 Wait works the same regardless of what conditions the If is checking. If the condition(s) change while in the Wait (or Repeat) the If is reevaluated. Here is the link to the Wiki section that covers the Wait http://wiki.universal-devices.com/index ... EON:Action Link to comment Share on other sites More sharing options...
3PNTSTech Posted January 2, 2014 Author Share Posted January 2, 2014 Awe, figured it out. Just need to wrap my head around these IF, Then, Else statements... Still not sure why this program is running differently then my other ones. As I have about 5 other that run Insteon devices and this type of program works fine, the only difference is the IF "Elk" statement. The rest is all the same. Thanks guys. Kevin Link to comment Share on other sites More sharing options...
LeeG Posted January 2, 2014 Share Posted January 2, 2014 The door changes state when it closes. Likely an Insteon device is not going to change state on its own. Link to comment Share on other sites More sharing options...
madcodger Posted January 2, 2014 Share Posted January 2, 2014 I just feel a need to comment that this WAIT is one of the most aggravating and illogical aspects of the ISY. For some of us who started in HA with other products (HomeSeer for me) the need to create TWO programs to do something this simple just seems silly and illogical. If you read the OP's program you can easily see exactly what is desired, yet the ISY can't easily accomplish it. Even if it took creation of something other than WAIT, it would be helpful if there was a command that would just create a delay before the next line was executed, regardless of the changes in state of the IF as currently required for the WAIT command. Just sayin'... Link to comment Share on other sites More sharing options...
bsobel Posted January 2, 2014 Share Posted January 2, 2014 There are quite a few requests for the ability to either have a different command or a check mark on the wait to indicate 'do not evaluate' As implemented its a very powerful feature but it is confusing. Link to comment Share on other sites More sharing options...
Michel Kohanim Posted January 2, 2014 Share Posted January 2, 2014 Hi madcodger, As much as I didn't want to respond but I feel compelled to posit our point of view: 1. Just because one got used to some other form of programming does not make ISY illogical. I suspect HS is doing a lot of things that seem illogical after one is accustomed to ISY 2. Having an atomic-wait is an interesting idea and we'll consider With kind regards, Michel Link to comment Share on other sites More sharing options...
apostolakisl Posted January 2, 2014 Share Posted January 2, 2014 I just feel a need to comment that this WAIT is one of the most aggravating and illogical aspects of the ISY. For some of us who started in HA with other products (HomeSeer for me) the need to create TWO programs to do something this simple just seems silly and illogical. If you read the OP's program you can easily see exactly what is desired, yet the ISY can't easily accomplish it. Even if it took creation of something other than WAIT, it would be helpful if there was a command that would just create a delay before the next line was executed, regardless of the changes in state of the IF as currently required for the WAIT command. Just sayin'... Sometimes having a wait interrupted is perfect. For example, I have lots of doors that when I open them at night, the outside light turns on, then 5 minutes later it turns off. But if I open the door again, say 4:59 later, I want the 5 minute wait to restart. If the wait didn't re-start, then that would be an issue. . . the light would shut off in 1 second. Now the fact that the door closing causes the wait to terminate does require two extra lines of code, but not an extra program. It is the last 2 line after the "or" Here is how I do it: If Control 'Family Room / Family Rm-Pat lts L' is not switched On And ( ( Elk Zone 'Family Rm Door' is Violated And Status 'Family Room / Family Rm-Pat lts L' is Off And Program 'Dark Outside' is True ) Or ( Program 'Patio Door' is True And Status 'Family Room / Family Rm-Pat lts L' is not Off ) ) Then Set Scene 'Patio Lts S' On Wait 5 minutes Repeat 15 times Set 'Family Room / Family Rm-Pat lts L' 250 (Beep Duration) Wait 2 seconds Repeat 1 times Set Scene 'Patio Lts S' Off Run Program 'Patio Door' (Else Path) Else - No Actions - (To add one, press 'Action') I have other features in there that has the switch beep at me to warn me before it shuts off, and if I hit the "on" switch it aborts the timer, and if the light is already on, it doesn't run the program. **The main thing is to notice the line "if program patio door is true". This line is a self reference (this program is patio door). So when the door shuts and the program re-triggers, if it is already running the 5 minute timer, it restarts the timer, it does not abandon the timer. So, in reality, the 5 minutes starts when I shut the door. But that is academic since I always shut the door a few seconds after I open it. (I just open the door long enough to get through it. Link to comment Share on other sites More sharing options...
apostolakisl Posted January 2, 2014 Share Posted January 2, 2014 Hi madcodger, As much as I didn't want to respond but I feel compelled to posit our point of view: 1. Just because one got used to some other form of programming does not make ISY illogical. I suspect HS is doing a lot of things that seem illogical after one is accustomed to ISY 2. Having an atomic-wait is an interesting idea and we'll consider With kind regards, Michel Please forgive my ignorance. But an atomic-wait is not language I know. If I didn't see it written, I would assume you were talking about atomic weight. . . as in physics, but I am pretty sure we are talking about something different. Link to comment Share on other sites More sharing options...
LeeG Posted January 2, 2014 Share Posted January 2, 2014 The Wiki uses the term atomic to describe the continuous execution of ISY statements. A Then section is considered atomic when there no Wait or Repeat. The statements are executed one after the other. When a Wait or Repeat is encountered the section stops atomic execution (uninterrupted) allowing the If to be reevaluated. Refer to this Wiki link (Statement Execution Order section) http://wiki.universal-devices.com/index ... tion_Order Link to comment Share on other sites More sharing options...
apostolakisl Posted January 2, 2014 Share Posted January 2, 2014 Got it, thanks. Link to comment Share on other sites More sharing options...
madcodger Posted January 4, 2014 Share Posted January 4, 2014 Hi madcodger, As much as I didn't want to respond but I feel compelled to posit our point of view: 1. Just because one got used to some other form of programming does not make ISY illogical. I suspect HS is doing a lot of things that seem illogical after one is accustomed to ISY 2. Having an atomic-wait is an interesting idea and we'll consider With kind regards, Michel Hi Michel, and thanks. I apologize for the terms "illogical" and "silly". But I think it's fair to say that "not necessarily intuitive" is not unfair as a description. As many of my other posts suggest, I'm a big fan of simple design and making things easy for the "average Joe", like me. I just love my ISY. But it's not exactly a device that focuses on Its User Interface (UI). So while I have many friends who like what it can do, none are willing to take on the learning curve, and that limits UDI's market, unfortunately. And FWIW, terms like "atomic wait", or any jargon that requires a user learn essentially a new partial language, exacerbate rather than alleviate that problem. That's not necessarily a criticism, but it's an observation. I really wish a much bigger part of the population used HA. But suppliers have their roots in industrial design, engineering, etc. It makes for some great hardware, but it doesn't do much for making that hardware part of every home. Great design / UI as an equal partner would go a long way toward that, as demonstrated by companies like Apple and Sonos. Link to comment Share on other sites More sharing options...
oberkc Posted January 4, 2014 Share Posted January 4, 2014 Sometimes having a wait interrupted is perfect That is always the point that I think when folks don't like wait statements that get interrupted. Yes, perhaps it is not the best for one particular application, but for others, the interrupted wait statement is PERFECT. No...I don't consider it inherently inefficient. For some cases, maybe. "not necessarily intuitive" Perhaps, but I this is based on background. With regards to making HA available to the "masses", I don't believe that whether a wait statement is interrupted or not has any bearing on this. Other factors are much larger. I view the hub as an attempt to make things simpler and easier for those not comfortable with learning curves. I know which option I prefer, but perhaps there is room for both. With regards to apple and sonos, well, I like android, for the same reasons. Apple is too inflexible. Perhaps that is the trade one must make...with flexibility comes a level of complexity? Link to comment Share on other sites More sharing options...
apostolakisl Posted January 4, 2014 Share Posted January 4, 2014 Really the long and short of it is unwanted triggers. The fact that "wait" and "repeat" get terminated could be avoided by preventing triggering, or by creating an "atomic" wait/repeat. (I get the "atomic" lingo but think a more intuitive word could be used, like "un-interupted"). In my mind, the unintended trigger seems like the better place to address the problem since with an unintended trigger fix you could "kill 2 birds with one stone" . . . or maybe 3 or 4 birds. Link to comment Share on other sites More sharing options...
Michel Kohanim Posted January 5, 2014 Share Posted January 5, 2014 Hi all, Thanks so very much for all the feedback. As I mentioned before, we'll consider atomic wait (or whatever else one wants to call it). Beyond Wait and Repeat, no other statements are interrupted so it's best to keep our focus on those two without trying to address all ill in the world of HA. With kind regards, Michel Link to comment Share on other sites More sharing options...
madcodger Posted January 6, 2014 Share Posted January 6, 2014 Well darn - I was really hoping we could finally tackle everything I want changed in HA. Now I'll just have to settle for UDI considering some additional triggering options. This world domination thing is just harder than planned! Seriously, though, thanks. I will probably always be the "make this more simple / focus on UI that requires no manual" guy. Thanks for listening. Link to comment Share on other sites More sharing options...
Michel Kohanim Posted January 6, 2014 Share Posted January 6, 2014 Hi madcodger, Our dilemma is that there are 100s out there that make it easy and we really do not want to be them. We want to be the most complete. Now, the question is how can we be the most complete while not making it exceedingly difficult. Perhaps we should go hire NEST UI folks! With kind regards, Michel Link to comment Share on other sites More sharing options...
oberkc Posted January 6, 2014 Share Posted January 6, 2014 Perhaps we should go hire NEST UI folks! Nooooooooo!!!!! Link to comment Share on other sites More sharing options...
apostolakisl Posted January 11, 2014 Share Posted January 11, 2014 Hi madcodger, As much as I didn't want to respond but I feel compelled to posit our point of view: 1. Just because one got used to some other form of programming does not make ISY illogical. I suspect HS is doing a lot of things that seem illogical after one is accustomed to ISY 2. Having an atomic-wait is an interesting idea and we'll consider With kind regards, Michel Perhaps just changing the "disable program" to not stop that program if it is already running. You have the "stop" command for that. Since a disabled program can still have its components run manually after it is disabled, why should its components stop running if they already are running when it becomes disabled? Then the below program would become an "atomic" wait. Program "1" If Some condition Then Disable Program '1' do something Wait 1 minute do something Enable Program '1' Else - No Actions - (To add one, press 'Action') Link to comment Share on other sites More sharing options...
oberkc Posted January 11, 2014 Share Posted January 11, 2014 Perhaps just changing the "disable program" to not stop that program if it is already running. A GREAT idea. Have you confirmed that this construct stops a currently-running program? I would have guessed not. Link to comment Share on other sites More sharing options...
apostolakisl Posted January 11, 2014 Share Posted January 11, 2014 Perhaps just changing the "disable program" to not stop that program if it is already running. A GREAT idea. Have you confirmed that this construct stops a currently-running program? I would have guessed not. Yes, it does stop a program. It seemed to me that it would not stop a program as well, but it does. This is the program I tested it with. This stops running after 10 seconds and does not advance the variable. If Control 'Kitchen / Butlers Pantry-Puck L' is switched On Then $itest = 0 Wait 10 seconds Disable Program '1' $itest = 1 Wait 1 minute $itest = 2 Enable Program '1' Else - No Actions - (To add one, press 'Action') Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.