oberkc

If downstairs is already on, turning it on again will not hurt anything. No. For the same reason. Having said that, you did not specify if your intentions were also to turn them off after a certain period of time after sense of motion. If so, then there may be benefits to including one of those conditions in your program. Also, if someone has made a manual adjustment to the scene (dimmed, bright, etc...) then turning the scene "back on" will cause it to resort to the devault settings. This may or may not be a factor in your case.

Wow. You don't ask an easy question. Are you prepared to reset and reprogram devices? How many devices are we talking about? Do you have any plug-in modules? Do you know what access points are and do you have any? How old do you believe is this installation? Do you have any whole-house controller of any type?

Does the PLM have a factory reset function? If so, how about: 1) remove PLM from ISY 2) factory reset PLM 3) restore PLM on ISY

This is what I have now for the sunset/sunrise but it is not working for some reason. It comes on during the day. This looks correct to me. I expect this to work, also (although it is unclear to me how these lights turn off. Is the motion sensor part of your 'backyard lighting' scene?) Have you checked the time on your ISY? Is it possible that the system settings got messed up? I am a little concerned that your manual backyard enable program includes actions in the "else" section that may trigger a re-evaluation of your program conditions. This violates one of my personal general programming rules for the ISY. As for the motion control program, is this constrained by sunset or sunrise anywhere? Is this program enabled along with your sunset/sunrise program, above?

Don't hesitate to post back. Also, check the universal devices wiki. There is an excellent example there. Perform a search on garage, and IOLinc. You will find explanations about many of your questions.

Be advised that most on this forum are Users with no affilitation with Insteon (Smarthome). A few are from Universal devices. As advised by LeeG, I believe that this can be done. However, I question if this what you really want. It sounds as if you are using a keypad to control your garage door. Is this true? If so, do you want your keypad to display status of the garage door?If not, how do you know the status of the door? What if the garage door is stopped mid-way or moving? How do you want the door to respond to commands? If mid-way, this will only respond to one command, depending on how you wire and position your sensor. If your original aspirations ("on" opens when closed, "off" closes when open) then my experience is consistent with LeeG. Create a scene with the relay as responder and your controlling device (whatever insteon device you desire to use to send on and off commands) as controller. Set the relay to momentary "C" mode. Keep in mind, also, that the sensor can be wired such that a garage door closed would give either "on" or "off" status. Additionally, there is no way to distinguish between a door being fully open or partially open.

I am impressed by your ambition. How does your site differ, in purpose, from the wiki?

I use programs to turn off scenes (including those with controller devices) all the time, without issues that I know about. In fact, I thought the response to scene commands was more robust than the response to individual devices. Like Sub-routine and gviliunas, I am having trouble understanding why you think this is a bad idea. Consider me to have spoken up. I believe this is not correct.

Thanks for trying.

I think I would, then, perform an experiment. Remove one of your devices from the ISY. Re-add it, this time by automatically creating the link (choose the "start linking" button). Then see if you can get status. I'll bet that you can. My theory is based upon the possibility that the ISY does not accurately recognize the device sometimes when added manually. Furthermore, this can result in query and status problems. While I am not completely confident of this, it seems a simple enough experiment to try.

I think I noticed this change in one of the recent updates. I recall, also, the option to expand (mouse click?) the primary button to show the links.

I am by no means an expert on this, but I think it possible that the remotelinc shows OK because it cannot respond to queries as can the other devices. I suspect the query of a remotelinc to be much more limited. When you added your devices, did you do it manually (type the address) or automatically (start linking)?

I tend to agree that an accurate progress bar would be nice. However, I have also used the event viewer to get a sense of communication issues. Set it to level 3 and one can see if there are hangups. While not the most elegant, it is a functional solution for those of us who like to keep track of such things.

I guess we will all see what Chris confirms, but I can tell you that the wait statements in my programs resume at the next step in the program following the wait, not the beginning. If this were not true, programs such as: set light on wait 2 minutes set light off would never work. My programs are not re-evaluated, either. If this were done, several of my programs would never finish. I understood Chris to say that a program will only stop execution if something happens that affect the "if" conditions. This is consistent with my experience.

