oberkc

I may understand your needs a bit differently (and, perhaps, wrongly) than the others. It seems to me that some of these suggested programs may not trigger the lights until 60 minutes after the phone is detected, or perhaps 60 minutes after the phone has last been detected. Is this what you wanted? Be aware that I am generally unfamiliar with REST commands, so I am assuming you have that working, and that your variable is a state variable (will trigger a program). For the purposes of this suggestion, I will follow the lead of the others and assume the state variable is 1 when detected and something else when not. Obviously, you cannot use directly the value of the current variable as an indication of being home (because of the intermittent dropouts). I would, thus, create a second state variable, calling it $athome. I will define the values for this variable to be 0=away, 1= at home. timer program: if $statevairable = 1 then set $athome = 1 else wait 60 minutes set $athome = 0 From there, it would be a relatively simple task to create a light program based on the $athome variable if time is from sunset to sunrise (next day) and $athome = 1 then turn on lights else do whatever you want done when having left home

My memory conntinues to be a little vague on this, but I recall some of the arlier devices may reuire a power cycle befor accepting the new settings. It is, at least, worth trying.

My lighting design includes two master scenes: all lights inside, and all lights outside. Any device or switch which controls or powers a light or fan is part onf one of these two scenes. At the end of the day, my program turns off these two scenes. If I were to ever want to transition to a different scene, with all other lights to turn off, I would consider a program which first shut off the ALL LIGHTS scene, the activated the new one.

Are you able to log into your router settings and see any IP assignments? Bad or loose cable? Unfortunately, my knowledge of such things is pretty limited.

I am unaware of anything that any program (or any other ability of the ISY) can do that would cause a keypad to emit a long beep and then to stop working. If you wanted to be sure, you could disable or delete the program and see if this solves the problem. Another thing I would do is watch the event viewer when pressing the F button. Does the ISY see it? Loose wire? My guess at this point is faulty device.

When one chooses a program under "action", there are choices that include "run (if)", "run then", and "run else". These refer to which of the three sections of a program (if, then, or else) to run. Once selected, it shows up in the program content as Run Program "XXXX" (then path)

I think I will stand by my suggestion on cocoontech. Did you try it?

What happens when you try this one: http://isy.universal-devices.com/99i/4.1.0/admin.jnlp

Motion sensor nodes? The first is motion sense, i recall. Second is day/night. Third is low battery. (Forgive me if I remember wrong.). The correct node depends on purpose. Use the first node for the motion condition in the program. The second node provides an opportunity to detect darkness and can be used in a program to define your day or night condition. The third node provides the opportunity to use in a program to send yourself a notification that it is time to chane the battery.

Switches... Nice! Really creative. Pick a time of the year. Determine when sunrise is at that time of year. Use that sunrise time as the limit of your time condition. I may steal this idea.

There is a program condition for this. It looks something like: if time is from 3am to 7am (same day) You will have to decide how you want the ISY to know if it is dark. One option is, simply, to use sunrise or sunset times programmed into the ISY. Another option would be to use the motion sensor, configuring it to send commands only during periods of darkness. There are probably other options if you would rather avoid using one of these two. This is no problem. The ISY has a "wait" statement that can be configured for three hours, and you can send a command to a specific device, as well as to a scene. What do you want to happen with the other two switches? Leave them on indefinitely? Do you want any of the lights to automatically turn off at sunrise/daylight? If the three-hour period exceeds the period of darkness, do you want it to stay on? I believe a program is the best way to accomplish this. Making no assumptions about your potential answers to my questions above, simply doing what you ask and no more, the program would look something like: if time is from 3am to 7am (same day) and time is from sunset to sunrise (next day) and control motion sensor is turned on then run second program (then path) else second program if then set scene 'three light scene' on wait 3 hours set 'one of the switches' off else You will see activity in the event viewer if the motion sensor is communicating. Have you added the motion sensor to the ISY yet?

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?