oberkc

I offered the RF theory as one plausible explanation (I have no actual evidence to support the theory)...mainly to consider the possibility that, sometimes, things happen for reasons beyond the control of insteon or the ISY. My experience is that if something happens because of the presence of the ISY, there is evidence in the log. If no log evidence exists, most likely the problem is elsewhere.

Spurious radio signals from unknown sources that the opener mistook as a remote control? Garage door remotes, I understand, are on shared frequencies. It is not unheard of that a door opens for no apparent reason.

The extension cord test was meant for the PLM,by the way. I apologize for the typographical errors.

I would not expect lack of ground to be a factor in quality of communications. Metal box, however, could impact RF range, if applicable. Consider, also the devices plugged into heame outlet and circuit as the PLM. These devices could interfere with PLM ability to communicate.

As LeeG described, there are only two "legs" (aka "Phases") in a house. For these purposes, I would use the term "leg" and "phase" synonomously. I tend to use "circuit" when talking about all devices on a given breaker. I started to suspect we were using terminology differently, so I am glad you cleared it up.

I am certainly curious how you know they are on the same "leg"...and that others are not. What is the load attached to the troublesome switch? Sometimes it seems that there are enough performance variances between a given device that one may work and another not.

I would use the PLM to initiate the phase detection mode. Go to smarthome.com and find the quick start guide. Min the guide, find the section titled "Use PowerLinc Modem as a Phase Bridge". Follow those directions. Let us know the results.

If there is a mismatch between the isy status and actual device ststus, I would first suspect a comm problem, likely beteen the PLM and the keypad. Have you confirmed communication between the legs of your electrical system? How may dual-band devices do you have? Do you have any range extenders? To test for this theory, choose one of your button scenes from the admin panel. Turn the scene on and off. Does the button status reliably change? Try a scene test on the button scene. If not reliable or fails the scene test, get an extension cord and plug it into a different outlet on a different circuit. Minto the extension cord plug the PLM. Doe the scene respond reliably now?

What is blinking green? The device you used to initiate the test, or the responders? What other dual-band devices do you have? I, actually, don't see the four-tap method mentioned in the user manual for the switchlinc 2477D. A blinking green LED suggests that it is linking mode as near I an tell on the user manual. Is your PLM dual-band? I would focus on confirmation that you have communication across the legs of your electrical system. Identify your dual-band devices. Find one that can perform the test, and confirm that you have another dual-band device responding appropriately (depends on model and era). Once confirmed, we can deal with inability to find the device. It is very possible that you cannot find a device because there is no communication between the electrical legs (or phases, if you prefer).

3) have you tried the 4-tap test? Why are you unable to initiate? Is it possible you are having difficulty tapping four times rapifly enough?

Choose the baulky device on the admin panel. Right click. Show device links table. Compare when done. If there are any mismatches, restore the device.

Cycling power does NOT cause a factory reset. One needs to depress the button on the device for a short period to reset it.

This is only temporary...a troubleshooting technique...to confirm or eliminate the possibility that the load is causing the problem. If you remove the load, and the scene tests now pass and the switches stay synced up, then this is a good indication that the neon lights were causing the problem and a filter is needed.

I believe the suggestion was to disconnect the neon lights from whatever device is powering them.

Have a certain number of devices is no guarantee. If you have not performed the test in the manual, I would not be confident. In my experience, this is not the case. Sometimes they can see each other on opposite legs, but the communication may be weak and easily disruptible.

In addition to the likely possibility of communication issues, check for ON levels related to this scene. From the admin panel, select and expand the scene. Within the scene select one of the controllers and view ON levels for each of the other two devices. Make sure none are zero. Do the same for the other two controllers. Regarding coupling the legs...this is normally performed by insteon dual-band devices. How many do you have? Have you ever performed the phase test described in the manuals for these devices? One check for communication problems is the scene test performed by the ISY-994. I believe you will find it under diagnostics. Choose the three-device scene in question. Run it a couple of times. Does it indicate failure?

Status and control both have a powerful place in the ISY-994 programming world. So long that one understands the differences, it is good to have both in your toolbag of methods. Glad you got it working.

Just be watching the PLM. These may be early signs of impending failure.

