Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Insteon component stopped working with introduction of home assistant 0.77 #16342

Closed
brucek1642 opened this issue Sep 1, 2018 · 34 comments · Fixed by #16472
Closed

Insteon component stopped working with introduction of home assistant 0.77 #16342

brucek1642 opened this issue Sep 1, 2018 · 34 comments · Fixed by #16472

Comments

@brucek1642
Copy link

Home Assistant release with the issue:

hassio -- version 1.3.1

Last working Home Assistant release (if known):
0.76.2

Operating environment (Hass.io/Docker/Windows/etc.):

Hass.io

My Insteon device is a pre-2014 Hub

Component/platform:

https://www.home-assistant.io/components/insteon/

Description of problem:
The code does not find any of the insteon devices. Prior to this version I was using curl commands to access x-10 devices and that code still works under home assistant 0.77

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

    
# Insteon entry in configuration.yaml
insteon:
  host: 172.16.0.135
  ip_port: 25105
  username: !secret insteon_user
  password: !secret insteon_pass

Traceback (if applicable):

2018-08-30 22:10:15 INFO (MainThread) [homeassistant.setup] Setting up insteon
2018-08-30 22:10:15 INFO (MainThread) [homeassistant.components.insteon] Connecting to Insteon Hub on 172.16.0.135
2018-08-30 22:10:15 INFO (MainThread) [insteonplm] Connecting to Insteon Hub on 172.16.0.135
2018-08-30 22:10:15 INFO (MainThread) [homeassistant.setup] Setup of domain insteon took 0.6 seconds.
2018-08-30 22:10:16 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=insteon>
2018-08-30 22:10:16 INFO (MainThread) [insteonplm] Insteon Hub reader started
2018-08-30 22:10:16 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=insteon, service=add_all_link>
2018-08-30 22:10:16 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=insteon, service=delete_all_link>
2018-08-30 22:10:16 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=insteon, service=load_all_link_database>
2018-08-30 22:10:16 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=insteon, service=print_all_link_database>
2018-08-30 22:10:16 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=insteon, service=print_im_all_link_database>
2018-08-30 22:10:16 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=insteon, service=x10_all_units_off>
2018-08-30 22:10:16 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=insteon, service=x10_all_lights_off>
2018-08-30 22:10:16 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=insteon, service=x10_all_lights_on>
2018-08-30 22:10:16 INFO (MainThread) [insteonplm.plm] Connection established to Hub
2018-08-30 22:10:16 INFO (MainThread) [insteonplm.plm] Requesting Insteon Modem Info
2018-08-30 22:10:16 INFO (MainThread) [insteonplm.plm] Requesting ALL-Link Records
2018-08-30 22:10:16 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback None
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 64, in uvloop.loop.Handle._run
TypeError: 'NoneType' object is not callable

Additional information:

@k7hpn
Copy link

k7hpn commented Sep 1, 2018

I am also seeing the "File 'uvloop/cbhandles.pyx', line 64, in uvloop.loop.Handle._run" error using the Insteon component with an Insteon Hub (Hub2-V04-20140904).

@teharris1
Copy link
Contributor

The error mentioned above does appear to be connected to the new Hub code for Insteon, however; it does not appear to be the reason why devices would not show up. I receive the same error but my system works as expected. My Hub is a Hub2-V04-20140904 as well.

Can you place the following code in your configuration.yaml:

logger:
  default: warn
  logs:
    insteonplm: debug
    homeassistant.components.insteon: debug
    homeassistant.components.light.insteon: debug
    homeassistant.components.switch.insteon: debug
    homeassistant.components.binary_sensor.insteon: debug
    homeassistant.components.sensor.insteon: debug
    homeassistant.components.fan.insteon: debug

The inital startup process may take up to 10 minutes to find all of the devices. Auto discovery for this component first loads the modem's (Hub or PLM) All-Link database then it queries the device for the device information. This can take a while.

@teharris1
Copy link
Contributor

