oberkc

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.

I use an android phone (v2.3.4). I can tell you that the web-page part of the ISY works fine, but the admin console page (I assume the java part) does not come up. I can access the devices, program status, scenes, etc. I cannot add or edit programs. Unfortunately, I have never investigated whether java for android even makes sense or exists....never felt the need to get to that level of detail on a cell phone.

Those two lines were the ones that caught my eye as candidates for triggers for your other program. My first inclination would be to try a couple of experiments. I would try running the button-b program with the can lights in various starting configurations (off, 25%, and on). This is an attempt to identify if there is some predictability regading when the first program reacts ton the "b" program, or whether it is truly random. If some pattern or relationship emerges between the two programs, or you can find a way to reliably trigger the first program from the second, I would be tempted to remove, one at a time, the can lights and the KPL main button from the program to see if they, indeed, act as triggers. Given both of our understanding that insteon signals do not "cascade", I would be a little surprised if this is the problem, but it is the only thing that jumps out at me.

It is my understanding that when one deletes scenes from the ISY, the ISY will delete the "locaL" scene records within any affect device.

Thanks for the clarification. This is as I suspected. I still wonder why you originally stated that: "Only the main "off" on the kpl should initiate this program."? In my mind, the "off" of the other switch would also initiate this program. I continue to consider the possibility that some of the keypad-b program is triggering this program, but can only suggest experimentation with different starting conditions (mostly associated with the can light switch) to discover any cause-effect relationship. Of course, it could be some type of anomoly as suggested by gviliunas.

I am a little unclear the difference between: 'Master Bedroom / Master-Cans over Bed L', (from program) 'Master Bedroom / Master Bedroom Keypad', (from program) and "main" (from post text) I wonder if your b-button-initiated program actions are triggering this program and, perhaps, the reason that this program does not always evaluate as true is because sometimes the 'Master Bedroom / Master-Cans over Bed L' is not initially off. Assuming that your master-cans is a device other than the keypad, it seems to me that this could be triggered by actions beyond "only" the main button. For example, if your cans were initially off, and then turned off, this would trigger your program AND evaluate as true, even though no keypad main button were pushed.

apostolakisl understanding is consistent with mine, but I think there can be times when the ISY DOES assume status. I understand that if the ISY does not recieve an acknowlegement, it WILL assume that a device responded properly. Also, I understand that scene commands are not acknowledged, by design. Regardless, a system being out of sync tends to point to communication problems, in my mind. I think it is a little bit more (barely) than a guessing game, but apostolakisl point is well made. It is often not easy to identify electrical devices that cause problems with insteon communication. The ISY does provide a tool that I can be useful in this task: the scene test. While it does not identify sources of noise, it is a baseline against which one can judge the presence of interference (noise or other types) and changes to communication integrity as one attempts to troubleshoot problems. Otherwise, yes, identifying sources of problems is often little more than observing cause-and-effect relationships as one isolates and removes potential sources of "interference". Often times, it is the summation of multiple devices that can cause problems.

There are a lot of those posts. I suggest starting with the wiki.

I don't know if it is too much, but the fact that you feel there is a need would concern me. If you are getting a lot of devices out of sync, I would be trying to find out why.

I assume that "flood HVAC" is the inlinelinc that controls the two floodlights and that "B1-Porch/B5" is the keypad button. Is this correct? What is the device "Flood Master"? Is this the scene you reference (if so, I expected the program line to read set SCENE "flood master" on)? I assume you have checked the event log to confirm receipt of the trigger condition. If not, I would. If you are receiving the trigger condition, have you checked program status (programs>>summary>>last run time) to confirm that it is running or not? Assuming you are receiving the trigger condition, and the program is running, I only assume that there is something going on with one of your scenes which counteracts the effect of the program. Regardless, I don't understand the purpose of your second "then" statement. Why not a more simple program: If Control 'B1 - Porch / B5 - Floods Master' is switched On or Control 'B1 - Porch / B5 - Floods Master' is switched Fast On Then Set 'Flood HVAC' Fast On Else - No Actions -

To "cross-link" two insteon devices, create a new ISY-99 scene, with both devices as controller. I doubt that the creation of scenes broke anything. I suspect is was the adding them to the ISY that removed the existing link records. I am unsure what your "expected behavior" is. It may help to describe what you want to happen in response to an "on" and "off" command from each switch.

No problems in my mind. I have been considering doing the same thing for some ceiling fans.