Insteon FanLinc and Hub 2422-222

ltoolio · January 27, 2019, 4:26am

I have one lingering aspect of Home Automation that I really want to close out…getting the FanLinc that’s in my daughters’ room to work properly in HA.

I’m currently running Hassio 0.86.2 on a Raspberry Pi, and my Insteon Hub is a 2422-222 (Rev 2.3).

I’ve added the Insteon Component per the documentation here, with my config below:

insteon:
  host: 192.168.86.15
  hub_version: 1

Upon rebooting Hassio, I don’t get any Insteon Components showing up in the UI, but I do get the following error messages within the HA Log:

2019-01-26 20:31:33 WARNING (MainThread) [insteonplm.devices] Device 1D.04.2B did not respond to an ID request
2019-01-26 20:31:33 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:31:38 WARNING (MainThread) [insteonplm.devices] Device 1D.03.F8 did not respond to an ID request
2019-01-26 20:31:38 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:32:58 WARNING (MainThread) [insteonplm.devices] Device 1E.4B.4E did not respond to an ID request
2019-01-26 20:32:58 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:01 WARNING (MainThread) [insteonplm.devices] Device 31.FF.E4 did not respond to an ID request
2019-01-26 20:33:01 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:03 WARNING (MainThread) [insteonplm.devices] Device 1D.E7.E9 did not respond to an ID request
2019-01-26 20:33:03 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:06 WARNING (MainThread) [insteonplm.devices] Device 1F.20.5C did not respond to an ID request
2019-01-26 20:33:06 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:14 WARNING (MainThread) [insteonplm.devices] Device 1D.04.20 did not respond to an ID request
2019-01-26 20:33:14 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:16 WARNING (MainThread) [insteonplm.devices] Device 1A.F0.09 did not respond to an ID request
2019-01-26 20:33:16 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:19 WARNING (MainThread) [insteonplm.devices] Device 31.FF.DB did not respond to an ID request
2019-01-26 20:33:19 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:21 WARNING (MainThread) [insteonplm.devices] Device 1F.4C.6E did not respond to an ID request
2019-01-26 20:33:21 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:24 WARNING (MainThread) [insteonplm.devices] Device 33.1B.2F did not respond to an ID request
2019-01-26 20:33:24 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:26 WARNING (MainThread) [insteonplm.devices] Device 1D.F4.D9 did not respond to an ID request
2019-01-26 20:33:26 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:29 WARNING (MainThread) [insteonplm.devices] Device 1D.EA.CE did not respond to an ID request
2019-01-26 20:33:29 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:32 WARNING (MainThread) [insteonplm.devices] Device 1D.E9.05 did not respond to an ID request
2019-01-26 20:33:32 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:34 WARNING (MainThread) [insteonplm.devices] Device 21.DA.B5 did not respond to an ID request
2019-01-26 20:33:34 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:37 WARNING (MainThread) [insteonplm.devices] Device 21.DB.21 did not respond to an ID request
2019-01-26 20:33:37 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:40 WARNING (MainThread) [insteonplm.devices] Device 14.F5.6C did not respond to an ID request
2019-01-26 20:33:40 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type
2019-01-26 20:33:42 WARNING (MainThread) [insteonplm.devices] Device 20.BB.A2 did not respond to an ID request
2019-01-26 20:33:42 WARNING (MainThread) [insteonplm.devices] Use a device override to define the device type

I’ve googled around but have not been able to figure out how to override the various components to get it working. Anyone have similar issues and have been successful in getting it working?

Thanks much!

teharris1 · February 1, 2019, 4:44pm

Sorry for the delay here. I see the following devices:
33.1B.2F
31.FF.E4
31.FF.DB
21.DB.21
21.DA.B5
20.BB.A2
1F.4C.6E
1F.20.5C
1E.4B.4E
1D.F4.D9
1D.EA.CE
1D.E9.05
1D.E7.E9
1D.04.2B
1D.04.20
1D.03.F8
1A.F0.09
14.F5.6C
None of them are responding to a device ID request. This is likely a communication problem. Are you using a Hub or a PLM? Do you know the device category and subcategory for each of these devices? To use device overrides make your config look like this:


