oberkc

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?

Sounds like you need a PC. Those darn Macs aren't much good for anything! Why do you suspect your logic is no good? Is your program not working? How about the following: if status KPL button is on and From Sunset To 10:00:00PM (same day) Then Set 'one of my lights' On Else Wait 30 minutes (Random) Set 'one of my lights' Off There are several ways to do this. The example above may suffer a shortcoming that you may or may not care about. If you turn the KPL button off with the light on, the program will cease and not turn it off automatically. Try things out. You may find that you have preferences in how you do things. Enjoy!

"Phase Coupler"? Please say which one. If you are using certain X-10 couplers, this may be a problem. The only difference between manually linking the two or three devices and doing it through the ISY, is that the scene created includes the ISY. This may indicate communication problems between one or more devices and the PLM. Do you have your PLM plugged into an outlet or circuit with lots of other stuff, such as computers, power supplies, UPS, surge suppressor, etc... Another possibility....it sounds like you manually created some links already before creating a scene through the ISY. Is this true? If so, I suggest removing them first. Since you are talking only of three devices total, it may be easiest to remove the devices from the ISY, perform a factory reset on all, re-adding them to the ISY, then creating a scene through the ISY. I cannot help but wonder if the existing links are causing a problem.

I don't have access to my ISY, but I recall an option to get caught up on restart. Do you see such an option under admin/configuration/system? I recall that this option must be selected for your schedules to catch up. I think this page is the one that I remember: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Configuration_Tab

It seems to me that the LV lighting systems are part of frequent speculation about causing interference when on. While I don't have a system like yours, I have some LED-based fixtures with power supplies. These required a filter between the switch and fixture to work properly (they turned on reliably, but not off). While you might get by programming these with the pro version, if you are experiencing communication issues, this will manifest itself in ways beyond programming, and it will not be good. Other than programming, is your insteon system working reliably?

That is my guess, but 5 seconds seems to be a pretty short time. How long do you expect your PIR to stay off once motion is detected? If you are unsure, you can watch an event viewer to get a little more insight into the timing of everything. As a possible option, you might try changing 'status' to 'control'

This sure goes beyond the trivial suggestion, given the construct of insteon. Short of additional logic within the ISY to force scene response consistent with local control, I am having trouble visualizing how one would do this. I suspect solutions would also force the user to input much more data (Naming of loads? Device wired to load?) Have you put any thought into how you would display it if you were king for the day?

I must be missing the point here. I am failing to understand what problem you are trying to solve. N-way switches are easily handled in a "logical grouping". It is called a "scene", with all devices defined as controllers. In case you are interested, most three-way switches are "single pole" (they are typically "single pole, double throw"). According to wikipedia, this type of switch may also be known as "single pole changeover". By comparison, a standard switch is a "single pole, single throw". I also found it interesting that three-way switches are known as two-way switches in the UK and Europe (this makes more sense in my mind).

???? Not sure what you mean here. For your programming example, set your KPL button as non-toggle off. Then, write a program such as: if control KPL button is switched off then set 'kitchen' off set ' stair light" to 50% else There are many ways to do this. The above is one example that may give you some ideas.

I don't see this as an ISY issue, but inherent with insteon. Scenes are part of the insteon design. ISY just makes them easier to create. I am not sure that this has ever caused much confusion in my head, but many have accused me of being a little strange in my ways of thinking.

Ah! I missed the non-toggle off setting. Yes, this is likely why it is flashing, then. Though I had not known (or forgotten) about the elimination of the error flashing feature. But, still, I would expect a response from his program and I am still curious about the possibility that the ISY is not getting the command. Looking back, I am wondering also if it is possible that the action in the "then" response is changing and forcing a re-evaluation of the "if" conditions, thus halting further execution of the program. Perhaps this is the reason his program is not working as expected. Given my understanding of this possibility, perhaps removing the 'wait' statements would solve this problem.