oberkc

I am sorry...I meant to ask if the keypad is a dimmer version...not the fanlinc.

I suppose it is possible, but is sounds like an unecessary complication and risk. Are you concerned about the difficulty of wiring and supplying unswitched power to the fanlinc? Is the fanlinc in question a dimmer version? This could be a problem.

I suppose it depends on how you have established the relationship between keypads and fanlinc. Are you doing this all with scenes? Part of your description makes me wonder if you have some programs in play here. Also, in the scene relationships, check the ON levels for all the responders to EACH of the controllers. Are some of the ON levels zero? It also sounds as if you have the fanlinc powered by the one keypad. Is this possible? Are you certain you have uninterrupted power to the fanlinc? What is connected to the red wire of the wall-mounted keypad?

Yes, i saw the changes, and the fact that it was now apparently working as expected.

I would ask what you mean by "first two conditions". Which is the first condition? Which is the second?

No need for wholesale changes. I continue to believe that the problems you are experiencing are unrelated to these programs. The fact that your lights dropped to a 10% level after 2 minutes makes me suspect that there is a rogue program somewhere that we have not identified. From your program listing, you should be able to identify any program that ran 2:15 after your motion program. Do you see anything? Have you checked?

I don't believe changing the THEN statement as you suggest will help. It is also good to know whether there are not other programs that are affected by the motion sensor. Is it possible that there atr other programs that affect the lights? Is the motion sensor part of any scene? There are a couple of options to assist you in troubleshooting you problem...the program status list, and the event viewer. Open the program status list and have someone trigger the motion sensor. Take note of any programs that become active as your lights turn on and off. If only your one program is active, watch the event viewer for signs of in set on traffic. You might be able to identify any devices or scenes that are causing your lights to turn off unexpectedly.

I don't see anything in your second program that would explain the behavior you describe. I remain suspicious about scenes you have that include the motion sensor.

There is nothing in the program you posted that would be affected by the motion sensor timeout period. If you have scenes that include the motion sensor, or other programs, then changing the tie out period may have an impact. Unfortunately, those questions remain unanswered.

The else part is a nice feature in the event that 11:30 occurs during the 10 minute wait, interrupting the THEN statement. Is this true? I don't see anything in the program that would respond to an OFF command. The only way that I can think that this might be an issue is that the light is responder to a scene with the motion sensor (which it should not be). I don't see anything in this program that would cause what you describe. Aas suggested by others, the motion sensor may be a controller of a scene with the light? If so, I would get rid of the scene, relying only on the program exclusively. If you are unsure, temporarily disable the program and see if the light still comes on from motion. If so, then there is something else going on. Alternatively, select the light in the device list and check along the right of the screen to see if it is a member of any scenes. I am curious what devices are in the scene "'Master Bathroom / Master Bath Closet light" Like others said, it could also be the result of other programs not posted here.

Yes

