ds10

A tuned circuit as in this diagram makes the most sense. This works like a trap on a multi-band antenna, allowing some frequencies to pass, others simply see it as a brick wall. The goal with such a circuit is to make it seem, at a given frequency, that the wire does not continue past that point. A UPS or surge protector is purposely attenuating, not simply ignoring, frequencies it was designed to remove. I'll have to look up the specs on the various surge devices I use to see what their attenuation is at the Insteon signaling frequency.

A good and well designed UPS serves two purposes: it provides power continuity during outages, and it filters noise from the power line. A surge suppressor of any quality provides the latter alone. A whole-house suppressor provides the sanme service, removing noise from the power lines. Insteon signals are in effect power line noise. They are in effect AC waveform signals not near 60Hz. It would be a big help to understand the design of the filterlinc module and it's goal. There are two possible goals: to block attenuation of Insteon waveforms by devices designed to suppress transients, or to block other transients at the frequencies used by Insteon. My remarks reflect my expectation that the server-class UPS gear I use does not impose noise on the grid (something that I am now curious about and will look at with an oscilloscope when I get a chance). Making that possibly incorrect assumption, I then supposed the filterlinc must be designed to prevent attenuation by the UPS, and if that were the case, then by extrapolation surge suppressors could be a culprit too. It would seem what I most need is to see a circuit diagram of the filterlinc, so as to understand what its purpose really is. Clearly my line of reasoning was flawed. I'm sorry you took my attempt at reasoning out a root cause as a personal attack. That certainly was not intended.

I assume each and every surge protector in the house too, then? And should the wired-in whole-house lightning protector be removed? Of course none of this explains why a dual-band (wired & wireless) PLM can't talk reliably to a dual band lamp module in the next room. The RF signal should have no trouble reaching.

Most devices came back to functioning after power cycling both the PLM and the ISY. In the event viewer we do see INST-ACK. Since I've got no point of reference for this protocol, I didn't know if that was good or bad. We have no thermostats. We do have some dual-band devices, including the PLM and one lamp module. We do have a wired signal bridge at our breaker panel. We do have the RF repeaters too. If there's some disturbance, it'd be really useful if there were a way to diagnose such. We do have UPS equipment in various places in the house, since I do run a business and have equipment that needs to stay up. We have an auto-start generator for occasions when the power fails, so the UPSs really just run for a short time until the generator starts (5 seconds). But we have not had any power outages lately (the generator sends me text messages in the event it has to start). Last time we had a major set of issues, you went through my list of devices and pointed at one that needed to get replaced. It was replaced, so I'm guessing it's not a bad device at this point. Can't fathom what else we need to do, aside from possibly ripping out all of the Insteon gear and giving up. Tonight I came home and found one of the outdoor lights did come on by program, the other did not (one comes on at dusk, the other at dusk plus 20 minutes). So clearly we still have issues.

Came home tonight, no lights on. Connected to the ISY-99 over the LAN and it's reporting having trouble accessing every device. We've had this happen from time to time, and it's getting old. Usually the way I clear this is to power cycle the ISY. I guess I'll do that yet again. It's possible the issue is the Insteon PLM, but hard to know. The event viewer shows very little. When every device you try to control with the ISY comes back with "communications error," you start thinking it's the ISY and not the modules. We've upgraded the ISY, we've updated the PLM, we've replaced modules we were told were versions that had issues. Everything works great for weeks to months, then we come home on a nice evening, no bad weather or anything, and the ISY/PLM setup can't talk to anything. Any thoughts besides finding another controller setup?

I agree completely with the concerns raised. I ran into the same issue as Teken with the All Off triggering the garage door to open. I have mine set up on Momentary A at this point and that's working better. What I'd REALLY, REALLY like to see is an FAQ for "So you're installing an IOLinc garage door module, here's how to do it successfully." The other thing I'd love to see is for the ISY to query the IOLinc Sensor a short while after the garage door is opened or closed, so that the ISY shows the correct status. Really, the same goes for any other module that updates without the ISY instigating, whether that's a light switch that sends a command or a sensor reading a status. It sure seems to me like the status doesn't get distributed by the affected modules all that well (if at all). I don't know if that's just a weakness of Insteon overall. The All Off affecting thermostats and garage doors points to a problem with the underlying technology, not Universal Devices' issue, really, in trying to overload a protocol intended to turn lights on and off to perform other functions. The Insteon protocol needs to be revisited to permit classes of devices, such that commands like "All Off", clearly intended for lights, does not wind up opening (or closing) garage doors, or disabling thermostats. Both could have very serious consequences, especially if issued remotely (thinking about a house winding up with no heat and frozen/broken pipes in the winter time after an all off shut down thermostats, for example).