Jump to content

Nodes respond to commands reliably, but status not reliable


siegeld

Recommended Posts

My ISY can reliably send commands to nodes in my Insteon network (of about 50 devices, plus four access points). Responses come back from certain nodes very reliably, and from other nodes not so reliably, and some nodes not at all. I have a few nodes where the response will come back 50% of the time - maybe less.

 

I am sure that these nodes have been linked to the ISY PLM correctly. I have also done "restore PLM" from the ISY to overcome trouble from the PLM linking bug. No real help.

 

Certain nodes have totally stop sending responses - but there are just a few in this category. These nodes that are now not sending responses at one point did send a response. Out of the blue, the responses just stop arriving.

 

I am not sure if this is a communication problem or an ISY problem. I do know that one of the nodes that is now not sending any responses at all is part of the multi-way (three-way) switch setup, and the other switches in the setup do respond to the commands from this particular node. This leads me to believe that it is sending out a response and at least the other switches (but not the PLM) are picking this up.

 

The problem I am experiencing is not time of day dependent.

 

I've put a scope up to my line voltage, and while I do see some noise in the 130khz range it doesn't look too bad.

 

When a device is sending out a response, does the response get sent out three times (as per the Insteon protocol to make things reliable) with other nodes re-broadcasting - or is the response just sent out once? The reason I ask this is I'm wondering if there is a particular reason why commands sent from the ISY to nodes is reliable but responses back not.

 

Help! Thanks!

Link to comment
Share on other sites

My guess, by the way, is that the PLM doesn't work very well. Perhaps it is not sensitive enough the the response signal?

 

I should add that it periodically has trouble speaking to several other nodes - even for a query.

 

I've plugged an access point directly into the PLM to see if that helps, and it does not.

 

I also should add that I have a hard-wired Insteon phase coupler installed, in addition to the four access points.

Link to comment
Share on other sites

siegeld,

 

I am so very sorry to hear about all these communication problems you are experiencing.

 

The first thing is to figure out how many links you have in your PLM. If the number of links exceed 417, then I can say with a 100% certainty that the PLM is at fault. To estimate that number:

1. Total number of button x 2 (each SWL counts as one button, KPL either 5 or 8, etc.) PLUS

2. Total number of responders only x 1 (InlineLinc, ApplianceLinc, etc.) PLUS

3. For each scene, total number of the members in the scene

 

I am not sure if this is a communication problem or an ISY problem. I do know that one of the nodes that is now not sending any responses at all is part of the multi-way (three-way) switch setup, and the other switches in the setup do respond to the commands from this particular node. This leads me to believe that it is sending out a response and at least the other switches (but not the PLM) are picking this up.

You are correct in your assumption: the problem HAS TO BE the PLM. Now, can you remember whether or not these strange behaviors start happening after you modify scenes (add/remove from scenes)? The PLM only hears traffic if therein exists a link for that device for that group. So, exceeding maximum number of links is certainly one of the first things I would look at.

 

Also, would you mind sending your http://your.isy.ip:port/WEB/NODESCNF.XML to tech@universal-devices.com?

 

Again, with sincere apologies for these troubles you've been experiencing,

With kind regards,

Michel

Link to comment
Share on other sites

Well - I have 106 devices including buttons on SwitchLinc, RemoteLinc, and ControlLinc devices and have 46 scenes, with no more than an average of 3 nodes in a scene. So, I guess I've got something like 250-300 by your count.

 

How can I verify what is really in the PLM database? I have tried to do the restore operation from the ISY and that does not seem to help the problem now though once before I do believe that I was hit with the PLM link bug that you suggested, and doing the restore helped.

 

I should add that certain nodes are intermitent. Not in getting the command, but in sending a response that the PLM sends to ISY. That is, if I push the switch a few times, one of the responses does get through. I'd guess that kind of problem is a communication problem, but not the problem with certain switches that now seem totally failing to send responses.

 

Also note that I think I have been able to restore the sending of responses in the past by deleting the device and link from ISY and the PLM, and then re-adding it. Is there any possibility that this would have a different effect than simply asking ISY to re-establish links with the PLM?

Link to comment
Share on other sites

siegeld,

 

