oberkc

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

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.