oberkc

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".

Understand, too, that ramp rates (if dimmer) and on-levels can be different based on the contoller which initiates the scene. If the PLM is the controller, then the rates and levels are defined at the scene level. If another device is a controller, it could have different rates and levels. Also, an on-level can be set to zero (off) in many devices. If this is the case, then it would appear as if a device is not responding to a command from a controller.

Best is always subjective, but this is the way I do it. A timer program generally looks like: if time is sunset then set scene "interior" on set scene "exterior" on Of course, you could use a discrete time rather than sunset.

There is no special wiring required for a three way configuration. Insteon devices are wired no differently in a three-way than for any other way. Yes, you need to create a scene to behave as a three-way. The ISY-99 scene would include both devices, both as controllers. It sounds as if yours system is working normally in this case. I have never gotten this option 'apply to all devices' to work. When I want the settings of an individual controller to match that of the scene, I choose the controller and choose a button "copy from scene". The foyer dimmer is a secondary button, therefore, it controls no load. To what insteon device is your "Foyer" light wired? In your scene, I see only "button B", "the Foyer dimmer (this is the secondary dimmer to the 8 button keypad)", "kitchen dimmer" and the "living room dimmer". I am confused. I see no "main button for the Foyer" in your scene. What is this button, how did it respond, and how did you expect it to respond. No, not yet. I am not convinced anything is messed up. I more suspect a bit of confusion about the understanding of controllers versus responders, and about which devices control which loads. Hopefully, we can get this worked out.

I have some devices which don't keep certain settings until you cycle power. I think it could be related to being older versions. Have you tried making the changes, then temporarily pulling power from the affected devices?

I don't have the network interface and use on android smartphone. I use conductor app. Have never used Mobilinc, so I cannot compare, but my impression from reading other's thoughts are favorable.

I don't think I have yet to find a programming example where there was ONLY one way to do things. however, nothing is coming to mind that is any simpler. It seems your approach is pretty compact. Do you want a given light to come on, if it comes on, at the same time? Off when?

I agree with the inference of LeeG: I expect your program will never trigger, because it has no conditions. While your folder-embedded program may become enabled and disabled, based on a set of conditions, the program still needs something to force an evaluation to run. As an aside, I must admit to having having never understood the purpose of this conditions such as: if status 'motion sensor' is on and status 'motion sensor' is not off versus if status 'motion sensor' is on It seems to me that both would trigger under identical conditions (any change in status) and evaluate the same (true only when motion sensor is on).

There are a couple of android apps that provide control of devices and scenes, conductor being the one that I use. I presume, from the specific mention of "admin panel", that the OP was looking for more than control...the ability to create and modify programs, scenes, and folders. While conductor provides the ability to control devices and scenes, as well as execute programs, Conductor does not provide the capability to manage your system (change programs, link devices, create scenes,...) Perhaps I read too much into it.

I will let you decide what is best. I agree with LeeG that scenes are generally preferable. However, for the going-away button, I chose a program. This offered two benefits. One, I could add a delay to allow me time to leave. Two, I could take advantage of programs already in place that perform the same function at different times. I assume that a program could also take care of your thermostat. In my case, I also use that button for a second function, to adjust various program schedules. The button being on signifies an away condition...off is home and a lot of lights come on at sunset. When away, fewer lights come on at night. The program looks something like: if control 'keypad' is set on then wait 5 minutes run program 'turn inside lights off' then path run program 'turn outside lights off' then path The two programs already existed and were otherwise schedule to run at the end of the day. The actual lighting schedule is also based on programs. I have home programs in folders active when the "away" button is off (at home). I have other programs in folders active when the "away" button is on (away).

This is mostly a user-to-user forum, as I understand. Few are able to speak on behalf of Universal Devices.

You don't have to wait. What is the program's current status...True or False. If it is false, then the last time it ran, it ran the "else" path. Opposite is true for "true" status. If the program ran, then most likely a communication problem.

Yes. I would concur with that assessment.

I use conductor also. If adding and updating ISY programs is the goal, conductor is NOT the answer, unfortunately. Conductor provides a bit more finger-friendly interface to your scenes and devices. It allows access to existing programs and allows the creation of widgets for such purposes. It does NOT give program status or access to the program language. I have found it to be a less reliable indicator of device status. I don't think I would use conductor for the purposes of going "around the house programming and tweaking".

Well...I suspected you had considered everything that I could think of. You know more about most of this than do I. But it was worth a shot. I know that, theoretically, insteon is not subject to those dreaded signal collisions, but it is easy enough to try out the insertion of some wait statements in key places. Unfortunately, that makes your program subject to some self-induced stoppages, should the right conditions arise. Still, perhaps it is worth a try. But there is nothing jumping out at me that is obviously wrong here. Will continue to ponder and keep watching this thread.