oberkc

No. I understand (from multiple posts here) that it is only v35 that can be a problem.

I don't know for sure, but given the "sense" current used by many insteon devices, I consider it a possibility. Furthermore, it is so easy to check by unscrewing the CFL (temporarily replacing with incandescent if needed) that I would not ignore the possibility.

You may be correct, but I note that the device name ( 'Upstairs thermostat - Main' ) is the same in both cases.

One thing that is not clear to me regarding the program... One of the conditions is that the 'Upstairs thermostat - Main' <= (less than or equal to) 65. One of the THEN actions is to set 'Upstairs thermostat - Main' to be 68. In my experience, this change in status would cause a re-evaluation of the program condition. The condition would now be false, since the termostat is GREATER than 65. This would cause the ELSE clause to run, shutting off the heat? No? If so, the heat will never stay on.

If I had a case where I wanted activation of one scene to turn off certain lights, I would include those lights in the scene, setting the ON level to zero.

I am glad it is working. One thing I thought I would mention was that the ISY includes a few features that could have helped. For example, the program status page may have given some clues. When you see lights going off when you don't expect it, check the program status page for any program that exectuded at that time. Or check the event log for commands at the lights-off time. Perhaps one of these indications, plus you knowledge of your programs, can assist in the future if you run into these types of problems again.

What keeps the program 'entryoccupied' from not running? It appears that this program would cause some lights to turn off, but I see nothing that disables this program when the switches are manually activated?

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"