oberkc

I wonder if this is a simple timing issue, but I am a little unclear what is "garage door opener button reset" and how it is activated. My quick theory is that, when KeypadB is immediately pressed and the program is triggered, "garage door opener button reset" is false (initially). The program "else" statement runs as expected. At some point after that, "garage door opener button reset" turns true, but it is too late. What if you put a wait statement (a couple of seconds) right at the beginning of the "else" path? If this solves the problem, this could confirm my theory.

I would like to think that I touched upon this a little more than "barely".

This is a quickly generated program where I expect a light to come on and off at variable intervals between the time of 8p and 11p. It uses the "wait" statement. Hopefully, this won't peg your fun meter. If From 8:00:00PM To 11:00:00PM (same day) Then Set 'Family Room / KP FRM A Table Lamp' On Wait 30 minutes (Random) Set 'Family Room / KP FRM A Table Lamp' Off Wait 30 minutes (Random) Repeat 4 times Else Set 'Family Room / KP FRM A Table Lamp' Off The wiki is also worth checking out, if you have not done so. Try here: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Action

I am unaware of any article about such a topic, but there have certainly been other threads on this topic. I generally have three categories of programs: - run all the time - run only in "home" mode - run only in "away" mode If programs are to run in home mode, they go in a program folder called "home". Likewise, if only while away, they go into the "away" folder. I use a keypad button as the tool for setting home or away modes. If the button is on, then I am "away", off is "home". The program folders use this button's status as condition. As far as the "lived-in" look, the most likely option is to create a program with a bit of randomness. I believe the best way to do this is through the wait statement, with "random" selected. Hopefully, this gives you some ideas. Have fun.

I understand your position. So long as it is working, I think I would remain unconcerned. Still, my money is on the prediction that this problem will come back for you some day in the future. My experience has been that problems don't completely go away by moving things to a different circuit. They may be marginalized, but they remain....waiting to bite. For now, though, I am guessing you will keep your eye on it. I notice that you have "filters" in your list of worthless X-10 items. My suggestion would be to use one of those. Better yet, keep them in waiting. If (or when) you experience problems in the future, try one to see if it helps. I am glad your system is working.

Perhaps I misunderstand how you "switch it around", but this type of situation is why they make filters. Given my experience, and the perceptions from reading this forum and others, I would put a filter on your media closet devices if you have not already done so. I don't know how much power it draws, so it may take more than one, but I would do this regardless of what circuit you have put this on or how you switched it around to solve your problem. If you have not done the same thing for your computer system and peripherals, I would put a filter here, as well (just make sure your PLM is not on the filtered power). I have followed this thread with interest (not posting for lack of anything meaningful to add) because I have a scene with several LED-based fixtures in my house which experiences a delay (even failure to respond, on occasion). There was no problem when these were incandescent, so I attribute this problem to the fixtures. I know that your own experiments pointed to other causes than the fixtures, but I would not completely rule this out as a possible contributor.

I tested this and get the same thing. I set mine up a while ago, so I had to refer to the wiki. Following the instructions, I expected to be able to add an email address when choose the "recipient" button in the "add/edit/remove recipient" dialog box. I also notice that the dialog box is a little different than in the wiki, lacking the option to "enter your full email address here@domain.com". Like you, I recieved an error message. Is it possible that this is some error in the ISY software?

I think you and I are in complete agreement here. I like the wiki approach. It has worked well for me. I agree that the original poster has bigger problems than a remote possibility of signal crashing. I think it was LeeG that suggested that there is "always a combination where the door did not move and the button shows the wrong status". I simply wanted to respond to this, saying that I have not found this to be the case, but could think of one theoretical possibility (besides powerline communication errors). Unfortunately, I think Jay5 has moved on.

Yes. I know. I use the wiki approach and it works well for me. The concern that I have is whether a flashing keypad (non-toggle on) is able to respond to a OFF command from a controlling device WHILE it is flashing. I have simply not tested this situation to confirm or deny.

I understand that there is also a setting on the IOLinc that sets whether the IOLinc responds only to "on" commands, "off" commands, or both. Perhaps your IOLinc is responding only to one command? (I think there is a setting that also allows a conditional response, based on sensor input, but it does not sound as if you have a sensor.) Perhaps it is here that lies the solution to your setup.