This is how I understood it. This is different, however, than saying that the "wait" statement itself causes a re-evaluation. While the syntax and programming structure may be unlike what one is used to, I remain unconvinced that this makes it wrong. In the case re-evaluation during program execution, I might even argue that this can offer advantages in certain situations (think motion sensors). Furthermore, there are ways to avoid the stopping-of-execution-in-the-middle-of wait-statements. Learning the ISY is like learning any other computer skill....computers, cell phones, calculators, Sony Dash, It takes a little time to be able to fully explit the available capability, but becomes pretty intuitive once learned. At least, that is how I find it. Maybe I am just weird.

It just surprised me how you described this as a lot of programming. I apologize for my confusion.

I did not believe that the wait statement actually caused a re-evaluation. Rather, I understood that a re-evaluation COULD occur during a wait state, at which point, a program would be either halted or restarted.

Do you not have an ISY-99? This would alleviate much of the burden of programming. Yes, it sounds as if you need to make Keypad A button A a responder in the other scenes.

I have read that sentence (and the whole post) several times, and remain uncertain as to it's meaning or your problem. Is there any chance you can re-phrase and elaborate? I apologize for being a little slow.

Perhaps it would be better stated "ESPECIALLY for people like me..." I often wonder if it is easier for those of us without expectations or experience regarding how it should work and the ability to recognize that it is somehow different than other programming languages that I may know.

I am just throwing out ideas....I have not tried anything like this. I would first create a "status" program (I am thinking others have called this a flag program). I don't think it needs to have anything in it. if then else I would then create a program to monitor the trigger, and change the condition of the status program. if control "togglelinc" set fast off <<then run program "status" (then path) <<wait 3 seconds run program else path <<else You could then create a third, panic, program: if status of program "status" is true and control "toggleinc" set on then do whatever you want in response else Please forgive the syntax. This was done purely by memory of ISY verbage. Hopefully, the intent is clear.

I have not seen one that helps solve any problems. There is a list of error messages here: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Errors_And_Error_Messages Unfortunately, this list offers little help (at least to me) deciding how to procede. Maybe others can point to lists with better explanations on the root cause of these error and how to solve them. Fortunately, I don't get these very often. When I do, I just resort to the normal troubleshooting methods....remove and re-add, factory resets, communication tests and troubleshooting methods.

How are you sending the "off" command? I found the instructions on the wiki: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Garage_Door_Kit'>http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Garage_Door_Kit and the instructions in the IOLinc options: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Linking_an_I/O_Linc to be better than anything that I can write up. Momentary C is defined as: "Look at Sensor - If the sensor is On the relay will close momentarily when an On command is received. If the sensor is Off the relay will close momentarily when an Off command is received. " What is your sensor status when the door is open? If your sensor is "on" then an off command will not do anything if you IOLinc is in momentary C. Try momentary A and see if this clears anything up. Without knowing a few more details about your setup (what is it that you are trying to do, with what device are you trying to control your garage door, how do you have your IOLinc wired, what sensor are you using, does door closed show off or on, etc...), I find it difficult to offer specific suggestions on how to configure your IOLinc, what scenes to create, if any, or what programs to write, if any. I have two garage doors. Each is controlled by a single button on each of two keypads. The button shows status (on is open) and I can open or close from them. I used the outstanding writeup from here: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Garage_Door_Kit The general theory is to set your keypad to non-toggle off. Create a scene with the keypad button as controller and IOLinc as responder. Create another scene with the relay as controller and the same keypad button as responder. Set the relay at momentary A (responding to either on or off commands from the keypad). I believe you also have to wire your sensor such that open gives a relay as on status, which is backwards from the instructions included with the kit, if I recall.

I thought mine reported state, but I just went out and checked, and noticed that none of my devices' status show up. I closed the ISY, then opened again, and status is now magically there. Manual control of devices shows up accurately in the status box. Try closing the admin panel and reopen. See what happens. Besides the possibility of device or communication failure, my first thought on your situation is wondering how you added the device to the ISY. Did you do it automatically (start linking) or manually (type insteon address). I am under the impressions that manual addition of devices may yield less than optimum results in some cases.

I am actually surprised that this even works at all, since the action (then path) affects the conditions. I am with IndyMike. I don't think there is a way to avoid the local control function. Perhaps a trick like CLU suggests would work. Maybe you could write a program: if control bedroom light is set fast on then wait 10 seconds set bedroom light off