Author Topic: 23.D0.80:FFF9,FF - Sender's device ID not in responder's database.  (Read 1297 times)

Offline rtranum

  • Newbie
  • *
  • Posts: 14
  • Karma: +0/-0
I have made a lot of progress working with altsteon from the command line interface.  I am trying to get everything working from the cli and then I will work on the UI from what I was told in previous posts.  I am trying to get the KeyPadLinc Dimmer Insteon Remote Control Switch Model 2486D 6 button device to control the Insteon FanLinc.  I can control the FanLinc from the alsteon_cli successfully.  I have gone through the "linking dance" with the KeyPadLinc and the PLM.  However, here is the response I get from the altsteon_cli:

23.D0.80:FFF9,FF - Sender's device ID not in responder's database.

Here is what I get on the alsteon_cli list command:

Cmd : list
23.D0.80:0046,00,FF,FF,00,23,D0,80 - 23.D0.80  (DevCat : 255  SubCat : 255  Hidden : 0  Addr : 23.D0.80)
23.3F.78:0046,01,01,2E,00,23,3F,78 - 23.3F.78  (DevCat : 1  SubCat : 46  Hidden : 0  Addr : 23.3F.78)
plm:0046,02,03,15,1,22,3D,CD - plm (DevCat : 3  S
ubCat : 21  Hidden : 1  Addr : 22.3D.CD)
end:004E,02 - End of list.

23.3F.78 is the fanlinc and 23.D0.80 is the keypadlinc

Any ideas?  Is there anyone out there who can help or any resource / contact I can work with.  I'll do all the legwork and have made tons of progress, but would love some expert feedback on a few items.  Once I get this working on the CLI and then conquer UI next, I think I am homefree and can help others :)

Offline fba

  • Moderator
  • Sr. Member
  • *****
  • Posts: 292
  • Karma: +1/-0
  • If it ain't broke, I ain't touched it yet.
Re: 23.D0.80:FFF9,FF - Sender's device ID not in responder's database.
« Reply #1 on: May 26, 2013, 10:03:33 pm »
The first problem you are running in to is that the keypadlinc isn't being recognized by Altsteon as a valid device.   DevCats and SubCats start out with a value of -1 in an unsigned byte.  So, if you see DevCat : 255 and SubCat : 255 it means Altsteon doesn't know what the device is.   So, that is the first thing you should get figured out.   This can happen if the KPL is on a different phase than the PLM or if the commands are getting lost.

If you use the command "23.D0.80 ping" what does it return?   

Since you are getting an error back, it would stand to reason that the PLM can send messages to the KPL.   So, the likely problem is that the PLM is not in the KPL's link database.   To fix that, you should be able to do the "linking dance" between the KPL and the PLM.   You can also verify the link database by running "plm dump_aldb" or "23.D0.80 dump_aldb" and looking for the address of the opposite device.   If both devices don't have the other devices address, you will see errors like this.   In general, it is recommended that you link all devices in both directions if possible.   For example, you would start with the PLM and put it in to linking mode.  Then, go to the KPL and put it in to linking mode, which should cause a double beep meaning they are linked.   Then, put the KPL in linking mode, and go to the PLM and put it in linking mode, which should cause a double beep again.    If you are using the buttons on the devices to put them in linking mode, the first device you put in linking mode will be the controller, and the second the responder.   Linking both ways minimizes your chances of losing a message due to confusion by the device.   So, unless the device won't let you link both ways, or you know what you are doing, make sure you link both ways.

Vera 3, Altsteon, (Insteon: Relay (Smarthome & Icon), Dimmer (Smarthome), Keypadlinc, 2420M, Triggerlinc, IOLinc, Garage Hawk, Venstar Thermostat, Fanlinc, MI lock, Appliancelinc, Synchrolinc, iMeter), CurrentCost, (Z-Wave: Schlage lock, GE Appliance switch), AutHomation