I believe programs are executed regardless of the existence of communication problems. I don't believe the ISY-99 knows of communication problems prior to the execution of programs, but, rather, only AFTER programs are run. Did you run a scene test? What were the results? Sometimes communication is intermittent...good one time and not so good another. Sometimes there are devices throughout the house that are only sometimes running (furnace, refigerator, dryer, etc) and causing problems. Question...do you have access points or other dual-band devices configured in such a way as to communicate between the legs of your electrical system?

I don't have all these devices to confirm the logic, but perhaps a program folder with the conditions: if time is from 800p until 0700 next day and ir command is recieved then run the programs in this folder in this folder, put a program such as if time is 0630 then turn the TV on Perhaps this logic will give you some ideas.

This looks to me like it will work. An alternative (syntax is approximate): if on Friday from 930 to 1130 or on Saturday from 0930 to 1130 then turn three lights on else turn three lights off I will let you decide if this is more artful. I don't believe there is an "all lights except". I believe you can use "my lighting" in a program to turn every device off. This will probably cause complications, however, as you use insteon for things other than lighting. Instead, I suggest you create scenes with all lights that you want part of an "all lighting" button. For example, I have scenes for all interior lights, all exterior lights, and all guest lights. Then use the scene to control "all lighting". This scene may also prove useful in the future for troubleshooting. That is the best way that I can think of.

My expectation would be a, b, and c. I agree. This is not my understanding. Perhaps your confusion and mine is with terminology. Compare "trigger", "evaluate", and "execute". I suggest that the meaning of the word "execute" includes to run a program action (then or else). Is it possible that, in this example, there is no "else" statement, therfore there would be no "execution" if the condition is triggered and evaluated as false? In different words, this program is triggered and evaluated many times, but only "executed" if evaluated as "true" (because of the lack of an "else" statement). This program is only evalated as "true" under the conditions described. Nice experiment. This is how many of us learned the ins-and-outs of the ISY-99. I believe that you will find status change is a trigger all day. It is just that your program will always evaluate as FALSE after sunrise and before sunset.

The separate programs are often needed when the "then" or "else" statements drive a change to the "if" condition. In some cases (typically when the statements include a wait or repeat), this can cause execution of the program to stop mid-stream. Separating the programs is a method to solve that problem. I just wanted you to be aware of the possibility. In your current example, however, I don't believe that separating the programs is necessary, but it is one way of doing it. Keeping it this way may avoid future problems, though, so perhaps keeping it separated is prudent. It sounds to me like you have a good grasp of things. Yes, this will trigger on it's own at any change in status. If the change to the porch light status is to turn off (such as at sunrise, for example), this program would execute on it's own. So, if you fail to disable this program, I would not be surprised to see the lights turn off at sunrise, followed immediately by the lights turning to 50% when the first program turns the lights off and the second program triggers itself.

Yes, there have been many posts on this topic here. In the case of from/to, this will be "triggered" at sunset and sunrise (in your case) and evaluated as "true" starting at sunset and "false" starting at sunrise. Yes. I expect this program to set the porch lights on (50%) at sunset. At sunrise, I expect the porch lights to turn off and the MBRl lights to turn on. The program will run, regardless of whether there are any actions in the "then" or "else" sections. Scheduled runs are based on "if" conditions. Yes, using programs as a status flag is one application for this. So...this newest program has adds a second condition to the original.. The "trigger" for evaluation continues to include sunrise and sunset (from the original condition), but adds a trigger for any time the porch light status CHANGES. Therefore, this program will trigger an evaluation any time you change the status of your porch light. Also, be aware that you have just introduce a condition (status of porch lights) that is affected by one of your program actions (set porch light to 50%, set porch light off). This can result in some interesting complications at times. I assume that your porch light is on a dimmer, so beware that this introduces some interesting status possibilities. Consider "on" versus "not off". Or "off" versus "not on". Is a light "on" if it is set to 50%? Just beware that there are a lot more possible status than simply "on" or "off". Correct. Also correct. Inherent in conditions are triggers (that can be schedule or event-based) that force an evaluation.

Mu suggestions were very general in nature. If you decide to adopt the approach, and later find a specific detail to be unclear, feel free to post more specific questions. If this is a real concern, perhaps there are options to mitigate this risk. One that comes to mind is to send yourself an EMail notification anytime this button is pressed. Another might be to locate a keypad switch in some out-of-the-way location, perhaps even in a desktop enclosure under the bed. You could even use one of the android or ipod/pad apps to make access a bit more convenient.

