oberkc

Agreed Agreed. If not every switch, certainly all that are of interest. I believe this is consistent with the two examples suggested so far.

Much depends on what you want to do based upon the state. If you want your program to trigger at any status change, and always evaluate as true, then you may try: if status 'device A' is not off or status 'device A' is not on or status 'device B' is not off or status 'device B' is not on . . . then wait timeout period run this program (else path) <<else This program would be true if sees any activity within timeout period and false if otherwise.

What happens when you try this link: http://www.universal-devices.com/99i/ ?

I believe enabled/disabled. A folder turning true does not trigger the included programs. If a folder turns false while a program is executing, however, my instincts are to suspect the program to continue execution unless it includes a wait or repeat. I would verify to be sure.

Your lights are plug-in? If so, your options are modules, outletlincs, or inlinelincs feeding outlets. Outletlincs and inlinelincs require permanent installation into your electrical system. The problem you are experiencing has to do, I believe, with the "sense" capability of the modules and outletlincs. These devices send a small current through the load, in order to sense local control has been activated and to turn on, in response. Unfortunately, this small current is enough to cause some LEDs to glow, when off. I don't believe the inlinelinc has this local control capability. If not, then this should be a viable option for you. As an alternative, many have reported success by adding, in addition to your LEDs, a small (somwhere around 5W) load to the outlet of the module. The addition of a small nightlight or power supply can often be enough to alleviate the glow of the LEDs. Unfortunately, this partially offsets the benefits of using LED.

With the ISY-99, scene level ramp rates (and on-levels) are those that are activated when the ISY-99 (PLM as controller) activates the scene, most likely through a program. The scene controller level settings are the ramp rates and on-levels in play when activated by that specific controller. This is one of the basic features of insteon...the ability to set different scene settings based on the controlling device.

I have used non-dimmable CFLs on insteon dimmer switches. I set on levels to 100% and ramp rates to instantaneous. Interestingly, when CFLs were relatively new (and before they were dimmable), I had some cases where insteon relay devices (plug-in modules) with smaller CFLs would not respond to commands, whereas insteon dimmer modules with these same CFLs would work. Because I wanted to use CFLs and control them with insteon, this forced me to use dimmable modules with non-dimming CFLs. I have not experienced this problem with newer devices or lamps. With the introduction of LED, and my general dissatisfaction with the dimming performance of CFL, I tend to keep CFLs on relays only. Still, I think I have two cases of non-dimming CFLs on dimmer modules. Have been this way for about four years now and see no reason to change. They work. They continue to work. I have had no device or lamp failure during this period. They are controlled by ISY-99 program only, so risk of accidental dimming is minimal.

I tried to check out my morninlinc, and find it inoperable. The LED is dimly flashing. No communication appears possible. Factory reset does not restore anything. I guess it will be a few days before I can confirm my original belief: on and off devices appeared to serve no separate function. Both would lock or unlock my morning industries door lock.

That was my initial impression. However, upon installation, I found that I could put either of the two devices in a scene and lock or unlock by sending either an on or off command to the single device. In my mind, this created a bit of redundancy. Will respond again when confirmed.

I notice the same thing. Two devices. Both able to lock and unlock the door. I was just too lazy or uniterested to ask the question. That being the case, I look forward to any insight anyone cares to offer.

Apostolakkisl suggestion is quite viable and may be the easiest approach. But there are date conditions in the ISY-99 (I believe they are part of the time condition). I have two program folders for seasonal programs, winter (nov-mar) and summer (apr - oct). I use the date condition for the program folder if from 12:00 am on 1 November 2011 until 11:59 pm on 31 March 2012 then run the programs in this folder In each folder I add the programs that I want to run during the respective seasons. Each year, I simply update the conditions to reflect the new year. If I wanted to take the next step, I could create a multi-year condition: if from 12:00 am on 1 November 2011 until 11:59 pm on 31 March 2012 or from 12:00 am on 1 November 2012 until 11:59 pm on 31 March 2013 then run the programs in this folder I believe that there are even examples on the wiki where one can use a variable to reflect a date without a year, thus creating a program that would have a condition equivalent to from 1 November (any year) to 31 march (any year) But I have apparently decided that it is easier simply to change the dates each year.

Your experience does NOT match mine. When I add or remove devices from scenes, I get an indication of things happening. When done, I find no need to re-run the admin console. All changes are accounted for. I find the speed of the changes mostly limited by the speed of insteon communication via powerlines. Given your desciption of the problem and how you believe this is related to Java, have you tried clearing the java cache?

This tends to suggest a communication problem, between your keypad and one of the scene's devices (this includes, potentially, the PLM). Where is your PLM plugged? Is it in the same outlet or cirucuit that includes a lot of computer stuff, such as surge supressor or UPS? Do you have any access points or other dual-band devices? Are they confirmed on opposite legs of your electrical power supply? In the ISY-99 admin panel, open event viewer. While opened, press button H. Do you see any event in the viewer suggesting acknowledgement of this button press? In the amin control panel, if you select the H button from the "my lighting" tree, do you see the status change as you press this button? What other devices are in the scene?

If you use "control", shutting the garage door (turning the sensor off) will NOT, by itself, trigger an evaluation of the program. "Control On" is only triggered by receipt of the "on" command. Off, dim, bright, will not trigger an evaluation. Given that the program is not triggered, there is no evaluation rendered. Of course, your wife could come in, open the door (triggering the program), then turn on the undercabinet light before the five-minte wait. This WOULD trigger an evaluation (status), which would then render a false conclusion, interrupting the wait, and sending the program into the "else" path. Alternatively, your wife could come home at sunset-3:01 hours, and trigger the program. A minute later, the program would trigger again (sunset - 3 hours) and send the program to the else path. One needs to look at what triggers evaluations of programs here, as well as the logical conclusions resulting from those evaluations: - Status is triggered at ANY change of status - Time from XXX to YYY is triggered twice: at time XXX and YYY. - Control is triggered only upon reciept of the specific command, whether off or on. Control on will NOT be triggered by an OFF command.

Try "control" rather than "status". Control will be triggered only by an "on" command. Status is triggered by ANY change in status. If >>>control 'Garage Door Sensor' is On And Status 'Kitchen - Under Cabinet' is Off And From Sunset + 15 minutes To Sunrise - 3 hours (next day) Then Set 'Kitchen - Under Cabinet' On Set 'Laundry Room - L [East]' On Wait 5 minutes Set 'Laundry Room - L [East]' Off Else - No Actions - (To add one, press 'Action')

If you move your access points, be sure to ensure they are on opposite legs of your power supply. I agree with Brian H...keep checking the devices on your PLM circuit. Power supplies can be problems. You can always try the extension cord test.

Your problem sounds typical of when the communication problem is associated with the PLM. Let's try the easy stuff first. Is your PLM plugged into a surge suppressor or UPS? Is the PLM plugged into an outlet or circuit that powers your computer system equipment, including surge suppressors or UPS?

Perhaps, too, there is a little confusion about the definition a "scene". The ISY-99 defines them slightly different than the basic insteon construct you get from smarthome. If you programmed these devices manually (tapping buttons, running around the room), you would create two "scenes"...one for each controller. Using the ISY to create these relationships, it will show up as a a single scene with two controllers.

These are programs I would be proud to call my own.

That sounds correct to me. I vaguely recall times when some of my programs have NO status, suggesting that they need to run at least once. Given this, there would be need to deal with this condition after times of power outages.

I will take a shot at this. I have not yet used variables, but this seems like a good place to start. This suggestion is conceptual, so the wording is approximate. You would have to create a variable (integer seems appropriate) in your admin console for this to work. I suggest using the variable as 1 to show the dimmer button has been pressed off within the last two seconds, otherwise set it to 0. I understand that variables don't trigger an evaluation when changed, which makes them useful in this case. I will throw this out for others to review: if control "Master BR dimmer" is set off and ivariable is 1 or control "Master BR dimmer" is set fast off then $variable = 0 set 'Master BR dimmer' to 30% set scene 'rest of the house' off wait 30 seconds set 'Master BR dimmer' off else $variable = 1 wait 2 seconds $variable = 0 I am hoping that this simpler approach will work for you.

So, you have not actually tried the program? Does it do what you want? It seems to me that you have a pretty complicated set of programs to accomplish your stated goal. Specifics will depend on how you define scenes and what switches control what fixtures. Conceptually, could you not do something just like you suggested: if control "Master BR dimmer" is set fast off then set 'Master BR dimmer' to 30% set scene 'rest of the house' off wait 30 seconds set 'Master BR dimmer' off else Given that you are trying to trigger a program from a device that powers the load (master BR dimmer), I would expect this light to initially turn off, then immediately rise to 30%. I am not sure there is any way around this.

It may help if you would describe the problem. The lamps turn to 20% when activated locally...how is this different than your expectations? Please elaborate on how you think they "should" work.

I agree. Try and see. This is how most of us learned to do things. I also agree that, conceptually, this should work, but sometimes there are often details that are difficult for the average user to predict, such as: what happens when one tries to change a ramp rate in a device that is currently executing a status change? Can one even write to devices while they are in a state of change? There may still be hardware or software limitations that limit your options here. But you can try and report back your findings. But wait...perhaps there is another option (just now thought of it). Insteon gives us the ability to set different ramp rates based upon different controllers. Is it possible to programmatically re-define the ramp rate for the remotelinc-as-controller at 8 minutes, between the times of 11 and 7 (or whatever you want), but leave the ramp rate for the master scene (PLM-as-controller) at .5 seconds. After the two-minute wait period, simply execute the master scene? Perhaps others could confirm whether this is even possible.

That is good to know. And the fact that the line of demarcation is I2 devices. Unfortunately, I suspect the limitation you suggested earlier, and the possibility that the remotelinc is already a controller in a scene with the devices-in-question, will make this an interesting programming question.