oberkc

The closest Insteon device that I know of would be the fanlinc.

I am able to make some of my modules beep with the ISY-994. I don't have any dual-band lamplincs, but I cannot imagine why they would not be so capable.

I can think of a few possibilities: a) they were turned off or on individually from the admin screen or a remote app the ON level for one is zero c) these devices (one or both) are also responders from another scene d) the status is inaccurately stated due to a comm issue I believe the red text indicates both are controllers of the scene, but it is worth confirming. If not, there is another possible explanation.

You may want to consider "control" rather than "status" for your garage door sensor condition. As written, if $OCC is 0 and the garage door is open, any time you turn off one of those two lamps, your program will execute TRUE. I am unsure, of course, what drives your $OCC variable to go to zero, so this may not be a practical concern. Still, I think "control" is a better choice here.

Glad it worked!

One thing to remember is that insteon scenes can have different ramp rates and ON levels, depending on which controller. When you are programming ramp rates and ON levels you wish to be in effect when the remotelinc is used, make sure you have selected the remotelinc under the scene definition. With the remotelinc selected, you should see, in the main panel, each of the devices in the scene, with ramp rates and ON levels. Make sure the keypad has the correct rates and levels.

Not certain, but I don't believe so. I understand the stickers on the units refer to hardware version, rather than software. I would think that if you were to isolate the swich (pull the tab) and your system starts working, that would be a pretty solid clue.

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.