insteon:
  port: /dev/insteon  # or Hub config as appropriate
 device_override:
    - address: 14dda8
      cat: 0x10
      subcat: 0x01
      firmware: 0x41
    - address: 44899f
      cat: 0x00
      subcat: 0x1b
    - address: 449b4e
      cat: 0x00
      subcat: 0x1c
    - address: 34ef51
      cat: 0x01
      subcat: 0x21

However, if the devices are not responding to an ID request it is either because they are battery operated or they are not communicating consistently with the Insteon Modem (PLM or Hub).

ltoolio · February 1, 2019, 5:18pm

Hello teharris1 -
Thanks for the reply!

I have made some progress since my original post, but it’s kinda a step forward then a step back.

I’m using a Hub, model 2242-222.

Here’s where I am now:

All of the orphaned IDs that you referenced are insteon devices I’ve since removed from the house, so all good there. I’m just ignoring them.
I was able to do an override of my 8-button Keypad with the following code:

insteon:
host: 192.168.86.15
hub_version: 1
device_override:
- address: 1D.F4.D9
cat: 0x01
subcat: 0x1C

And upon doing so, I get the following elements showing up in the UI:
good%20scr

The first entry - the KeypadLinc Main - does not respond to anything. I turn it on from the UI and it immediately turns off.

But…nothing happens to the lights/fan when I turn the buttons on or off. The LEDs on the keypad will illuminate or turn off, but nothing actually happens with the lights/fan themselves.

I just got back in town from some business travel, and haven’t had a chance yet to troubleshoot further.

Anything jump out at you based upon what I’ve shared back?

teharris1 · February 1, 2019, 10:21pm

Can you put the following in your configuration.yaml file:

logger:
  default: warn
  logs:
    insteonplm: debug
    homeassistant.components.insteon: info

Try all of the buttons and send me the log.

ltoolio · February 1, 2019, 11:55pm

I’m not sure the best way to send it to you, so I’ve added it to my GDrive and shared it via the link here:

Let me know if you need anything else, and thanks for the help!

teharris1 · February 2, 2019, 2:25am

It appears you have a USB port issue communicating to the Hub. I have seen this before on a RPi but I don’t know what the solution is. The indication of this is the following lines in the log:

2019-02-01 17:47:33 DEBUG (MainThread) [insteonplm.plm] Queueing msg: {'code': 0x62, 'address': 1D.F4.D9, 'flags': 0x10, 'cmd1': 0x2e, 'cmd2': 0x00, 'userdata': 0x01.09.02.00.00.00.00.00.00.00.00.00.00.c6, 'acknak': 0xNone}
2019-02-01 17:47:33 DEBUG (MainThread) [insteonplm.devices] Ending 1D.F4.D9 Device._process_send_queue
2019-02-01 17:47:33 DEBUG (MainThread) [insteonplm.plm] TX: {'code': 0x62, 'address': 1D.F4.D9, 'flags': 0x10, 'cmd1': 0x2e, 'cmd2': 0x00, 'userdata': 0x01.09.02.00.00.00.00.00.00.00.00.00.00.c6, 'acknak': 0xNone}
2019-02-01 17:47:33 DEBUG (MainThread) [insteonplm.plm] Waiting for ACK or NAK message
2019-02-01 17:47:34 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2019-02-01 17:47:34 DEBUG (MainThread) [insteonplm.plm] Received 22 bytes from PLM: b'0262f4d9102e0001090200000000000000000000c606'

The first line shows that what was sent to the modem and the last line shows what was actually acknowledged by the modem:
sent: 02621df4d9102e0001090200000000000000000000c6
recd: 0262f4d9102e0001090200000000000000000000c6

Notice the 3rd byte (0x1d) was dropped. This means you have a garbled message on the wire. I would try to rebuild your RPi but I don’t really know much about them.

Unfortunately this does not appear to be the only issue. The KeyPadLinc with ID 1D.F4.D9 is not responding to messages that are send correctly. Here is what I am seeing in the log:


2019-02-01 17:47:28 DEBUG (MainThread) [insteonplm.devices] Starting Device._send_msg
2019-02-01 17:47:28 DEBUG (MainThread) [insteonplm.devices] Ending Device._send_msg
2019-02-01 17:47:28 DEBUG (MainThread) [insteonplm.devices] Starting 1D.F4.D9 Device._process_send_queue
2019-02-01 17:47:28 DEBUG (MainThread) [insteonplm.devices] Lock is locked from yield from
2019-02-01 17:47:28 DEBUG (MainThread) [insteonplm.plm] Queueing msg: {'code': 0x62, 'address': 1D.F4.D9, 'flags': 0x00, 'cmd1': 0x11, 'cmd2': 0xff, 'acknak': 0xNone}
2019-02-01 17:47:28 DEBUG (MainThread) [insteonplm.devices] Ending 1D.F4.D9 Device._process_send_queue
2019-02-01 17:47:28 DEBUG (MainThread) [insteonplm.plm] TX: {'code': 0x62, 'address': 1D.F4.D9, 'flags': 0x00, 'cmd1': 0x11, 'cmd2': 0xff, 'acknak': 0xNone}
2019-02-01 17:47:28 DEBUG (MainThread) [insteonplm.plm] Waiting for ACK or NAK message
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.plm] Received 9 bytes from PLM: b'02621df4d90011ff06'
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'02621df4d90011ff06'
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.plm] Buffer too short to have a message
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 1
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x62, 'address': 1D.F4.D9, 'flags': 0x00, 'cmd1': 0x11, 'cmd2': 0xff, 'acknak': 0x06}
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.devices] Starting Device.receive_message
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.devices] Got Message ACK
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.devices] Look for direct ACK
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.devices] Ending Device.receive_message
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.plm] Last item in self._recv_queue reached.
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.plm] ACK or NAK received
2019-02-01 17:47:29 DEBUG (MainThread) [insteonplm.devices] Starting Device._wait_for_direct_ACK
2019-02-01 17:47:32 DEBUG (MainThread) [insteonplm.devices] No direct ACK messages received.
2019-02-01 17:47:32 DEBUG (MainThread) [insteonplm.devices] Releasing lock after processing direct ACK
2019-02-01 17:47:32 DEBUG (MainThread) [insteonplm.devices] Device 1D.F4.D9 msg_lock unlocked

at 2019-02-01 17:47:28 a command 0x11 was sent to turn on the device to full on (0xff). The modem did receive this message correctly and so the correct message was put onto the wire. However the KPL did not respond to the command (see the message at 2019-02-01 17:47:32 No direct ACK messages received). This can have a lot of reasons but it can be due to the message not transmitting correctly or device links not being setup correctly. Also, KPLs can be flakey devices and if you have done a lot of linking and unlinking of devices to the KPL their database can become unmanageable and slow. The result it they don’t respond to valid commands.

Sorry for the bad news. Try the following:

rebuild the RPi
Try again if it fails:
Reset the KPL to factory defaults and relink to the modem and any devices.

Not great news but it is the best I have.

Heatvent · January 28, 2022, 5:43pm

Hi, I am new to HA, moving from HomeSeer. The integration seemingly pulled in my devices and is responding. I have fanlinc’s in a few rooms with keypadlincs controlling them. The fanlinc seems to just come in as light and fan. There should probably be separate entities for high, medium, low and off for the fan but I don’t see these. Wondering how this might be done in the HA integration or through some level of customization if needed.

Below is what I see in the insteon_devices.json file for one of the fanlincs:

“7751”: {
“memory”: 7751,
“in_use”: true,
“controller”: true,
“high_water_mark”: false,
“bit5”: true,
“bit4”: false,
“group”: 0,
“target”: “477ed7”,
“data1”: 1,
“data2”: 46,
“data3”: 69

For the keypadlinc’s I see multiple entries which I assume are for each of the 8 buttons. I guess I would expect to see this for the fanlinc as well perhaps.

Thanks!

teharris1 · February 9, 2022, 4:36pm

There are two entities for a FanLinc. One is a light which is dimmable and the other is the fan which has default speed settings for High, Medium, Low and Off.

Heatvent · February 9, 2022, 6:42pm

Thanks for the reply. I see now that the fan works in 33.33% increments for the various speeds. I just came from HomeSeer where each speed was given a different device that turns on/off so I guess I was expecting to see something similar. The HA implementation obviously makes more sense. Thanks for the follow-up!