For reference, I have 28 devices connected to my Hub. It takes almost exactly 1 min to read the ALDB then another 2 minutes to get the device info for each device. At that point, HA sees all of the devices.

Subsequent startups see the devices right away because it uses cached device info.

@k7hpn
Copy link

k7hpn commented Sep 2, 2018

  1. Connects to the hub to request info
  2. Home Assistant callback error posted above
  3. Receives message with the Insteon ID (xx.xx.xx) of my hub.
  4. [homeassistant.setup] Setup of config is taking over 10 seconds.
  5. [homeassistant.core] Timer got out of sync. Resetting

That last message came in over ten minutes ago, nothing since. Not sure if I should see more Insteon messages as it discovers or if that last HA log message means something else is hosed and it's not going to log further.

Is there anything I should clear from the log (other than IP address) before posting?

Edit: this is using hass.io on a Raspberry Pi 3B+ if that matters.

@teharris1
Copy link
Contributor

If you want to be ultra secure, replace the Insteon address of the hub or any other device. Just FYI, how many devices do you have and what are they?

@k7hpn
Copy link

k7hpn commented Sep 2, 2018

I'm seeing some device discovery now but I seem to be unable to do anything with it. Am I correct in guessing that if I:

  • Click the left-most icon in the Home Assistant developer tools
  • Choose service light.turn_on and put in light.xxxxxx with the Insteon id
  • Click the button

...that it should turn the light on?

Log should be attached.

I have four dimmer wall switch devices and a few mini remote control keypads, though I'm just trying to get the wall switches to toggle/read.

@teharris1
Copy link
Contributor

This is the section of the log that concerns me:

2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm.plm] TX: {'code': 0x69, 'acknak': 0xNone}
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm] ..................Writing a message..............
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm.plm] Waiting for ACK or NAK message
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm] Writing message: http://x.x.x.x:25105/3?0269=I=3
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm] Post status: 200
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm] Buffer from 0 to 6
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm] New buffer: 026915
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm.plm] Received 3 bytes from PLM: b'026915'
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'026915'
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm.plm] Buffer too short to have a message
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 1
2018-09-02 11:48:53 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x69, 'acknak': 0x15}

The first line is a request for the All-Link database. The last line says you have reached the end of the All-Link database. So no links were loaded. Are you sure you have linked your devices to the Hub?

The wall switches should work easy if they are linked correctly. The mini-remote, because it is battery powered, may require a device override. But let's get the wall switches first.

I would suggest you relink the devices. It won't hurt anything and will likely get them to show up right away. To do this in HA:

  1. Go to Developer Tools -> Services
  2. Select service insteon.add_all_link.
  3. In the Service Data box enter the following : {"mode": "controller", "group": 0}.
  4. Press the CALL SERVICE button
  5. Press the Set button on the device.

This has just set the Hub as a controller of the device. Now we need to set the Hub to be a responder to the device.

  1. Go to Developer Tools -> Services
  2. Select service insteon.add_all_link.
  3. In the Service Data box enter the following : {"mode": "responder", "group": 1}.
  4. Press the Set button on the device.
  5. Press the CALL SERVICE button

Note the change of the group from 0 to 1 and the order of the pressing of the set button and the call service button.

@k7hpn
Copy link

k7hpn commented Sep 2, 2018

That seems to have done the trick for me! My Insteon Hub was an RMA for a broken one so I wonder if somehow the replacement one never got properly linked (though the iOS app worked?).

In any event, that's great, thank you so much! If you can point me at insight about linking the remotes that'd be good but this was my main concern.

@teharris1
Copy link
Contributor

For the remotes repeat the two steps above for linking as a controller first then a responder but when linking as a responder do this for each button (i.e if you have an 8 button remote, link to groups 1 through 8).

The remote does not show up in HA as an entity. The way it is designed to work is a trigger of automations. Have a look here and let me know if you have questions:
https://www.home-assistant.io/components/insteon/#events-and-mini-remotes

@teharris1
Copy link
Contributor