How I (and, I dare say, most) do this is to use a Keypad button as the designation for home or vacation modes. Your first decision is how you want to designate the vacation mode. Assuming you want to use some type of insteon switch (on=vacation, off=home), you can approach this a couple of ways. One would be to create two program folders. One folder would have the condition: if status 'vacation switch' is on then run the programs in this folder The other would be: if status 'vacation switch' is off then run the programs in this folder In each folder you would place the programs you want to run when away (switch on) and home (switch off), respectively. Alternatively, you could simply place a condition in each program who's execution you want to be based on the condition of the vacation switch. The condition would be identical to those above.

While not stated, do you not want your lights to turn off at sunrise? If so, try: If From Sunset To Sunrise (next day) Then Set 'Front Porch Lights' 50% Else Set 'Front Porch Lights' off

I will start it off (conceptual approach only): if status "sensor" is off then wait 5 minutes send notification to .... else This will send an EMail notification to your account of choice.

here is the link to the wiki instructions: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Garage_Door_Kit This assumes you want the KPL button illuminated if the door is open, and off if the door is closed. The keypad button must be in non-toggle "ON" (not "off"). I have not found this to be an inherent problem with the wiki approach (barring communication errors), but perhaps there is this possibility out there lurking that I have just not experienced. Maybe this could happen if the door was open a couple of inches, and you press the button, and the sensor sends an "off" signal while the keypad button is flashing? Who knows? With this approach, the only way a keypad button can be "off" (door closed) is for the sensor to have commanded it to be so. Given this, there is high confidence in the "off" status, with any ambiguity only possible with a lit button.

Your speed and reliability issues instantly make me wonder if you are having a communication problem across your powerlines. Do you have: -surge suppressors? -ups? Is your ISY/PLM plugged into, or nearby, any of the above devices? Do you use any access points or other dual band devices to communicate between legs of your electrical system. As leeG suggested, programs will necessarily be slower than direct commands, but the time frames you describe, along with the lack of reliability, makes me suspect you have other issues.

You may (a good idea, in my mind) perform a factory reset prior to adding to the ISY-99. The instructions for this, from the wiki: Resetting KeypadLinc to Its Factory Default Settings "The factory reset procedure can be used to clear the KeypadLinc memory and restore its factory default settings. This procedure will clear the unit of all INSTEON Links, and any programmed X10 addresses. 1.Before resetting a KeypadLinc that has been Linked to an INSTEON Controller, be sure to Unlink it from the Controller first. See Unlinking KeypadLinc from an INSTEON Controller. 2.If you are using KeypadLinc to control any INSTEON devices, Unlink those devices from KeypadLinc. See Unlinking a Controlled INSTEON Device from KeypadLinc. 3.Gently pull the Set button at the bottom of the keypad out as far as it will go (about 1/8"). This "air gap" removes all power to KeypadLinc. The KeypadLinc LEDs and the load will turn off 4.Wait 10 seconds, and then push the Set button all the way down until it beeps (3 seconds) and release A few seconds after you release the Set button, KeypadLinc will double-beep and its LED will turn on solid If KeypadLinc is a dimmer model, it will turn on its load Factory reset is now complete. KeypadLinc has been reset to all the factory default settings and is ready for fresh programming and use." After this, you can add the device to the ISY-99. Put the ISY into linking mode, then do so for the KPL. For the KPL, I did this by pressing and holding the ON button. I believe that this is consistent with the instructions, also. Once linked, expect the ISY to recognize the device and add all the buttons to your "my lighting" tree. Since you are using the laptop on your LAN, you should expect the same results as your desktop. I do this regularly. If you are outside your LAN (WAN), you can also enable internet access on the ISY and perform system programming anywhere else you have internet access with your laptop. Folders are a relatively recent addition. I have lost track of when this came in, but I would not be surprised if it was an update that was not compatible with the ISY-26. I like the folder option. If someone does not come along to confirm, you can check out the thread on latest software and look at the history of each version.

UPB models???!!! I see no such device on your web page?!

I believe that there is a device called the "vehicle interface" that recieves commands from the vehicle and converts them to X-10. You could use this to trigger commands from the ISY-99. Unfortunately, I have no direct experience with this to offer. The only place I recall seeing this vehicle interface is from the homelink web page. It seems to me that they don't emphasise this product, and you may have to call them to find out more about it. Hopefully, they still make it.