oberkc

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.

While you did not state it directly, is the button that you want to use to activate this action also in a scene as controller for the "couple of lights"? I recall that changing the ramp rate in a program is an option, but some older devices require a power cycle for that change to take place. If that is accurate, whether this will work for you could be device dependent.

Yes. Being in non-toggle does not affect ability to turn the button "on" or "off" from as a response to a scene command or program. It only affects action from a direct press of the button. I take advantage of this capability on my garage door buttons.

My, oh my! That is a lot of reaction to a single button press. It appears to me that the total reaction to the initial button press to the end of response being about 11 seconds, at which point there is a 13-second delay until the last two actions. I also note, with interest, the X-10 action. Unfortunately, I am not smart enough to see the hoped-for smoking gun (assuming that there is one). Perhaps this is a bug associated with KPL version 2D. The thoughts that go through my head are: -Is the device 'Master Bedroom / Master-Keypad / Mstr Bed Key B' also a scene controller? -What devices have address A6? Is 'Master-Cans over Bed L' or 'Master-Keypad' one of them? -What scenes include 'Master-Cans over Bed L' or 'Master-Keypad'? Based on my understanding of program triggers, a control would only trigger by a direct press of that device. Given this, I don't see how other programs or scenes would initiate your first program. Drawing a blank here.

This is as expected. The program WILL run (else path) at those times.

If this is of primary importance, then I suggest including your single keypad button in the scene (as controller) and setting the keypad to non-toggle-off mode (sending only off commands when pressed). If the light status is something you desire, then use an approach like kingwr in the first post.

Theoretically, I would have thought your first method to be fine. Given that it is not, I am unsure why your second would be any better. There are several methods I could think of to accomplish this goal. One would be folders with conditions based on time. Another would be to use program status, based on time. I can't say that there is an absolute best way, in my mind. Perhaps, if you post your existing program, someone might notice something.

Noted about the repeat. More correct, then: If Time is from 7:00:00AM to 12am (next day) Then Repeat Set 'ICON Relay 1' On Wait 40 minutes Set 'ICON Relay 1' Off Wait 20 minutes Else Repeat Set 'ICON Relay 1' On Wait 10 minutes Set 'ICON Relay 1' Off Wait 50 minutes

I doubt I can think of anything you have not already considered. Certainly, I see nothing in the programs which would cause this. My first reaction is to check the log for events occurring when the program-in-question ran unexpectently. From that, perhaps it would be possible to identify the offending device or program. Absence of any evidence suggests a gremlin somewhere.

Alternatively If Time is from 7:00:00AM to 12am (next day) Then Set 'ICON Relay 1' On Wait 40 minutes Set 'ICON Relay 1' Off Wait 20 minutes Repeat Else Set 'ICON Relay 1' On Wait 10 minutes Set 'ICON Relay 1' Off Wait 50 minutes Repeat

There is no "physical" way to wire insteon multi-way switches. One simply attaches all switches to hot and neutral. One (or more) of the switches should be wired to the load from the switch red wire. Once installed, create an ISY-99 scene, adding all switches to the scene as "controller".

I wonder if determining room occupancy, and whether such occupance is quick or otherwise, will be difficult to implement with door sensors unless you have confidence that open door = occupancy and closed door = gone. (My life experience suggests that there is little relationship between doors and occupancy.) Given that creating a program to predict the future is difficult, I would suggest that the only way to determine if an occupancy is longer than "quick" is, simply, to wait for quick to be over, then reach the necessary conclusion. I also suggest taking advantage of the built-in capability to halt program execution during periods of wait or repeat. In hyperpseudo code: if status "sensor" is occupied (however you define it) then wait "quick" do something else return system to nominal condition, whatever that is If the status of the sensor changes from "occupied" to "unoccupied" during the wait period, the program execution will halt before it gets to "do something".