teharris1 commented Sep 2, 2018

Also, if for some reason this does not work, you may still need to add the device to the configuration.yaml file with the following:

insteon:
  host: xxx.xxx.xxx.xxx
  username: someusername
  password: somepassword
  device_override:
    - address: 112233
      cat: 0x00
      subcat: 0xXX (see below for a description)
    - address: 445566
      cat: 0x00
      subcat: 0xXX (see below for a description)

All mini-remotes have a category (cat) of 0x00. The subcat is what tells you which one it is. Here is the list:

Cat Subcat Model Description
0x00 0x10 2444A2WH4 Mini Remote - 4 Scene
0x00 0x11 2444A3 Mini Remote - Switch
0x00 0x12 2444A2WH8 Mini Remote - 8 Scene
0x00 0x14 2342-432 Mini Remote - 4 Scene
0x00 0x15 2342-442 Mini Remote - Switch
0x00 0x16 2342-422 Mini Remote - 8 Scene
0x00 0x17 2342-532 Mini Remote - 4 Scene
0x00 0x18 2342-522 Mini Remote - 8 Scene
0x00 0x19 2342-542 Mini Remote - Switch
0x00 0x1A 2342-222 Mini Remote - 4 Scene
0x00 0x1B 2342-232 Mini Remote - 8 Scene
0x00 0x1C 2342-242 Mini Remote - Switch

@teharris1
Copy link
Contributor

@brucek1642 Happy to see if this linking solution helps you too. If not let me know.

@brucek1642
Copy link
Author

I've done some more digging and it looks like my issue is that I have the pre-2014 hub. It is expecting the traffic to come over tcp to port 9761. And there is no username or password. It works fine with insteon-terminal setup this way. ie It accesses the raw plm port 9761 to do its job. I had a quick look through your code and it looks like it does not offer this third type of connection.

I attached a copy of my init.py from insteon-terminal (renamed to a text file)

init.py.txt

Thanks

@teharris1
Copy link
Contributor

Yup. I see what you mean. I will get a fix ready. How literate are you at downloading repos and installing them. This is not that hard of a fix I think and it just requires that the username and password be optional. If I can post a fix would you be able to install and test?

@teharris1
Copy link
Contributor

teharris1 commented Sep 3, 2018

BTW, did this work with the insteon_local component?

@brucek1642
Copy link
Author

I can't say that I have ever downloaded a repo outside of the ones that automatically come with home assistant, but I am sure I can work through it. I would be more that happy to install and test the code.

Yes this did work with insteon_local component but .... it was not very reliable. It polled the hub every 30 seconds or so and if there was too much traffic it confused the hub. Then a power cycle was required for the hub to bring it back to life. I was using curl commands to use the x-10 feature via port 25105. There were two strings sent to the X-10. The first was to select the x-10 device, a pause then the second string to tell it to turn on or off. Too many of these and it overflowed the buffer ( i assume )

From what have been able to try out port 25105 works but is not very reliable due to the polling aspect. Using port 9761 is preferred since uses direct access to the internal plm

@teharris1
Copy link
Contributor

Since you are using hass.io I am not sure it is possible to load from a custom repo. We can try though.

Working on the fix now. Should be done today. But I cannot test so it is a bit of a shot in the dark.

One thing you could do for me is confirm the size of the buffer. Can you send the output of the following command inside a browser:
http://<your ip address>:9761/buffstatus.xml

@teharris1
Copy link
Contributor

Looking at this further, insteon_local was using the http requests via port 25105. Port 9761 is a socket based interface. I will not be able to get that working today but should be able to get the http requests working. This will not be meaningfully better than insteon_local except that the buffer management of insteon is (I believe) better than it was in insteon_local. So you will see some improvement. I still need you to confirm the buffer size but the actual command I need the output of is:
http://<your ip address>:25105/buffstatus.xml

@brucek1642
Copy link
Author

Hmm didn't work, so I went looking and ended up find this link ( which had some useful links at the bottom)

