oberkc

That is, indeed, a lot of devices. I would not be willing to start completely over, either. Fortunately, my suggestion about starting over applies only to the couple of devices and scenes with which I percieve you are having trouble. But it sounds like my perception has been less than accurate at times.[/img]

That was my first reaction...you had already created a bunch of links in the devices prior to ISY. I wondered if you had performed a factory reset on the device before adding to the ISY. If not, did you remove the links when adding to the ISY. Also, is it possible that there are some X-10 addresses in the device. I know it is a little bit of pain, but it doesn't sound like you have too many devices yet, so I would start over. Remove the devices from the ISY. Factory reset each of your switches, link them back to the ISY, then create the scenes. I would expect this to solve your problem.

Is this accurate? It appears you repeated KPL3. I may be missing something here, but you are using KPLs 1 and 3 as controllers for you dim and full scenes, yet the mutually exclusive condition are for KPS 1 and 2. Is this as you want. Could this be contributing to your problem?

I assume you have thought of this, but in case not...I use a laptop when working around the house and want to be able to get close to the device while making adjustments. Of course, this requires wifi, but I am guessing most of us have that already.

The "non-admin page"? Is that the first one that pops up? If this works the same as my mobile phone, you can still choose the "administrative control" option and see and control your devices. Not as pretty, but may work for your puposes.

Flashing lights at my house usually mean communication difficulties. Have you added any new electronic devices in your house lately that might contribute to these problems?

I do not claim to understand all those log file lines, but I associate those max hop statements with less-than-robust communication. I would be looking for sources of electronic noise and interference. Do you use any filters? Access points?

When I have intermittent problems and less-than-full scene response, I can usually trace that to communication issues. Powerline noise or "signal suckers". Communication problems can slow down responses and force rebroadcasts. I think these can result in signal collisions and the like. It may be possible to mitigate this problem. You could create an "all device" shutdown program, and send off commands to all devices, inserting short (a second or two) waits between each. This may work better. The best best is to test for communication quality (under tools, scene test) and identify and remove (or filter) and problem devices in your house.

In case you did not realize it, there is an "event viewer" under tools. If you don't see anything there that helps, I am with the others.....you have noise problems.

I am not sure I can respond to everything you ask, but I can try a couple of points: I believe the answer lies in "control" versus "status". From a time standpoint, you can choose a specific time (when time = XX:XX) or range (from XX:XX to XX:XX). A control represents a one event (device sends an on signal). Status represent the fact that a device is on, for as long as it is on. Knowing this, most commands that I can think of to perform in response to these conditions are one time commands (turn on, turn off, dim, bright). I am not sure how one would run a program indefinitely, based on the if statement. Else is never evaluated. Only the "if" statement is evaluated. The program statments will run one time when the "if"condition is true. However, if the "if" statement remains true, and somebody comes along and trys to create a condition contrary to the else statement, then the else statement will run again. For example, if the else statement tells switch A to turn on, and somebody comes along and turns it off later, then the program will immediately turn it back on. I hope I am making sense here. "Then" and "Else" conditions can be called from other programs. The syntax looks like: Run Program "program name" (then path)

I use a statement in a program: set scene "my lighting" off (or something close to that). This appears to turn off all insteon devices. It has no affect on X-10 that I can tell.

Since your links pre-existed your ISY, the only question that remains is how you added your devices. When linking, there are three options. It sounds like you may have chosen the option to link without importing the existing links. Perhaps I, too, misundertand these options. Fortunately, this is easy to fix. First, I assume all your devices are linked to the ISY/PLM. Correct? Go ahead and create the various scenes you want in the ISY. Once done, I would use the "restore device" option (available by right-click) on each device in question. Restoring makes the device links match the ISY. If your programming and system is relatively small at this point, you may also consider performing removing your devices from the ISY, performing a factory reset on the devices, relinking, and creating the scenes from scratch. The factory reset would remove those links, as well as any residual X-10 addresses, which can cause problems as well.

I understand also that if you manually create links after a device in linked to the ISY, there is no way for the ISY to know the links are there. However, I thought that if an insteon device had existing links (added manually) prior to linking to the ISY, one could choose the option to keep those links at the time when that device is linked to the ISY. Did your links exist when you added the device to the ISY, or did you add them afterwards? When you linked these devices to the ISY, did you choose the option to keep the existing links?

