oberkc

Which lights are exhibing the problem...frontporchscene, or entrylights?

Keep in mind that if one disables a program after it is running, it will continue to run. Also keep in mind that if a program (entry occupied, for example) calls another program (entrylightsoff, for example), the called program will run, even if disabled.

I see references to programs not listed (evening, for example) and am not confident that I follow the entire logic of your approach. I wonder, however, are you asking about when somebody turns on on the light swithces after they are already on from motion, or before?

It sounds as if you are doing things correctly. Given the scene test results, you may be experiencing comm problems. Do you see any red exclamation points or green icons in the device listing. if you post the program, perhaps also it could be something we could see.

so the problem is that the device does not respond to the ramp settings? Just to confirm...when you select the device, itself, from the ISY device tree, you see an ON level and a RAMP RATE other than zero? What is the ramp rate? Make sure you are not using scenes at this point, or selecting the device where it is listed as part of a scene. Ramp rates and ON levels for a given device can be different when controlled locally, by the ISY, as part of a scene, and/or responding to a controlling device. This is part of the flexibility of insteon, but can lead to confusing results if not understood. Obviously, as LeeG asks, if you are experiencing marginal results when you run the scene test as part of diagnostics, you may have other things going on.

If all you want to do (at least, to start) is control a single switch with a program, you need no scene for this. Let's start fresh, I suggest, and get rid of the scenes for now. Try a simple program if time is sunset then set "switch" 50% else Of course, you can set the IF condition to whatever you wish (you did not state any particular condition for your program). Can you get this program to work? Start there and clarify what you wish to do next, if anything.

Yes, controller. The goals of the scene I suggested is to go figure the keypad such that when one presses one of the four secondary buttons, the other three turn off. For this, each bottom must be a controller of the other three.

I agree with xathros. Another possibility is the light-beam safety system associated with most garage door systems. Perhaps it has become dirty, or misalinged. Or possibly something has come loose that blocks the sensors at a given door position. One clue might be when the door actually reverses direction...is it only after fully closing, or part way? Yes, removing the wire from the IOLinc should isolate the problem further. Alternatively, temporarily removing the sensor could help in the troubleshooting steps. Another option is to watch the ISY event viewer and program status as the door is closing to see what is happening with the ISY during this critical period.

I suspect the wiki references, above, are more complicated than you need. The wiki approach is based on a single switch to control the timer...you are proposing a keypadlinc. I believe the use of a keypadlinc simplifies things a bit. The solution could be influenced by how you want the buttons to behave, and the device that actually powers the fan (assumed is this keypadlinc). I understand that you want main ON button to be continuous (no countdown). Main OFF, obviously, turns the fan off immediately. If button A is 15 minutes, how do you want your system to react if you press button A once, then press it again before the 15 minutes expire? Do you want the countdown to restart (would be my preference)? Do you want the button and fan to turn off? If you press the main OFF button, do you want all other buttons to immediately turn off (assumed yes)? What if you press the 30-minute button, then press the 15-minute button (or vice versa), how do you want the system to respond? I think I would approach this with a variety of tools, both scenes and programs. First, I would configure buttons A-D to be in non-toggle ON mode. Second, I would create a scene that includes all four buttons A-D, all as controllers, with on-levels for responder devices at zero. This accomplishes two things. First, it ensures that when I press any of the four buttons, it will send an ON command. Second, when I press any of the four buttons, the other three buttons turn off. I would then create four programs, nearly identical: Programs 1-4 if control button 1 is set ON run program 2 (else path) << run program 3 (else path) run program 4 (else path) then Turn on keypad main button wait X minutes Turn off keypad main button << Turn off 4-button scene << else I would then create a fifth program, to turn off buttons A-D when Main button is turned off: Program 5: if control main button is turned off then turn off 4-button scene else

Given that your fourth program will trigger itself when the sensor switches off, I am not sure that the third program is even needed. Nice approach!

So....you want something to happen when the catgenie "starts". This indicates an increase in power consumption, correct? This causes the synchrolinc to send an ON command, correct? Then you want something to happen at the "end of the cycle". Can we assume that the catgenie will reduce power consumption sufficiently to trigger the synchrolinc to send an OFF command? But the hiccup is that the catgenie also cycles between high- and low-power modes several times during a cycle, correct? But you have determined that these OFF periods of time are less than 3 minutes, and that any OFF period longer than 3 minutes constitutes an "end of the cycle", correct? And, we now understand that you want the programmed events to occur only once...one at the beginning of a cycle and one at the end of the cycle, but none between...no duplicate events, correct? Can we assume that the programmed events (ie "physical parts"), themselves, have no wait or repeat statements? If the above is correct, I would further modify my suggestions if control "synchrolinc" is switched on <<and status of "THIS PROGRAM" is false <<then run "DO WHATEVER YOU WANT" program (then path) <<else nothing If control "synchrolinc" is switched off <<and "synchrolinc" is not switched on <<then wait 3 minutes <<< make sure it is a real OFF run "DO WHATEVER ELSE YOU WANT" program (then path) <<run "ON PROGRAM" else path <<< notes: turns first program FALSE else I am a big fan of exploiting the inherent capabilities of the programming language and use variables only when I can find no other way around doing so. Perhaps I simply enjoy the intellectual challenge, but I find this less complicated.