https://openremote.github.io/archive-dotorg/forums/attachments/22882151/23036475.pdf
which led to
https://blog.automategreen.com/post/under-the-insteon-hub-hood/

172.16.0.135:25105/buffstatus.xml did work and got back

  | 02622E64860F19000602502E64862CB16D2F0000000000000000000000000000000000000000000000000000000000000000

I also found the attached developers guide who's file name matches my insteon hub model 2242-222 which maybe helpful is says the

The INSTEON buffer can be read from “/buffstatus.xml” and can hold up to 100 characters or 50
hex bytes.

2242-222dev-062013-en.pdf

@teharris1
Copy link
Contributor

That's what I was afraid of. The reason you were seeing poor performance from insteon_local with buffer overflows is that the hub1 and the hub2 have different buffer handling. Hub2 holds 202 chars or 101 bytes. The last byte is the last buffer write position which allows you to know when a buffer overflow happens.

This is more than a quick fix. I need to make changes to the underlying library and without the device that will be tough. But I did figure out how to get the code to you for testing. I just have to package it up as a custom component.

@teharris1
Copy link
Contributor

Here is a first attempt at a fix. Drop this into your config directory and set the configuration.yaml as follows:

insteon_custom:
  host: <your ip address>

custom_components.zip

@brucek1642
Copy link
Author

brucek1642 commented Sep 4, 2018 via email

@brucek1642
Copy link
Author

brucek1642 commented Sep 4, 2018 via email

@teharris1
Copy link
Contributor

OK, I gave you a file that is for a newer version than what you have. Sorry. That one is for 0.78 not 0.77. Let me fix that quickly. Also, please use the following in your configuration.yaml:

insteon_custom:
  host: 192.168.1.136
  ip_port: 9761
  hub_version: 1

logger:
  default: warn
  logs:
    insteonplm: debug
    custom_components.insteon_custom: debug

custom_components.zip

@brucek1642
Copy link
Author

brucek1642 commented Sep 5, 2018 via email

@teharris1
Copy link
Contributor

This is actually encouraging. This message:
2018-09-04 20:17:55 DEBUG (MainThread) [insteonplm.devices] ID ACK: {'code': 0x62, 'address': 00.00.00, 'flags': 0x00, 'cmd1': 0x10, 'cmd2': 0x00, 'acknak': 0x06}
is a response from the Hubthat it acknowedged the message. Close. I will have another file to try in a few minutes.

@teharris1
Copy link
Contributor

Updated file. Feel pretty good about this one based on debugging.
custom_components.zip

@brucek1642
Copy link
Author

brucek1642 commented Sep 5, 2018 via email

@ghost
Copy link

ghost commented Sep 5, 2018

Thanks for the patients. Can you try this one?
custom_components.zip

@brucek1642
Copy link
Author

brucek1642 commented Sep 5, 2018 via email

@teharris1
Copy link
Contributor

Another update.
custom_components.zip

@brucek1642
Copy link
Author

brucek1642 commented Sep 5, 2018 via email

@teharris1
Copy link
Contributor

Excellent! use that temp fix until I can get something in production. Leave this issue open until then.

@MartinHjelmare
Copy link
Member

Please don't post endless unformatted log messages. Use triple backtics to format into code block and hide long logs with details tag:

https://gist.github.com/ericclemmons/b146fe5da72ca1f706b2ef72a20ac39d

@ghost ghost added the in progress label Sep 7, 2018
@ghost ghost removed the in progress label Sep 10, 2018
@brucek1642
Copy link
Author

I installed ha 0.78 last night and everything is looking good. Two positive side effects. It is much faster, ie the google assistant responses comes before the turn on / off action like it should. Secondly the the turn on of a dimmer at the wall switch properly updates HA. Before only turn off was updating.

If you ever need a tester for older model of Insteon hub, feel free to drop me a note. Thanks

@home-assistant home-assistant locked and limited conversation to collaborators Feb 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants