oberkc

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

one - I (and many here) have done this. I don't believe harmony has built-in insteon RF signals (unless recently added) so this leave a couple of options....X-10 signals to the ISY, use one of the insteon IR receivers and learn one of the harmony codes, or make sure you get the ISY-99IR. This works well. This will be no problem.

it seems to me that this would work. There are so many examples of how to do motion sensors. I think there is a pretty good explanation also in the wiki. Perhaps you want to consider coming up with a way to avoid having to make the assumptions above. What if you don't always want the light off during the day? What if you don't necessarily want it to turn off at sunset? What if you want to maintain manual control of a light, but motion sensor control when manual activation hasn't occurred? (These are all rhetorical questions unless you want to try to tackle this.) There are so many variations and it can all be done if you want to take the time to program it.

I am concerned that your approach will suffer the same problem with the so-called "boundary conditions". If your sunset/sunrise program disables your motion program (for example, when it turns to dawn) while the lights are on (in the five-minute period), then the lights will not turn off. First, you cannot use the quick reply. In the full reply, select the text that you want listed as code, then select the "code" button in the reply window.

I suggest posting a copy of your program(s). Perhaps someone can spot why this is so.

I suggest that this is a case of understanding what one wants to do. It appears to me that Sub-routine's program would turn the lights off 5 minutes after the motion sensor sends and off command (and the other motion sensor is off). That constitues 5 minutes, plus whatever time is set on each of the motion sensors before an off command is sent. These are variations on the same theme. Both approaches will work. Both probably have merit. The important thing (in my mind) is to understand what it is you are trying to do. Unfortunately, this was in response to a request to make it "work right". We don't know if five minutes is the correct time, or five minutes plus motion sensor time, five minutes after motion sensor sends an off command, or whatever. Both will work. There are subtle differences in performance. Both require a specific configuration set up in your motion sensor.

I appreciate your desire to learn the system. I beleive this approach helps make all of us a better user. The reason I asked this question is that I recall cases where manual input of addresses caused problems in certain cases...perhaps the ISY could not ID the device (what does the ISY show as device type?)....something like that. My suggestion is to add them automatically. First remove one of your devices. Next, choose start linking (remove existing links). Next put device in linking mode. At this point, you should see the device back in your admin panel. Exit linking mode from the ISY. My suspicion is that if you were to now add this device into your program, it will work as expected. This is only a moderately educated guess, however. It is also pretty easy to check. Hopefully, this will solve your problem.

OK. This introduces some issues many have referred to as "boundary conditions". That is, how do you handle the condition where dawn occurs during your "on" time period. Maybe. If your needs are simple, scenes could be best. They are quick and, as I understand, more robust. Responses to scenes tend to happen a bit quicker than programs. There is a measurable time that programs take to respond. My estimate is that this is somewhere in the 1-second range, depending on complexity. I have three motion sensor programs and two seasonal (holiday lights) programs that I want to operate between dusk and dawn. I find it convenient ("best") to use a single program folder to constrain each program, rather than putting the condition INTO each program. I assume from your response that this motion sensor is the only program you have that you want to run from dusk to dawn. Given this, it may be "best" to put this constrain directly in the program. I don't use insteon sensors (mine are X-10) but I understand that insteon sensors have jumpers that allow one to set certain conditions, such as: - operate all day or only during "dark" - whether the motion sensor transmits an off signal - duration of duration of time between sensing of motion There may be others. Bottom line is that how well a program works and what is "best" is contingent on how you want to configure these jumpers. If you have only a single light, then you may be fine turning that light on directly from the program. If you have mlultiple lights, it may be "best" to create a scene with the multiple lights as responders and turn the scene on through the program. My perception from reading these forums is that programming "skills" are one thing. These can be learned if desired. The harder part is specifically defining what it is that you want to do and expressing this desire in sufficient detail such that those with the programming skill can offer meaningful suggestions. Sub-routine's suggestion on the other thread, for example, will work beautifully. Unfortunately, it will not do what you want because you want it only to work from dusk to dawn and he did not appear to know this. Try two programs: if from sunset to sunrise (next day) and ( control motionsensor1 is turned on or control motionsensor2 is turned on ) then run "timer" program (then path) else timer program: if then turn light on wait x minutes turn light off else Good luck and have fun!

OK. This introduces some issues many have referred to as "boundary conditions". That is, how do you handle the condition where dawn occurs during your "on" time period. Maybe. If your needs are simple, scenes could be best. They are quick and, as I understand, more robust. Responses to scenes tend to happen a bit quicker than programs. There is a measurable time that programs take to respond. My estimate is that this is somewhere in the 1-second range, depending on complexity. I have three motion sensor programs and two seasonal (holiday lights) programs that I want to operate between dusk and dawn. I find it convenient ("best") to use a single program folder to constrain each program, rather than putting the condition INTO each program. I assume from your response that this motion sensor is the only program you have that you want to run from dusk to dawn. Given this, it may be "best" to put this constrain directly in the program. I don't use insteon sensors (mine are X-10) but I understand that insteon sensors have jumpers that allow one to set certain conditions, such as: - operate all day or only during "dark" - whether the motion sensor transmits an off signal - duration of duration of time between sensing of motion There may be others. Bottom line is that how well a program works and what is "best" is contingent on how you want to configure these jumpers. If you have only a single light, then you may be fine turning that light on directly from the program. If you have mlultiple lights, it may be "best" to create a scene with the multiple lights as responders and turn the scene on through the program. My perception from reading these forums is that programming "skills" are one thing. These can be learned if desired. The harder part is specifically defining what it is that you want to do and expressing this desire in sufficient detail such that those with the programming skill can offer meaningful suggestions. Sub-routine's suggestion on the other thread will work beautifully. Unfortunately, it will not do what you want because you want it only to work from dusk to dawn and he did not appear to know this. Try two programs: if from sunset to sunrise (next day) and ( control motionsensor1 is turned on or control motionsensor2 is turned on ) then run "timer" program (then path) else timer program: if then turn light on wait x minutes turn light off else Good luck and have fun!

There are several ways to do this, all perfectly functional. I have found that "best" is often based on other factors, often unrelated to the specific task-at-hand. 1. Do you have time constraints? Dusk to dawn? Seasonal? 2. Do you prefer controlling the timing via the ISY or the motion sensor, itself? Is your motion sensor difficult to reach? 3. Does the slight delay of programs versus scenes bother you? 4. Do you have other programs with similar time constraints that can consolidate into folders? 5. What type of motion sensors are you using? Insteon? X-10? Other? How are your sensors configured? 6. What do you want the response to motion to be? Multiple lights? One light? I think it will be up to you to decide what is "best", based on your own needs and desires. Several have offered suggestions on the other post, based on the posted desires. If your desire is to use the ISY to control the on time of your lights, and you have no other specific issues pointing towards a certain approach, you might try something as simple as: if control "motionsensor1" is switched on or control "motionsensor2" is switched on then turn light on wait x minutes turn light off else

It looks like you found the other recent thread on this topic: http://forum.universal-devices.com/viewtopic.php?t=5286 After having found it, do you have additional questions?

My perception is that this is unrelated to the program. This sounds more like set-up or communication problems. 1. how many access points (or dual-band devices) do you have? Are you certain that you have one on each "leg" of your electrical system? 2. how did you add the kitchen sink device? Manually (typing an address) or automatically (start linking)? 3. can you control the kitchen sink through the ISY admin panel (select device, select "on")? 4. what kind of light (incandescent, LED, flourescent, 12V halogen, etc) are controlling with the kitchen sink switch?