I've not experienced this, but I wonder if you have some electronic device failing somewhere. Perhaps it is one of your insteon devices failing? If it were me, I would be shutting off circuit breakers during one of these outbreaks of flashing lights, to try to identify if there was a particular circuit that is causing this unwanted traffic. Hopefully, you can find a particular circuit that, when disabled, causes the noise to cease. If so, perhaps that will narrow down a search for a failing device.

a couple of things come to mind quickly. First, make sure you created all the scenes with the ISY. I assume you did. If not, you may have some links in various devices that are causing some unexpected behaviour. It sounds like you want to be able to turn the hall lights on from both of the toggle links and the keypad E. Correct? In this case, all three devices should be programmed as controllers. Make sure the scene is created this way. If you are unsure whether these conditions is untrue, you may consider performing a factory reset (eliminating a devices existing links) on all devices, readding them to the ISY, then recreating your scene (with all as controllers). Hopefully, this will solve your problem. If not, we can dig deeper.

I use smarthome filterlinks with great success on my insteon system.

To add to the thoughts of Mr Kohanim, I think what you are experiencing is the feature that allows one to set different on levels and ramp rates, depending on which controller is used to initiate the scene. When you click on the scene in the main tab of the ISY, the on- and ramp-rates will be set for when the scene is activiated by the ISY,. If you want to set the rates for when the scene is activated by your party button, expand the scene so that it shows the devices within, click on the party button, and set the sliders to your taste. Note that you can set them different than the master scene levels if this is desirable to you. Note that you can set them different for each controller within the scene, so that different buttons can activate different levels. Finally, you can choose the button that allows you to copy scene attributes from the main scene. While initially this may seem overly complicated, it is, to me, a nice feature giving extra flexibility in the control of your system.

There are whole threads addressing the programming for motion sensors. Check them out. Good reading. Your program will turn the lights on any time the two conditions are true. When you manually turn the lights off, the conditions are again made true (so long as you are within the time-out window of the motion sensor), so the program will turn them back on. Perhaps a better way would be to use control, rather than status, of the motion sensor as a condition, then use a wait action after turning the lights on. After the wait, send a command to turn them off. (This assumes that you want them to go off after some prescribed period.) There may be a couple of additional considerations, so search on motion sensor and check out the other threads. I think there is also a wiki article on this subject.

There is a scene test. If it passes this test, I understand one can conclude communication being good. I assume, also, this is regarding communication between the scene devices and the ISY. I assume it does not verify device-to-device communication. Still, it is a useful tool.

The ability to set these parameters differently for the primary scene versus the individual controllers allows flexibility to have different responses depending on which controller is pressed. The primary scene parameters is, I guess, the parameter executed when controlled by the ISY itself. I have found a bit of a learning curve in programming the ISY, but once you get used to the idea of cut-and-paste, updates versus adds, the actual creation of these type of repetitive-lined programs can be done pretty efficiently. I guess that would explain my issues with older devices and confirm the recollections of Quixote. Thanks.

Hopefullly, someone can offer suggestions based on those specific error messages. Unfortunately, they mean nothing to me. Sorry. I assume that your scene tests failed? I wish I could give come up with any new ideas, but I am sure you by now you know the routine trying to identify problems with communication and all the normal kinds of questions to ask. Not fun.

I do not expect this to help. Capability to adjust on levels and ramp rates came in 2.6.7 Regardless, I have never had trouble updating. I recall it simply a matter of going to the posted link and saving the zip file at some location that you can remember. Once done, go to the admin console, under the help tab, choose "manually upgrade my lighting". After the appropriate response to the prompts, locate the zip file and the ISY will take care of the rest.

Consider it confirmed. I am able to manually adjust ramp rates without pulling the tab, and can do so in a program.

I believe that is incorrect. I am able to change ramp rates without pulling the tab. That is part of typical setup I thought....link devices to ISY....add to scenes....change scene properties, including ramp rates. All this is done without pulling the tab in my experience. In my experimental program, I was able to change on levels without pulling the tab. I admit, though I did not try to adjust ramp rates. I will try and report back.

comminication problems? Have you tried a scene test on your troubled scenes?