oberkc

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.

Poor communication can cause wrong status.

I know that some of my module LEDs "flutter" during insteon traffic. I can't say that I have noticed any of my switch LEDs doing the same. Furthermore, I have not had one lock up as a result. If a factory reset does not solve the problem, I would tend to guess hardware failure of some sort.

Yup. On the other hand, if you wanted random, unexpected can be good at times. Alternatively, you could make these times relative to darkness or sunset if lights coming on at EXACTLY the same time every day is too obvious to the would-be intruder.

I like to keep things simple. Fewer programs are better (to me) than more programs. if time is from 6:00pm to 7:00pm (same day) or time is from 8:00pm to 9:00pm (same day) or time is from 10:00 to 11:00pm (same day) etc... then turn lights on else turn lights off Obviously, adjust times to suit.

Your "stop" statement halts execution, I believe. It does not stop a program from subsequently triggering and restarting. As a troubleshooting step, temporarily disable these two programs and see if this solves the problem. Without seeing them, it would be wild speculation on my part to conclude that these are an issue. I think we know, however, that it is not a motion sensor failure. It is not a failure of communication between motion sensors and PLM. The program appears to run. Despite passing the scene test, this still sounds like a possible communication problem. Do you have dual-band devices CONFIRMED on both legs of your electrical system? If you run an extension cord to outlets in other rooms and circuits to your PLM, does the performance change? Is your PLM plugged into a surge suppressor or UPS? Near any of these?

Steve, Sorry...I was unclear. If "run then" results in the same symptoms (what I called failure mode) where the "first scene" initially fails to respond, but the rest respond acceptable. The way my mind works, my earlier questions were simply trying to isolate the cause...is the program faulty? Is the scene faulty (or corrupted)? Is the ISY seeing the motion sensor commands? Has the motion sensor failed? Runing the "run then" command was, to me, trying to confirm that a normally executing "then" path results in the same problems. If so, then I would conclude that this is likely not caused by failed motion sensors or faulty communication between motion sensor and PLM. Other things one can do is to watch the event viewer to see if the ISY sees the motion sensor. Since you stated that the program shows TRUE at the proper times, I have tended to discount problems with motion sensors. Since your program does little other than turn the same scene ON and OFF, but only some of the scene commands appear to fail, I tend to discound faulty or corrupted scene links, so this leaves (in my mind) intermittent communication. Other possibilities: are there other programs that include this scene, either as conditions or responses? What are the two "p stairs...." programs? Could halting these cause your first scene command to appear to fail?

I cannot help with the error statements. If, in you example program, it runs runs (shows true) but does not work as expected, what happens if you select the program and "run then"? Is the failure mode repeatable? If yo select the scene, itself, from the device list, can you reliably control it from the admin console? Since it appears that you have an intermittent problem, I would tend to suspect marginal communications. Have you ever performed a scene test on this scene? Does it pass?

My perceptions from this log is that you have pretty darn good communication. Hops left=2 suggests, I understand, there was little need for retries and retransmissions. Given this, it is hard to imagine how you can improve your delay by improvements in this area. As for my experience, I would guess that time between detection and lights are aroudn a second..