j0dan Posted July 22, 2011 Posted July 22, 2011 I have a SwitchLinc that keeps breaking its connection to scenes. Up to once a day I need to delete the switch from all scenes and re-add them. When adjusting scene settings for that device, I get SSL errors, device errors, and other confusing error messages. After I delete and re-add it to the scene, it works. Restoring the device does not fix this either. I thought it was a problem with the device, so I replaced it with another, and placed the switch on the other side of the house (different circuit) where an existing SwitchLinc was working perfectly. I have the same problems with the new switch in that new location. The device also doesn't always send on/off (when physically pressed) commands back to the ISY unless it is a Controller in a scene (I just have a test one.) What could be causing this? I have a network of about 15 devices and have never had communication issues except with this one.
LeeG Posted July 22, 2011 Posted July 22, 2011 j0dan "I have the same problems with the new switch in that new location." I'm sorry but I don't understand this statement. SwitchLinc A has a problem at location A. I think SwitchLinc A was moved to location B and a completely new SwitchLinc is now installed in location A. Now, which location has the problem, location B where the old SwitchLinc was moved to or location A where a new SwitchLinc is installed? It sounds like a link record issue in the SwitchLinc. The SwitchLinc cannot control Scenes if the link records are lost or damaged. When the SwitchLinc is working, run Tools | Diagnostics | Show Device Links Table and note the exact results. When the failures occur run the Show Device Links Table again and note any differences. The SSL errors are a total mystery. Insteon devices have no relevance to SSL. Let us know what if any differences exist in the device links table and we can go from there. Also did the failure follow the SwitchLinc or stay at the original location? Also what is the firmware level of the SwitchLinc? V.35 firmware ia famous for Scene communication problems. Lee
j0dan Posted July 22, 2011 Author Posted July 22, 2011 Thanks for the reply. "I have the same problems with the new switch in that new location." I'm sorry but I don't understand this statement. SwitchLinc A has a problem at location A. I think SwitchLinc A was moved to location B and a completely new SwitchLinc is now installed in location A. Now, which location has the problem, location B where the old SwitchLinc was moved to or location A where a new SwitchLinc is installed? I replaced the switch at location A, when that didn't fix the problem, I moved it to location B (a confirmed working location). It sounds like a link record issue in the SwitchLinc. The SwitchLinc cannot control Scenes if the link records are lost or damaged. When the SwitchLinc is working, run Tools | Diagnostics | Show Device Links Table and note the exact results. When the failures occur run the Show Device Links Table again and note any differences.I'll try that next time it breaks. Probably tomorrow. IIRC, I would get communication errors when trying to get a links table. The SSL errors are a total mystery. Insteon devices have no relevance to SSL.I understand that it has no relevance, but it seems the ISY gets very confused when there are communication errors with this switch. Let us know what if any differences exist in the device links table and we can go from there. Also did the failure follow the SwitchLinc or stay at the original location?It followed the SwitchLinc. Also what is the firmware level of the SwitchLinc? V.35 firmware ia famous for Scene communication problems.v.36
LeeG Posted July 22, 2011 Posted July 22, 2011 j0dan Okay, thanks. Just to be sure, location A with SwitchLinc A produces the symptoms described. Installing a new SwitchLinc B at location A, location A still has the problem. This suggests something in the way the SwitchLinc is being used. Perhaps the dynamic changing of the Scene characteristics (only a guess). Now, SwitchLinc A is installed in location B and there are still problems with SwitchLinc A at location B. Are the Scenes in SwitchLinc A at location B being dynamically changed while at location B? Lee
j0dan Posted July 23, 2011 Author Posted July 23, 2011 j0dan Okay, thanks. Just to be sure, location A with SwitchLinc A produces the symptoms described. Installing a new SwitchLinc B at location A, location A still has the problem. This suggests something in the way the SwitchLinc is being used. Perhaps the dynamic changing of the Scene characteristics (only a guess). Now, SwitchLinc A is installed in location B and there are still problems with SwitchLinc A at location B. Are the Scenes in SwitchLinc A at location B being dynamically changed while at location B? Lee Correct. Although SwitchLinc A was sent back to SmartHome as I thought it was faulty. SwitchLinc B was moved from location B to location A after confirming location was not the problem. I have some dynamically updating scenes. What kind of things could cause this? I also change the LED brightness based on other things in the house. Surprisingly, this always works.
LeeG Posted July 23, 2011 Posted July 23, 2011 j0dan Dynamically changing Scene characteristics involves changing link records in the SwitchLinc. No specific reason to think that is the cause. Just sounds like a link record issue and that function happens to make changes to link records. Should be able to tell something when a good base line link table can be compared to the link table when things stop working. The LED level is maintained in memory away from the link database itself. Would not expect that to be affected by or cause a link table problem. Thanks for all the information. I like to form a theory about a possible cause and then either prove it right or wrong and move on from there. All the symptoms suggest a link record problem even though I don't really know how or what is doing the damage. Once we know what is wrong then more theory about how. Thanks again. Lee
j0dan Posted July 24, 2011 Author Posted July 24, 2011 Glad to have someone to troubleshoot with. It happened again today. When trying to change it's options in a scene, I first get this error: Subscriber didn't reply to event: 1 [Net Module Rule: 3] ------------------------------------ TCP client connection timed out [Net Module Rule: 7] ^That was a single error dialog. Then any adjustments after that get this error: Error Request Failed After removing from scenes and re-adding, it all works as expected. So step one is disabling all automatic scene adjustments? I can successfully request a links table. See attachment:
LeeG Posted July 24, 2011 Posted July 24, 2011 j0dan The link database labeled Broken looks okay. Two Scenes have the responder On Level and Ramp Rate changed. Other than that the correct number of link records exist with the same Scene numbers as the right example. In fact the sequence of the Broken example is what I would expect to see when the device was added to the ISY and then the device added as a Responder to 4 Scenes. The right example looks like the device has had a Restore Device issued. The E2 01 18.D1.59 FF 1F 00 link record is first in the Broken example. It is the link record created when the device is added to the ISY and allows the ISY to be aware of a paddle press. It is expected to be the first link record. In the example on the right it is the 3rd link record which happens only when a Restore Device is executed (as far as I know). Removing a device from a Scene as a responder would affect link records 2,3,4,5 in the Broken image but would have not cause the E2 link record to be moved away from its link record 1 location. There is more going on here than can be explained with simple remove device from Scene and add it back to the Scene and Scene responder On Level and Ramp Rate adjustments. I do not have the Network Module. Those initial messages appear to be related to rules defined for the Network Module. What device is the Network Module controlling and what are those rules accomplishing. Lee
j0dan Posted July 25, 2011 Author Posted July 25, 2011 The right example looks like the device has had a Restore Device issued.Interesting. I never ran the restore device command. Not in the past few weeks anyway. I just deleted it from scenes one by one and re-added. The E2 01 18.D1.59 FF 1F 00 link record is first in the Broken example. It is the link record created when the device is added to the ISY and allows the ISY to be aware of a paddle press.That is one of the issues I've been having too. The ISY does not see paddle presses when it is broken. I found out that I could get it working by making it a controller in a scene. I do not have the Network Module. Those initial messages appear to be related to rules defined for the Network Module. What device is the Network Module controlling and what are those rules accomplishing.No programs work with the network module and that switch. The network module can only send commands to the network when called from a program. There is no direct link to the Insteon side of things. I'm going to try disabling programs that change settings on the switch and see what happens.
LeeG Posted July 25, 2011 Posted July 25, 2011 j0dan With the Scene Responder link records (A2) appearing before the Controller link record (E2) something has rewritten the sequence of link records. The only thing I know of that does that is a Restore Device or Restore Modem (PLM). Since the link records that are labeled Broken are actually correct, albeit in a different order which has no affect on the operation of an individual link record, the next suspect is the Responder link record in the PLM for that SwitchLinc. There must be an A2 01 18.0F.08 xx xx xx in the PLM for the ISY to be aware of the SwitchLinc paddle press. Suggest doing a Show PLM Links Table and then click Count. The Show PLM Links Table/Count should be done 2-3 times to insure the count is reproducible. Inbound Insteon traffic to the PLM during the Show activity will adversely affect the number of link records displayed and subsequently counted. With a display with a predictable count look for the link record shown above. When the SwitchLinc stops reporting a paddle press do a Show PLM Links Table/Count and look for the A2 Responder link record for the SwitchLinc. Lee
j0dan Posted July 25, 2011 Author Posted July 25, 2011 There must be an A2 01 18.0F.08 xx xx xx in the PLM for the ISY to be aware of the SwitchLinc paddle press. Neat! It's there now. I'll check next time it breaks. Thanks.
j0dan Posted August 1, 2011 Author Posted August 1, 2011 Well the problem has gotten stranger. The switch now responds to a few scenes in the house that it is not a part of. Nothing shows up in the event log and it doesn't report that it changed to the ISY. I tried running restore devices on my entire network and factory reset the switch. Any other ideas?
LeeG Posted August 1, 2011 Posted August 1, 2011 The SwitchLinc is responding to button/paddle presses in other controllers that do not have this SwitchLinc as a Responder? If this is the case and there are not A2 link records in this SwitchLinc with the other controllers Insteon address the SwitchLinc is defective. Insteon architecture does not permit a device to respond to any Group (Scene) communication without the appropriate link record. Is there any chance the SwitchLinc is responding to Direct commands from an ISY Program that is triggered from the other controller button/paddle press?
j0dan Posted August 1, 2011 Author Posted August 1, 2011 I'm seeing these problems when I activate a scene right from the ISY console. The only change I made was making it a controller in one scene. This somehow increased the amount of links in the switch from 6 to 29. It has E2 records for devices that are in the scenes that somehow control this light. I don't see any reason in the ISY for these links to be there, but the ISY links table shows them all too. No related programs are running, but just in-case I disabled all programs that control the light. How often do SwitchLinc's go bad?
LeeG Posted August 1, 2011 Posted August 1, 2011 When a device is added as a Controller it is assumed to also be a Responder (if it has responder capability) and was cross linked with every other Controller in the Scene including the ISY PLM which is why it is now turning On.
j0dan Posted August 1, 2011 Author Posted August 1, 2011 It's a controller in a scene with one other device. None of the devices in it's scene are related to the scene or devices that keep affecting it. What would cause the E2 links (I'm assuming these are scene links of some sort) to unrelated devices?
LeeG Posted August 1, 2011 Posted August 1, 2011 After doing a Show Device Links Table, click on Compare. The results will indicate if the ISY beleives they should be there. Can you post the Show Device results?
j0dan Posted August 2, 2011 Author Posted August 2, 2011 Screenshot is attached. Also shows all the scenes that the device is in. After running restore devices on my network last night I started having the first problem with a KeypadLinc too. Similar errors when adjusting scenes from the ISY console. Links also match what the ISY think they should be. The wife no longer likes this system.
LeeG Posted August 2, 2011 Posted August 2, 2011 Is MBedroom Light 18.0F.08 a SwitchLinc or a KeypadLinc? The link records make it look like a KeypadLinc.
j0dan Posted August 2, 2011 Author Posted August 2, 2011 Is MBedroom Light 18.0F.08 a SwitchLinc or a KeypadLinc? The link records make it look like a KeypadLinc. That's the SwitchLinc.
LeeG Posted August 2, 2011 Posted August 2, 2011 Those are definitely KeypadLinc link records. A SwitchLinc uses a single Group number (01) in the second byte of E2 link records. A KeypadLinc uses up to 8 Group numbers (01-08) for an 8 button KPL. Many of the link records displayed have Group numbers in the 02-08 range. Physically impossible for a SwitchLinc to use. Same thing with the A2 link records except it is the last byte which identifies the "Output Unit Number". For a SwitchLinc it is always 00. The A2 link records that have values 01-08 represent KeypadLinc Group numbers acting as Responders. Again, physically impossible for a SwitchLinc to use. Recommend taking a backup of the system as it is now in case UDI needs it to determine why KPL link records have been associated with a SwitchLinc. Then restore a backup that does not have this bad link record association. An alternative would be to delete the SwitchLinc and add it back from scratch. The concern is something has happened to the configuration information and simply fixing this SwitchLinc may not resolve the underlying problem. Under the Admin Console when the SwitchLinc node is selected does the pane on the right show the device type as a SwitchLinc or a KeypadLinc?
j0dan Posted August 2, 2011 Author Posted August 2, 2011 Crazy. And it's a KeypadLinc that has now inherited the same problem. The MBedroom Light that we've been looking at says (2476D) SwitchLinc Dimmer W/Beeper v.38
j0dan Posted August 2, 2011 Author Posted August 2, 2011 Here is my KeypadLinc that stopped working at the same time. I'm so thankful you can understand all this. I was going crazy as I couldn't see anything wrong.
LeeG Posted August 2, 2011 Posted August 2, 2011 The last Show Device Links Table that came from a KeypadLinc looks like something that would come from a SwitchLinc. The Show Device has no E2 links for anything beyond the load control button. Also the Output Unit Number in the A2 entries is invalid for a KeypadLinc. Almost looks like the link record information for the SwitchLinc and KeypadLinc have been swapped.
j0dan Posted August 6, 2011 Author Posted August 6, 2011 Well I fixed the weird links by removing both devices and re-adding them. A lot of work! Now both devices are having the same problem where it doesn't stay in scenes correctly. This is driving me crazy and it looks like an ISY bug. The device links all look correct, but the ISY link table is blank for those two devices. What could cause this? Whose the best person to talk to at ISY to get this figured out?
Recommended Posts