Thank you for sending your nodescnf.xml. I think I know where the problem is (it's a PLM bug with an available work-around: PLM may delete the wrong links when you remove nodes from scenes for which the INSTEON group number is less than 9).

 

Could you please verify that the problematic devices are one (or many) of the devices which belong to one (or many) the following scenes:

 

David's Study Work

Rear Stairway (3way)

Down Hall Front (3way)

Foyer Hanging Lamp (3way)

Mudroom (3way)

David's Study All

Down Hall Rear (3way)

 

In short, could it be said that all the problematic devices at some point in time belong/belonged to one (or many) of the aforementioned scenes?

 

If so, we we can fix this issue immediately by:

1. Removing those scenes and recreating them

2. Restore the PLM

In effect, we are recreating the links that the PLM might have deleted on its own.

 

Firmware versions above 2.4.8 do not have this issue since, as a work-around, our INSTEON group numbers start from 20.

 

Thanks and with kind regards,

Michel

 

Well - I have 106 devices including buttons on SwitchLinc, RemoteLinc, and ControlLinc devices and have 46 scenes, with no more than an average of 3 nodes in a scene. So, I guess I've got something like 250-300 by your count.

 

How can I verify what is really in the PLM database? I have tried to do the restore operation from the ISY and that does not seem to help the problem now though once before I do believe that I was hit with the PLM link bug that you suggested, and doing the restore helped.

 

I should add that certain nodes are intermitent. Not in getting the command, but in sending a response that the PLM sends to ISY. That is, if I push the switch a few times, one of the responses does get through. I'd guess that kind of problem is a communication problem, but not the problem with certain switches that now seem totally failing to send responses.

 

Also note that I think I have been able to restore the sending of responses in the past by deleting the device and link from ISY and the PLM, and then re-adding it. Is there any possibility that this would have a different effect than simply asking ISY to re-establish links with the PLM?

Link to comment
Share on other sites

siegeld,

 

Great ... this is that piece of information that I needed to verify the PLM issue. So, please take a look at your nodescnf.xml (the one you sent me) and:

1. Remove and recreate any scene with element having a number less than 9

2. Restore your PLM only after you are done with ALL the scenes

 

No longer will you have to restore your PLM after you have done steps 1 and 2.

 

With sincere apologies for the inconvenience,

With kind regards,

Michel

 

I should add that I have frequently been making changes to scenes, but ever since you pointed out the PLM bug I always do a Restore PLM when I am done, just to ensure that the links are in order (as per your previous suggestion).
Link to comment
Share on other sites

OK, I'll try this tonight.

 

A related question: one SwitchLinc that has always been accessable from ISY has now stopped responding. ISY cannot check its status at all. What is odd is that this SwitchLinc is part of a three way circuit, and hence on the same physical wires as another SwitchLinc that is responding. The hardware of the SwitchLinc has not failed, and it still controls the other SwitchLinc in the three way setup. It is just ISY that cannot get to it.

 

This SwitchLinc is not part of a scene with ID less than 9.

 

When I had a problem like this on another device, I found the deleting and re-adding the SwitchLinc restored communication. I could try this again with this device, but was wondering if you had any clues as to what really could be going on.

Link to comment
Share on other sites

siegeld,

 

I cannot say that I have experienced this issue before. But we have had cases where a device "stops" responding although it can still control. Can you control your SWL from the other SWL in the circuit?

 

Please note that Query and any direct/point to point communications with a device do not require any links: they should work. If removing and adding the device "sometimes" fixes the problem, then I suspect that the problem is the device itself being in "locked" state and not responding.

 

With kind regards,

Michel

 

OK, I'll try this tonight.

 

A related question: one SwitchLinc that has always been accessable from ISY has now stopped responding. ISY cannot check its status at all. What is odd is that this SwitchLinc is part of a three way circuit, and hence on the same physical wires as another SwitchLinc that is responding. The hardware of the SwitchLinc has not failed, and it still controls the other SwitchLinc in the three way setup. It is just ISY that cannot get to it.

 

This SwitchLinc is not part of a scene with ID less than 9.

 

When I had a problem like this on another device, I found the deleting and re-adding the SwitchLinc restored communication. I could try this again with this device, but was wondering if you had any clues as to what really could be going on.

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...