oberkc

My first suggestion is to return your house to the pre-new-device status (in your case, pull the power tab from your new switches) and see if this restores proper operation of the welcome home scene. To confirm (or eliminate) a couple of other possibilities, did you add any new lights to your house, or change the type of lamps (CFL, LED) in any of these fixtures? For example, do your new devices control a low voltage fixture or CFL? Did you change the bulbs in any of the fixtures that are part of your welcome home scene? Have you recently added any electronic devices to your house? This could be coincidental to the addition of your new insteon devices.

If you are asking whether lights can be turned on with one program and off with a second, I believe the answer is a confident "YES".

apostalakisl, dnl, don't get too hung up an this particular program example to conclude there is no value in this particular control condition. I created this program just to verify a theory. There is no practical application intended. But both of your conclusions are the same as mine, however: this particular sets of conditions has a pretty limited appeal. Consider, however, something such as: time is from sunrise to sunset (next day) or control 'xxx' is not switched On This simple change in conditions give a much broader set of possibilities. I think the possibilities are limited only by our imagination.

I may not get it, either, but here is how I see it regarding the sample program. Firstly, I believe that this program will be evaluated ONLY as a result of two triggers. One trigger is time=7:44pm. The other trigger is any receipt of an "on" signal from the switch "exterior sconse". Secondly, one must look at the results of the evaluation, once they are triggered. An "on" command from the switch would yield a "false" condition, but given the nature of "controls", that condition would be only momentary (at the time of command receipt). If the control condition were evaluated at a time other than upon receipt of the "on" command, the condition would be evaluated as "true". The time condition would yield a true result only if evaluated at exactly 7:44. So....at 7:44pm an evaluation was triggered. Time condition was true. Control condition was also true (because there was NO simultaneous receipt of an on command from the switch). Both conditions were true: program was true. The triggers forcing evaluation would be unchanged. However, the results of the evaluation would require only one of the two conditions to be true for the program to be true, rather than both. I originally believed the same thing about an IPad, but once available, I came up with some uses. I continue to be amazed at the creativity of the folks around here. While I don't currently use it and cannot immediately think of a use, I am not ready to conclude that there is absolutely no use for it.

I do know my way works. Yes, of that I am sure. For what it is worth, in support of another thread I ran a quick experiment with the following program: At 7:44, the status of this program changed from false to true. It remained so until I switched the sconse on, at which point it went false. This tends to support the theory that time-based conditions themselves only trigger an evaluation at the specified time. This is consistent with my understanding and tends to support the GregE's apparent suspicion that this particular example can be accomplished as a single program. It sounds as if GregE has the same personality as me....deriving some irrational pleasure in minimizing lines of code. I think, however, it may be good general practice to break them into two programs, just in case of something we were not smart enough to foresee. That is, unless we specifically want to take advantage of the ISY ability to halt programs midstream (such as certain motion sensor programs).

Hi dnl, I just created a sample program: If Control 'Basement/Garage / SW GRS Garage Exterior Sconse' is not switched On And Time is 7:44:00PM Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') When the ISY clock went to 7:44, the program status changed from false to true. I expect it to remain true indefinitely, unless the switch is turned on manually, at which point it will stay false until 7:44:00pm the next day. BTW: this is consistent with my single test point....I turned the switch on and the program reverted to false. If I remember to check tomorrow, I will see if the program turns true at 7:44p.

But, I thought that the time condition, in this case, would only evaluate once per day (at sunset). I see no other trigger condition forcing an evaluation that could result in a false condition, halting the program. (You are not suggesting that the "wait" statement, itself, triggers an evaluation, are you?) I expect this program to be "true" indefinitely...and that a single program would work here.

The response from Chris made me think differently. The expression WOULD evaluate as "true" IF it were evaluated. However, in this case, the only trigger that would force an evaluation (apart from additional conditions in the "if" statement) would be receipt of an "on" command, at which point it would evaluate as false. I think this is the case of differentiating between what causes an evaluation versus the results of an evaluation. Statements such as this are probably most useful in conjunction with other conditions, or if you want an "on" command to trigger an "else" statement. For example, I would expect the following statement to trigger an evaluation at 0900 and the evaluation to yield a "true" result: if time is 0900 am and control "XXX" is not switched on Consider the opposite.... if control "XXX" is switched on By the same thought process, this one never evaluates as "false".

So, is this statement always evaluated as "true" except at the instance when "On" is received. Is the implication also that the trigger for evaluation of this statement is still just an "On" command from the device (off, dim, bright, xx% will NOT necesarily trigger an evaluation)?