All programs execute...it is just a matter of whether the run THEN or ELSE. Depending on the logic employed, it can also not be necessary for all of the conditions to be true for a program to evaluate as true. For example: "If A or B" can be true even if either A or B is false (but not both). This is an example that will evaluate true even if "one of the conditions is false". Do you have a specific example of a program that is not executing as you expect?

I am still a little unclear about the extent and types of your devices. Given that you have eliminated x-10 address (relying, instead, on insteon for this communication) from a few of your keypads, how many devices do you have remaining that occasionally need the repeated x-10 commands? How flexible is this PC resource...can it send out insteon commands?

Yes, I would agree that this is a likely culprit. I must admit that I don't understand what you are trying to achieve by having an ISY program triggered by an X10 command which issues a resource statement which then issues the same X10 command. Is it not possible to control your widgets without issuing additional X-10 commands on your power lines? Also, since you are using insteon to now communicate between the ISY and insteon switches, and you have removed the X-10 address from these insteon switches, there is no value in providing backup communication. If you were to take this step out of your PC program, does this solve your looping problems?

Actually, I think you are making it more complicated than need be. It won't take anywhere near that long. I have used mutually-exclusive relationships, but find that they are, simply, not as versatile as using scenes. These relationships are enforced only within a given keypad, when one of its buttons is pressed. It is not enforced when called by other device and scenes, which I suspect is why you are having trouble. You appear to be using more than one keypad to control a given "activity", and the mutual relationships will simply not be enforced on one keypad when activated by one of the other keypads. Mutually-exclusive relationships are unrelated to any of your ISY scenes, BTW. My suggestion is to get rid of any such mutual-exclusive relationships you have established. Once done, I think you can achieve what you want (unless you have one of these older KPLs mentioned by EricK, and unless you intend to call these scenes from the ISY) with a single scene. This scene would include ALL the buttons from all the four activities and all the keypads. This means if you have four activities (default, dine, mood, TV) and controlling these activities from two keypads, you would have eight buttons in that scene. All the buttons would be controllers of that scene. The trick is to make sure that the ON levels are properly set for all eight controllers. I would expect that, with proper guidance from tech support, you can get this done in less than an hour. Take UDI up on this offer. I agree with the others regarding the scene terminology. Though it seems smarthome uses the term "links" a little bit more than they used to, the term "scenes" is definitely part of the insteon lexicon, not just of the ISY.

That is a complicated web you have weaved. I am not sure that I can even guess everything that is going on there. I also don't use "resources", so I have no clue what they might do to your programs. I missed where you described the device that "controls the light". Is it an X-10 device? I also missed where you described what (besides the ISY) would transmit an X-10 command. Are you dimming? So let me see if I have this straight. - you have a keypadlinc that you want to use to control a light fixture (button D) - you have a light fixture on an X-10 device, address A15 - you have some other devices capable of transmitting commands against X-10 address A15 Unless I am missing something, this should be relatively simple. I see too much going on (status rather than control, resources, redundant conditions, etc..) to even try to salvage what you have. Let's start fresh with a program to send X10 commands in response to the keypad button pressed (ignoring, for now, dim and bright commands): if control keypad button D is switched on and control keypad button D is not switched off then Send X10 'A15/On (3)' else Send X10 'A15/Off (11) Next, to control a secondary keypad button from the ISY, I believe it necessary to create a scene with the keypad button D as a responder. I will call it scene D. Finally, create a couple of programs: if X10 'A15/On (3)' is Received Or X10 'A/All Lights On (5)' is Received then set scene D on else nothing if X10 'A15/Off (11)' is Received Or X10 'A/All Units Off (13)' is Received Or X10 'A/All Lights Off (1)' is Received then set scene D off else nothing Let me know how this works out.

If you have confirmed that you have communication across the legs of your electrical system, using the methods described in the user manual for the dual-band devices, then I would not worry about additional dual-band devices in the garage.

Sure, that would work. I would have to check how "random" works (I think it can be any amount of time up to the specified time), but it appears that the ELSE path will be well complete before 3:00am (longest elapsed time is 4-1/2 hours, starting at 7:30). If so, the ELSE path is not necessary unless you are concerned about something not shutting off.