oberkc

I suspect that you at going to find your understanding of the "control not switched off" to be inaccurate. This will be triggered only by OFF commands, and run the ELSE path when triggered. If you care to confirm, turn on that switch and see if your program responds, if at all. I think you will Ind that it does not. Apostolaksl and larrylix has, in my mind, the best solution for your stated requirements.

I have a couple of concerns. First, you may want to try: Status is not off As your program condition. "Control is not switched off" will trigger only upon receipt of an OFF command from the switch. Second, I suspect your program will require breaking into two pieces if status is used.

Another thing that I like about scenes is that I find them easier to deal with than programs as I make minor adjustements to my lighting environment over time and as my needs change. If I invoke scenes only as part of my program, then making the changes to scenes will automatically be captured without program changes.

Sorry. I was in too much of a hurry. Perhaps when smokegrub returns, he can clarify which of us is confused.

Because this, in my mind, does not do what you are asking. You said you wanted a program that, for a period of five minutes after G is on, watch for a door sensor and, if triggered, send a notification (without mentioning the need for a delayed notification). Your program will trigger a notification (but the notification will not be sent until 5 minutes after the fact) anytime the door is triggered while G is ON (regardless of whether G has been on for less than five minutes. This may be what you want in your mind, but I believe Stusviews more accurately reflects what you asked for in your original post.

That would be my conclusion, as well.

As I understand STATUS conditions, any change in status would trigger the program evaluation.

I tend to agree that your first program should work, assuming that I understand your requirements. I suspect issues other than the program are in play here. What happens when you choose the program>>run then? Does the keypad turn off? When the main KPL is off, what is the status of the program? Is it TRUE?

Yes, since you are using "control", Both would need to be there, separated by an 'or'.

My first instinct would be to make sure your ISY software is latest (though having worked before suggests that this will not solve your problem). You did remove the device from the ISY before readding, correct?

I am curious why you have "Run Program 'kitchen day light action' (Then Path)" in two programs. I see that you also have "Run Program 'kitchen night action' (Then Path)" in two programs. I suspect these two programs can, at times, fight each other. Perhaps taking these actions out of the reminder program will help reduce your problems?

The best settings are, partially, dependent on how one intends to control the IOLinc. Other settings are more universal. One most certainly should use momentary mode. Whether using A, B, or C depends on other factors. Personally, i use a keypad button to trigger the door, set to non-toggle ON mode, withIOLinc set to respond to ON commands (momentary C?). Some settings are dependent on how you have the sensor wired and the type of sensor. Status of the relay is not always accurate. The relay is not a controller capable, so it does not transmit status. Displayed status is typically the last command sent...not necessarily accurate. I do not find relay status to be anything useful. Regarding mobilinc, i believe it is best to use scenes to trigger. Look at the sensor node to determine door status.

If you have no scenes, then I believe the scene test difficult. I recall it being something like tools or diagnostics. Mi cannot access my control panel right now to verify. I am sure you can find it in the wiki if you care to check out.

One- or two-second delays may be the result of marginal communications. Have you ever performed scene tests? Do they generally pass?

I think I once asked such a question, and the answer was "no". I have no recently explored newer versions of mobilinc, but I have not noticed this capability having been added. I use android version. May be different in iOS.

The physical indications from the switch gives me concerns. It is certainly strange to me that you would have multiple failures so quickly. I would certainly be looking for any unusual conditions....high voltage....noisy devices....high loads. My temptation would be to perform a factory reset on the switch. If the switch begins to behave normally after that, try a restore from the ISY.

Is it possibly a wiring problem? Are these intended to be part of a three-way installation, or did they replace devices that were?

The theory is that "control" will trigger whenever either (or) either of the switches is turned on manually. When that happens, the timer program, if it is in a wait state, will halt, and the program run the ELSE clause (which has nothing in it).

The only other thing I can think is to choose the questionable device and "show device link tables" then "compare". If there are mismatches, once again "restore" the device.

For a given H button, have you looked at scene membership...."is controller of", "controlled by"? When you press the H button, do devices come on that are not listed in one of the scenes? Have you observed your program status list when you press the H button? Do any programs activate? Open an event viewer. Press one of the H buttons. Do you see any signs of an X-10 address? There is nothing in my experience where devices respond to other devices without a reason such as being in a scene, a program, or having X-10 addresses assigned.

I understand the scene test is not conclusive...only an indication of the quality of communication. Sometimes, too, the devices respond as expected, but the return confirmation fails. This would, I understand, cause a failure of the test. It is also, in my mind, something that should be corrected. Another thing that can cause a failure is if you have programs enabled that are triggered by the devices in the scene test. Make sure you disable any such programs. Finally, I have found it necessary to run a test several times, and am generally satisfied if it pass most. Do you notice any particular slowness in the response by your devices? Is it near instantaneous?

Other than those goofy, toyish buttons, I don't see anything remarkable. A button besides your bed that, when pushed, turns on some lights and coffee maker. A button by the front door that advises you when your daughter gets home. Did I miss something?

It sounds like you are wise and practical. I am with you regarding the price of devices. I expect that smart devices will not last as long as the dumb ones, so there will be a noticable cost maintaining your system as devices fail. Still, I enjoy conversations about this topic, and the general state of automation. Given the recent proliferation of protocols, and given things like the new apple "home kit", one capability I value highly (and suspect the marketplace will reward) is the ability to integrate different types of devices, beyond insteon. I suspect prices will come down on these as competition heats up. In fact, I was shopping recently and stumbled upon a random clearance table of stuff, and saw a couple of z-wave modules for about $20 each. Back to the ISY, as much as I have enjoyed this thing so far, I believe the potential is still relatively untapped. The introduction of the z-wave module for the ISY and the initial inquiry into the home kit and insteon/microsoft partnership can potentially be the biggest benefit of having an ISY. This could let you pick and choose from a wider assortment of devices (beyond insteon) and choose those that meet your needs for price and value. Over time, it could be cheaper overall for those with an ISY than those without if one is a careful shopper.

I would use a program. If Control switch is switched on Then Wait 10 minutes Set switch off Else Nothing

At the risk of repeating some of xathros explanation... Which is, as explained by xathros, what the CONTROL condition does. Well, that is why we are all here...to help each other see things. At the risk of repeating (think of it as emphasising): this is exacly how a CONTROL condition works. CONTROL only triggers when a device, itself, initiates an action. When the device state is changed indirectly, CONTROL conditions do not trigger. Please note in my suggested status program, I used a lot of CONTROL conditions. This was not an arbitrary choice, and should handle the concerns about which you speak. This could be true if one were using a STATUS condition, but not if using a CONTROL condition. I do not believe that this is the case, so long as you are willing to live with the limitations associated with a scene. It is only because you are trying to add conditions to WHEN and IF and HOW BRIGHT that force one into a program and contribute to the delays. Reading many of your responses, it seems to me that the struggles that you are having are due to an incomplete familiarization between STATUS and CONTROL conditions, and when programs are triggered. I am happy to elaborate further if you are interested in trying to make the ISY work.