I use a keypad button to define occupancy (home or away). I don't have them, either. Mine are X-10. However, I understand the same as you...they issue commands like any other insteon device. Perhaps they operate most like the Remotelinc. I also understand that there are several jumpers which can be used to define certain characteristics of the sensor. I have been following your two threads on this subject, with interest. Given the responses, I wonder about the value of one line in kingwr's logic: Or Control 'Living Room Light' is not switched On In the back of my head, I also keep thinking about how people often complain of a "feature" of ISY programming...halting program execution (with wait or repeat) when an input condition changes. I find it interesting that this type of programming actually exploits this feature. I am curious about your (and other's) thoughts on this.

I am not so sure that the motion sensor changing to "off" is an indication of someone being present, but if that is what you want, then I am starting to understand the approach you took. The only other question remaining in my mind is whether there would be any difference if you used "control" rather than "status" to track your motion sensors. In your case, based on my understanding, my guess is no. Thanks for the dialog. i found it interesting and enlightening. Some people enjoy Sudoku. I enjoy logic. I am hoping it keeps my mind fresh. I don't use my mind as much as I should.

I suspect the answer to your question is no. I understand that those devices that cannot be configured as controller in a scene are this way because they fail to transmit status updates. Based on this understanding, not only can you not use them as controllers in a scene, but you could not use them to trigger programs. I suspect that is why you don't see appliancelinc as one of the devices listed when you try to add a control or status to a program.

I just ran another experiment with "control" rather than "status". Indeed, the program did NOT change conditions as a result of a remote command. I don't recall writing such a thing, but it appears that I was correct, if I did. Regardless, I did not have a lot of time to try to understand your problem earlier. Now that I have looked a little harder, I realize that I misunderstood (I thought your livingroom light stayed on forever, but it was your motion sensor that was getting stuck on). Given my current understanding of your desires (and based on our experiments), I am now wondering if the following addition to your first program would solve your needs: If Status 'Motion Sensor' is On Or Control 'Living Room Light' is switched On Then Disable Program 'Night Lighting' Wait 24 hours Enable Program 'Night Lighting' Run Program 'Night Lighting' (If) Else Wait 24 hours Enable Program 'Night Lighting' Run Program 'Night Lighting' (If) Every time the motion sensor sends "on" or every time the living room light is turned on, the program (then path) will disable the second program and start a countdown. If no motion activity of any kind is sensed (even if the motion detector fails to send an "off" command) for the next 24 hours, the night lighting program will start. If the motion sensor is turned off, then a new 24 hour countdown starts. Each 24-hour period would be interrupted by a motion "on" or a manual turning of the light "on", starting a new 24 hour countdown. Thoughts?

This is something that is pretty easy to confirm yourself, should you care to do so. Under the program summary tab, you can see the status of your programs. Watch the status of your program "occupancy detector" after "night lighting - then" path has run. If you see "occupancy detector turn from "false" to "true", then you have confirmed your original (and my current) theories. I don't use this type of logic in any of my programs, or else I would confirm this myself. Update: I would not be too quick to discount your original theory. I just created a simple program, looking something like: if status "light" is on then else I then sent commands from the admin panel to device "light" (a togglelinc). The program changed status as a result of commands from the ISY to turn the light on or off. It required no physical press of the switch. I take this as tentative confirmation that actions from a program can cause an evaluation of another program, with resulting status based on evaluation results.

I did not spend a lot of time looking at this, but I wonder if your problem is that, at sunset - 15 minutes, the "then" statement of your night lighting program causes your first program to immediately disable it for 24 hours. This results in your night lighting program not running the "then" path at 10:30?

This works pretty well, so long as all your devices are lights. If you have others (garage door, for example), I wonder if this may result in undesired consequences. I created two scenes: interior-all and exterior-all. They include only lights that I want to respond to the "all off" button. This may offer another option for you if needed.

There does seem to be a small-but-vocal group out there that regularly complain of this behaviour. In my mind, it has some benefits, and some downside, depending on your purposes. Regardless, it is like any other computer programming: you have to know the language, but once you do, it is completely predictable.

My understanding is that, whether device or program, change in status will trigger an evaluation of the "if" condition and respond accordingly.

This is standard "Boolean Logic". There is a discussion about this in the wiki: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Scope,_Precedence_and_Execution_Order Knowing the priority between "and" and "or" and using parenthesis is an important part of programming beyond the basic level. I found it to be good reading and hope you find it as useful as did I.

I do this. I have a KPL button set to non-toggle off, but make it a responder in a scene with another device who's status I want to know. It turns on and off, based on the status of the other device. I assume, based on LeeG's response, that mine is a newer KPL.

This is, in my experience, the hardest part, and the part that pays the greatest dividends. Few put enough thought into understanding their requirements.

It is good to hear you have your problem solved. That was a creative solution. I will make a note of it, in case I ever need it. I would still be curious why you can't add that one device to a scene. I can't help but suspect this problem could continue to show up in mysterious ways. On the other hand, I have learned to let sleeping dogs lie, and enjoy a functioning system.

There are many variations on the motion sensor theme. I learned much from the wiki, which addresses your concern. I think there are other wiki examples, also. http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Using_X-10_Motion_Sensors Another issue that you may run into is what happens when sunrise passes during your wait period. You program will stop and the light will never shut off. I agree with apostolakisl, there are benefits with separating your programs. One of the problems with a simple solution to your twist is that is can often have circular logic. You could check that the light is not on as part of your condition, but the program would turn it on when motion is sensed, forcing evaluation of your condition (now false), stopping your program. I cannot improve upon the recommendations in the wiki, so I suggest checking out the part about "motion disable".

I am not so sure that this is true. As you pointed out, each 'off' statement triggers an evaluation, at which point it will halt the program and start it at the beginning. This assumes that the motion sensor sends repeated off's, which I suspect it will (after the motion sensor time-out period). The only problem that I can see is if the motion sensor time-out is longer than the program wait period. Based on the original post, however, it sounds as if the motion sensor wait period is less than 5 seconds.

That shouldn't matter, unless you happen to have FKey1 - B and FKey1 - G set to mutually exclusive. Is this possible?