Jump to content

Failed communicating with...


Recommended Posts

Posted

 

When filtering, don't forget the ISY's power pack. While the PLM obviously cannot be filtered the ISY power supply definitely should be. When I first installed my ISY-99i I had both the power pack and PLM on the same outlet. Moving the power pack to a different circuit with a filter made a very significant improvement.

 

I sure hope someone develops and sells a PLM that communicates at least as well as a SwitchLinc.

.

 

JMC,

I never found any issue with having the ISY's power pack in the same outlet as the PLM. Sometimes moving a device can appear to make a difference, when in reality your communications reliability is very random and true results are difficult to gauge. I specifically tested the adapter (one that came with the ISY) and found no signal attenuation issues.

I did not specifically look for noise but have never experienced any issues prompting me to need look for noise.

 

The last sentence confused me. Are you saying they do not? That has not been my experience.

 

Where is your PLM located with respect to the service cabinet? Do you have your worst problems communicating from the PLM to devices on another phase (leg) or on other circuits that may be distant from the PLM (in terms of cable length from the PLM to the service and then back out on another circuit)?

Posted

Michel Kohanim wrote:

 

Quick question: are any of your SwitchLinc dimmers reporting as v35 (in the Admin Console)?

 

 

Yes, I have 3 V.35 SwitchLincs in my system. They are scheduled for replacement as soon as some of 2477D dual-band devices arrive. I knew that v.35 units had been implicated in scene issues. Do they cause other problems as well?

Posted

ELA

 

The PLM is about 6 feet (wire length) from the service cabinet. Everything on that circuit except the PLM, a TW523 X10 modem and an EZIO6i is filtered using Leviton 6287s.

 

The improvement I saw when I put the ISY power pack behind a filter may have been a coincidence but it was repeatable.

Posted

Hello JMC,

 

Yes, SWL v35 would cause all sorts of problems including interference with other devices. I would not spend too much time on the system as is till they are all replaced: it would be like chasing a ghost.

 

With kind regards,

Michel

Posted

MIchel,

 

Are there any other devices or versions known to cause problems that I should watch out for? I have SWL v. 35, v.37, v.40 and v.56; KPL 6 button v.00 and v.2d; Compacta EZIO6i v.00; and APL v.00

Posted

Hello JMC,

 

Please remove your KPL (it was added by force and thus 00), add it back using Link Management | Start Linking, add your KPL back. If it shows up as versions 2A or 2D, you would want to replace them.

 

With kind regards,

Michel

Posted

When I removed and relinked that KPL it identified itself as v.2d. Evidently SH now has dual-band KPLs. Is anyone familiar with them? Any particular version to avoid?

Posted

Michel,

 

Do the KPL v.2a and v.2d exhibit the same problem as the SWL v.35? Since the v.35 problem is recognized for warranty replacement, maybe the same will happen for the v.2d. Is there a "safe" version of the KPL?

Posted

Hi JMC,

 

2A and 2D have different issues. I call it ICE (Intermittent Christmas Effect); i.e. once in a while devices linked to 2A and 2D start turning on/off by themselves.

 

We have not yet had any problems with 36.

 

With kind regards,

Michel

Posted

I finally got the v.35 SWLs replaced so now all SWLs are v.37 or later. I still have 3 v.2d KPLs in the system but they are not exhibiting the ICE that Michel mentioned. Do these KPLs contribute to communication problems? Overall communication appears to have improved but I still have problems with scenes. I can have two SWLs that work fine individually but when I put them together in a scene one will not respond when the scene is activated. Querying the device produces a prompt response though. I also have a three-gang box with 3 v.37 SWLs in it. All three receive and execute commands from the ISY perfectly but turning them on with their own paddles produces no reaction at the ISY. The map still shows them at the last state they were commanded to by the ISY. I have deleted them and added them back as New Insteon Devices with no apparent result. Only one of the three has a load attached and it is an incandescent bulb. There are no obvious sources of either noise or signal attenuation on that entire circuit.

 

I have to admit I'm getting a bit frustrated.

Posted

Hello JMC,

 

Those KPLs may contribute to the problems you are having.

 

