| Author |
|
jmvanden
Newbie
Joined: February 16 2006
Online Status: Offline
Posts: 16
|
| Posted: April 14 2006 at 08:49 | IP Logged
|
|
|
I am coming across a situation where it appears that PH may be adding additional links in Insteon links reports. After having PH running for quite some time, I begin to see additional copies of devices (mostly on my KPLs and Controlincs) listed. The odd thing about these additional copies of the devices is that the controller and responder status show as NOT FOUND and the button that they claim to be linked to is usually -1, -2, -4, or -6.
Any thoughts on what could be causing this? I have cleared the PH groups a few times, rediscovered everything and then things look ok. Then several days later when I check on things, I see these bogus links. I am running PH V 1.03.4.7.
Thanks,
Jim
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: April 16 2006 at 22:47 | IP Logged
|
|
|
Jim,
I know I responded to you via email concerning installing the 1.03.4.7-4 patch as this is a known issue with the non-patched version.
Let me know if you're still having problems.
Dave.
|
| Back to Top |
|
| |
jmvanden
Newbie
Joined: February 16 2006
Online Status: Offline
Posts: 16
|
| Posted: April 29 2006 at 09:38 | IP Logged
|
|
|
Dave,
I wanted to make sure of this before I updated this post. I re-installed the 7-4 patch just to be sure and then let PH run for a few weeks. After a few weeks, I do still see a number of these rogue links showing up. Interestingly enough, it seems like it is one of the KPLs and one of the devices that keep replicating this link. Any thoughts? COuld it be the devices?
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: May 01 2006 at 23:37 | IP Logged
|
|
|
Jim,
I wouldnt think it would be the devices, but I wouldnt necessarily rule it out either.
The best way to proceed at this point would be to send me a copy of your database with the bad links. I may be able to spot a pattern in the raw link data that may shed some light on what is happening.
Also, let me know what version of the SDM you're using.
Dave.
|
| Back to Top |
|
| |
nadler
Super User
Joined: February 25 2006
Location: United States
Online Status: Offline
Posts: 354
|
| Posted: May 03 2006 at 06:57 | IP Logged
|
|
|
I continue to have the same issue as jmvanden. After running PH for a while some weird links start appearing again, also many with the KPL and controlinc and with NOT FOUND and the button that they claim to be linked to is usually -1, -2, -4, or -6.
But I have also found this doesn't seem to hurt anything so I am ignoring it.
Also when reviewing the report I see that I get about 3 to 4 "unmapped insteon in" command from various devices an hour. What would that be?
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: May 05 2006 at 00:17 | IP Logged
|
|
|
I would go ahead and email me your database as well. It will probably help me to pinpoint the issues.
Concerning the "unmapped insteon in"...this is mostly normal. It's possible that some incoming commands are just truly bad commands but most likely theyre legit commands that I didnt fully map in the last version. I'll work on trying to finish the mapping for the next version.
Dave.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: May 12 2006 at 16:25 | IP Logged
|
|
|
Jim,
Ive finished the analysis on your database and it's not as bad as I was expecting. Actually, most of the problems I understand and are not the result of the previous problem with the "reflected" peeks.
A majority of the problems are where you've got links between buttons on a KeypadLinc. This is a error that Im already aware of and have fixed in the next beta. You can see these problems where you've linked between buttons on a KPL and one of the links (usually the controller) will say NOT FOUND. This type of link since it's between buttons on the same device, creates two records in the KPL. One for the controller portion and one for the responder portion. The problem occurs because I would update the database after both links were created. Because of this, I would look for the first available record and create the first link. I would then search for the next available record and create the second link. Since I did not save after the first link, the second link was created on top of the first link and you get a NOT FOUND for one of the links.
Now the good news is, if you are creating a link between KPL buttons and the responder button is any button besides the main "load" button, then you shouldnt be creating a link at all. This type of configuration should be done in the KeypadLinc Configuration Utility. The very first link meeting this criteria is your FRONTROOMKEYPAD button 1 controlling FRONTROOMKEYPAD button 3. Since the responder button (3) is not the load button, you should just open the KPL Util and in the "Button 1" section, just put a check in the LED On checkbox of button 3. When button 1 is pressed ON, then button 3 will also turn on. When button 1 is pressed OFF, then button 3 will also turn off. You should just right-click these types of links and select "Delete from Devices".
For the links between KPL's where the responder is the "load" button (group 1), you still have to use the KPL Utility to make this link work, but you also need to create an actual link. You won't be able to fix this type of link though until the next beta  .
Another problem I see is with the first link on your FRONTROOMKEYPAD with button 3 as the controller. This link is showing NOT FOUND for the device ID (00.41.36). This looks like it may have been a legitimate communications error because it doesnt match the symptoms of the earlier problem that I was having. What it looks like it was trying to do is create a link for the UPPERHALLBYMBR (01.41.36) since this link also appears (last) in the list of links for button 3. To fix this problem, I would delete both links using "Delete From Devices" since the link actually exists incorrectly in both devices. Then recreate this link using the "Create/Edit/Clone" window.
Another problem appears to be a communication problem to LIVINGROOMLAMP2. You can see a number of links between it and FRONTROOMKEYPAD button 5. This is something I will need to look at in my code to see if I can prevent it from happening but it appears that everytime it tried to verify the link and couldnt, it would create a new phantom link (the button keeps incrementing with a negative number). The best way to fix this problem would be to delete all of the links from the FRONTROOMKEYPAD button 5 to LIVINGROOMLAMP2 using the "Delete from PH" option. Then recreate the link using "Create/Edit/Clone" and see if that takes care of it.
You've also got a lot of NOT FOUND links on your MASTERBEDCONTROLINC1. All of these NOT FOUNDS are on the controller side (the ControLinc). These links will still work because the responders all have the link verified so when the ControLinc sends a GROUP ON/OFF command, it sees that it's a member of the ControLinc group and then reacts. If the link is truly not in the ControLinc, then you wont get any of the GROUP CLEANUP messages that are sent. For these links, I would click "Reverify" and assuming your communications is OK going to the ControLinc (you can see in the SDM log) and the links still come back as NOT FOUND, then I would delete them using "Delete from Devices" and rebuild them using the "Create/Edit/Clone" window. The reason these links are showing as NOT FOUND could just be poor communications between the PLC and the ControLinc.
You've got 1 link that appears to be like the problem that PowerHome had earlier with reflected ACK's. That link is on KITCHENKEYPAD button 7 as the controller and GARAGEENTRYKEYPAD button 25 as the responder. It shows a status of "CHECKING" on the controller side. This link is garbage and should be deleted using the "Delete from PH" option.
Let me know how this goes for you.
Dave.
|
| Back to Top |
|
| |
cmhardwick
Senior Member
Joined: July 08 2006
Location: United States
Online Status: Offline
Posts: 290
|
| Posted: July 10 2006 at 17:10 | IP Logged
|
|
|
Question on Delete from PH and Delete from Device. When should you use which deletion? I've always done Delete from Device and fully recreated the links. What's an example of when to delete just from PH?
Thanks!
__________________
Cicero, Enjoying automation!
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 10 2006 at 22:45 | IP Logged
|
|
|
If the links are valid (VERIFIED) and the devices exist, then you would use "Delete from Devices" to remove the links from the Insteon devices. If the link is a bad link (doesnt really exist or the device is no longer on the network), then you would just use the "Delete from PH". This would just delete the link from the PowerHome database without actually trying to communicate with the Insteon devices to delete the links internally to the devices.
Dave.
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Bug Reports
Topic: NOT FOUND links for Insteon devices occur