I definitely like your second picture better. My quick reaction is that you may need a dedicated keypad button for both ON and OFF operations to get the positive feedback your are looking for. Thinking aloud, set the ON button to NON-TOGGLE OFF mode (so that manual presses don't turn the LED on) and use the program to turn the backlight on once completed. I would take the opposite approach with the OFF button. The big point of the theory here is to ensure that there is there is only ONE way for the keypad button to indicate things are working properly, either by being on or off as you choose. That one way is for the program to turn it on or off. Make sure that a physical press is in NON TOGGLE mode, with the opposite mode.

If you are trying to determine specifically whether a switch was turned on directly (as opposed to in response to insteon commands from other devices, for example), you will want to use "Control" in your program. The problem with using "Status" is that it will respond both direct physical control of a switch, and when the switch changes as a result of being a responder to a scene. if control "switch" is turned on then do something Expanding on this a bit, your interest in being able to use a switch to override a motion program is pretty common. One way is a simple program: if control "switch" is turned on and control "switch" is not turned off then nothing else nothing This program will be TRUE any time somebody physically turns "switch" on, and FALSE any time somebody physically turns "switch" off. This program could then be used as a condition in your motion (that is, the "override" program to halt any countdown timer. It seems some prefer variables for this. Perhaps it is easier to visualize if control switch is switched on and control switch is not switched off then set variable = 1 else set variable = 0 You could then use the variables as a condition in your motion sensor program to halt a countdown or to keep it from starting in the first place.

For iall intents and purposes, i believe a restore should solve most problems. I does nothing for x10 addresses, however. It does nothing for hardware issues that are occasionally solved by a factory reset. But, as far as link records, it should work as far as I understand.

Is it possible you have a couple of "loops" here, where executing the THEN or ELSE section of your first program causes a change in the conditions, causing a reevaluation, causing....etc...? It appears to me that your first program condition is based, in part, on the setting of your main thermostat. It further appears to me that each of your "WEEKDAY" programs causes a change to you thermostat setting which would cause a reevaluation of your first program conditions. I am also a little confused about what it is you are trying to accomplish, suspecting that there is a lot of unecessary complications here. If all you are trying to do is to set the thermostat to certain settings at certain times of certain days, why not use a handful of simple programs, such as: IF On Mon, Tue, Thu, Fri And time is 4:30:00PM Then Set 'Main Thermostat' 75° F (Cool Setpoint) Set 'Main Thermostat' 64° F (Heat Setpoint) Else - No Actions - (To add one, press 'Action') If On Mon, Tue, Thu, Fri And time is 5:30:00AM Then Set 'Main Thermostat' 76° F (Cool Setpoint) Set 'Main Thermostat' 67° F (Heat Setpoint) Else - No Actions - (To add one, press 'Action') If On Mon, Tue, Wed, Thu, Fri and time is 6:30:00AM Then Set 'Main Thermostat' 80° F (Cool Setpoint) Set 'Main Thermostat' 55° F (Heat Setpoint) Else - No Actions - (To add one, press 'Action') If On Mon, Tue, Wed, Thu, Fri and time is Sunset Then Set 'Main Thermostat' 77° F (Cool Setpoint) Set 'Main Thermostat' 65° F (Heat Setpoint) Else - No Actions - (To add one, press 'Action')

The reason that I ask is as a factor in your controller decision. The ISY-994 is, in my estimation, the absolute best insteon controller available. I understand (have yet to add any Z-wave to my house) that it controls some Z-wave devices, including door locks, but I am not sure that one could make the claim that it is the best Z-wave controller (at least, not yet). Perhaps others would disagree? Fortunately, there are lots of insteon devices available. If you are willing to go with Insteon devices where available, then go with the ISY, no question. There is an insteon-compatible lock set (Morning Industries). Unfortunately, it does not transmit status...only responds to commands. This can limit its usefulness, but it may be sufficient for your needs.

I see no mention of anything insteon. Is it your intention to use insteon components?

I suspect this is your likely end state, yes. If you prefer an independent check, take a short piece of wire and quickly touch the to opener terminals together (simulating a momentary contact switch). Does the door open or close? If yes, then I would further consider the possibility that there is a problem in the configuration of your IOLinc or connections. If no, then you will likely have to wire directly to the wall switch. I don't know whether my chamberlain is a "myQ" system. It does NOT connect to the internet, but it does have motion sensor and separate switches for the lights. Yes, I can control the opener with an IOLinc connected to the opener, itself. Also, when my opener lights flash, it is an indication that the safety sensors are not seeing each other.

To which I add that the points made about triggers, evaluation state, status, and control are all applicable to a temperature sensor when part of a program condition. I found apostalakisl comments quite relevent to this case. What did I miss?

OK. Yes, you can get rid of your first program. You are correct that for your program to trigger at all times, the omission of a time constraint is the best way to specify this. A couple of things to watch out for in this: a) yes, control and status are different in subtle ways. I recall that the wiki described this, and suggest you check it out for your own edification. In this case, I believe "control" is a better option the motion sensors, themselves, configurable by combinations of internal switches, and software such as the ISY. I think you have to configure switch 5 to enable software control. From there, check out the ISY-based options, looking for the "occupancy" mode (I think). This will allow the sensor to send ON commands each time motion is sensed, without the need to wait for a time-out period. Once done, you should be able to handle this with a single program if timeout periods for door and motion are the same, or two programs if different. Consider: if control motion sensorA is set on or control motion sensorB is set on or control motion sensorC is set on or control doorsensor is set on then turn on light wait a few minutes turn off light else nothing

I am curious as to your intentions here with program 1 compared to program 2. Also, why did you choose "status" rather than "control" in program 1? Also, 12AM to 12AM (next day) sounds a lot like "anytime". Did you intend to say 12PM (next day)? Program 1 will turn on the light any time the door sensor changes from OFF to ON. That seems fine to me. But, program 2 will do the same thing, then turn it off 2 minutes later. It seems that program 1 is redundant. Program 3, on the other hand, has the potential to cause the light to come on and stay on indefinitely. Is this what you want?

I have not performed any controlled tests. I also have seen no reason to doubt the specifications mentioned by stusviews and agree that the range can have a LARGE variability based on installation factors. Based upon what I read around here, it seems that range can also vary by device, and even among multiple copies of similar devices. I have a general perception that, all other things being equal, the "range extenders" have as good of range as any device. My best guess would be that I see the most complaints about shortness of range in regards to the insteon bulb. In my own experience, I have motion sensors removed up to 30 feet (with a wall in between) from the nearest dual-band device (a range extender) and it seems to work reliably. I tend to view the RF as a "backup" to the wire communication path, best when one has many RF-enabled devices communicating amongst themselves. I would be very hesitant to rely solely on the RF side of insteon for communication among devices.

ONe thing that seems to trip some folks up is that the relay device status is not to be used as a reflection of garage door status. Make sure you are using the sensor. (from your program, I could not tell which you were using...sorry) Another possibility, beyond those already suggested, is that it is possible that there are differences between responses to scene commands and direct commands. Perhaps creation of a scene with the relay included only, and having the program activating the scene, rather than directly addressing the relay, would help. Check, also, the mode of the relay. Is this in momentary mode?

You may also consider creating a scene in the ISY-994 (with the relay only) and controlling the scene from the mobilinc.

My initial guesses are - for some reason, the KPL OFF signal is not getting to all the devices. Do you have a confirmed communication path between the legs of your electrical system? How did you confirm this? - is you KPL in non-toggle mode, only sending ON commands? Just to confirm...you have a single scene with (about) ten KPLs and two othe devices that power the outside lights. All KPLs are controllers, the two light devices are responders. Correct? Is the non-response consistent for all ten KPLs?