This said, and specifically to address the SWL issues (two SWLs in a scene where one responds and the other does not), please do be kind enough to right mouse click on the scene to which both of these belong and then choose Scene Test. Do they both succeed?

 

With kind regards,

Michel

Posted

I did the test as you suggested, one light succeeded and one failed. Interestingly it was the light which had failed to respond to normal commands repeatedly earlier in the day which succeeded when I ran the test. The one which failed the test succeeded with regular commands earlier. Most of the other scenes are under program control this evening, I'll test them during the day on Wednesday.

Posted

Hello JMC,

 

There are three cases:

1. Either the failing switch does not have correct link records --> try Right Mouse Click | Restore Device

2. Or, its load is connected to something that causes major noise ... to test, unplug/unscrew the load to the switch and run the same test

3. The device is defective

 

All the above assume that both of these switches are in the same gang box.

 

With kind regards,

Michel

Posted

I tested each scene this morning multiple times with all programs disabled. After resetting some SWLs back to factory settings I was able to restore them to proper operation. I am getting "Cannot communicate with" error messages on some devices when I attempt to restore the device although a simple Query seems to work fine. 4 of the SWL s that won't take a restore are in the same 4 gang box but all of their loads are incandescent bulbs so I'm a bit confused as to a possible source of noise. There are no electronic devices (other than the SWLs) on that circuit and all of my computer and entertainment equipment is filtered, as all battery chargers. I do have some CFLs but they are all controlled by conventional toggle switches so when the switches are off they shouldn't be an issue. I'll be getting replacemts for the v.35 SWLs from SmartHome and I'll use them to try to isolate any further equipment problems.

Posted

JMC

 

It is not uncommon for a Query or simple On/Off command to work but not able to Restore when there are communications problems. Each Query/On/Off is a single message. It may take a hundred or more messages to Restore a device depending on the number of link records that must be restored. Even a simple Restore can be dozens of messages. It only takes a single message with associated automatic retries to fail to cause the Restore to abort.

 

Noise does not have to exist on that specific circuit to create a problem. One approach is to turn Off all possible breakers but those for the switch circuit and the ISY/PLM and see what happens. If the Restore works then turn the breakers back On one at a time until the failures occur.

 

Lee

Posted

I know about the difference between a simple query and a restore but I think something else is going on. I can query one device and get a "cannot communicate with" error for a completely different device almost as though communication failures are buffered up and retried whenever a communication is attempted.

 

I've also noticed that a scene test can initiate a WeatherBug update even if the scene has nothing WeatherBug related in it.

 

I don't have equipment for measuring line noise but I have been through the entire house and almost everything other than an incandescent light bulb has a filter on it. The oven and HVAC are about the only exceptions.

 

It is interesting to note that all of the Insteon devices that are now having trouble, even the v.35 SWLs, were communicating with each other with no problems before the 2413s PLM was introduced into the system. I have to believe that device is a major source of my problems.

Posted

It is interesting to note that all of the Insteon devices that are now having trouble, even the v.35 SWLs, were communicating with each other with no problems before the 2413s PLM was introduced into the system. I have to believe that device is a major source of my problems.

 

Can you explain this further? Do you mean before you introduced an ISY + PLM or a new PLM replacement?

 

One helpful exercise to help you figure out issues is to map out all circuits with Insteon loads on a drawing showing the approximate cable lengths and routing ( from the device to the service cabinet and then back out to another device).

 

When an ISY PLM is introduced this device then has to be able to communicate with every device, as opposed to just a few other devices in the same scene. Is it possible that the devices you have issues with have a longer signal path to and from the PLM?

Posted

I meant before I added the ISY/PLM, although I have tried a new PLM just in case the first was defective.

 

Unfortunately my site map did not scan well, detail are way too small to read.

 

Some of the Insteon devices are 100' or more from the service cabinet so total signal distances between devices can be as long as 200'. The line from the service cabinet to the PLM is less than 6 feet but that may be moot. I disabled the 3 v.2d KPLs and communication problems seem to have disappeared. I'll monitor for a few days and if I don't see any change I'll assume they are the problem and either replace or do without.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...