Upon re-reading the original post, as well as the response by TJF1960, I wonder if I may not fully understand the problem here. If the idea is simply to force a 3-minute wait after an OFF command to ensure it is truly off (rather than one of those tempory low-power moments in the normal duty cycle of the CatGenie), I would update the last of my programs from: If control "synchrolinc" is switched off then run second program (then path) else nothing To: If control "synchrolinc" is switched off and control "synchrolinc" is not switched on then wait 3 minutes run second program (then path) else nothing

These little red exclamation points generally indicate an inability to communicate with, or write updates to, a given device. What happens if you right-click, and select "write updates" (or something like that)? Do you have access points installed on opposite legs of your electrical system? First, make sure that the device you wish to use to control the scene (a keypad button, in this case) is defined as "controller" (as opposed to, simply, "responder") of that scene. Once a controller, select that scene device from you admin console and make sure that the ON levels (level to which scene devices go to in response to this controller) are where you want them. These responder levels can, by design, be different than the levels at the scene level, and can also be zero (turn off in response to an ON command).

Unfortunately, I do not have a synchrolinc, so I can only offer suggestions based on assumptions. You say that "3 minutes later is fine". Do you prefer later, or immediately? First I would create the two programs that you want to run, one for when the unit turns on, the second for when the unit turns off. These programs would require no conditions, and look something like: if (nothing) then do whatever you want else (nothing) I would then create two programs, one to watch for ON commands from the synchrolinc, the other to watch for OFF. They would look something like: if control "synchrolinc" is switched on then run first program (then path) else nothing If control "synchrolinc" is switched off then run second program (then path) else nothing

Not that I am aware. However, I don't find it overly burdensome to simply put the ISY into linking mode, then, simply, do the same for each new device. One does not have to return to the ISY after each new device is added.

The symptoms you describe strike me as indicative of a potential powerline communication problem. Do you see other signs of poor communication, such as lights sometimes not responding or slow to respond? Do you have access points or other dual-band devices? Do you have your PLM plugged into outlets with lots of other electronic devices?

As far as I know, the keypads have only two LED states: ON and OFF. The levels can be adjusted to reflect each of the two states, but I don't believe that a normally-functioning keypad would slowly increase or decrease in brightness. The only explanation I can think of is a faulty keypad. Perhaps you could remove the keypad from the ISY and perform a factory reset on the keypad?

According the the user manual, the ISY-994 is connected to the PLM via "standard cat 5e patch cable". This does make me wonder, however, if it is connected to the correct port. If you haven't already, it is probably worth confirming that the PLM is plugged into the "port A"

They should, but it seems the anecdotal evidence suggests otherwise. Perhaps range is better with access points. Perhaps the flexibility afforded a plug in module not tied to a physical fixture is beneficial. Perhaps installation of switches into boxes messes with range or performance. Who knows.... As for me, I consider the money I spent on my four access points to be well spent.

When I see a bunch of things apparently "failing" simultaneously, I try to think of common factors. Besides RF, this could also be explained by something that is causing a communication failure with the ISY, itself. a) do you see any other evidence that the ISY is failing to see insteon communication activity? do you seen any signs that the motion sensors are communicating with devices other than the ISY? c) did you recently add a new device to the outlet/circuit powering your PLM? There are a few, simple, experiments that could point to the root cause. Try moving the PLM to the same outlet as one of your insteon access points (use an extension cord, if necessary). Create a temporary scene, with a motion sensor as controller and some light as responder. Does motion trigger this scene?

I am actually surprised this program returns your temperature to the original temperature at the end of the period. if from time A to time B then do something else do something else Programs like this work such that at TIME A run the THEN clause, at TIME B run the ELSE clause. If you want it to change the temperature and the variable, you have to specify both, in each clause. Since your program had no ELSE clause, I don't believe it was this program which caused the return to the original temperature.

Not that I am aware. I assume you would know about (unless your memory is like mine) any program, or manual disable. I agree, there is nothing in the program that makes me suspect it would not fire on its own. I don't know about any particular advantage in breaking apart your email and cell issue, especially since you tested it out and it worked.

Since you did not post the program, I could only ask the general question. If you have satisfied yourself that it cannot be a program error, that is good enough for me. Your original post did not address the possibility (except for the THEN path working correctly), however, so I simply raised the question for you to consider. If there remains any doubt, feel free to post it for a second opinion. Of course, it could be the program being disabled, either manually or by another program. It could be part of a folder that is disabled. Yes, it could also be a logical condition error. Unfortunately, I don't have access to your program to do anything more than speculate.

Perhaps a program error?

The program is simple enough, but I cannot help but wonder if your TO time is causing trouble. I am unsure if "Sunset + 9 hours and 43 minutes " would be SAME DAY or NEXT DAY. As an experiment, you could temporarily change this to "Sunrise (next day)" and see if this solves the problem. Double-check, also, that the time being registered by the ISY is consistent with your time zone and location. Double-check that the program is "enabled" and confirm that you have no programs that would disable it or that the program is not in a folder which is disabled.