Insteon Losing Connection Regularly = "Can not connect to host"

I have, and have had Insteon integrated into Home Assistant for a while. Even before the shutdown.

The issue I am having is that Home Assistant just looses connection to the Insteon Hub.

In the logs I can see…

Logger: pyinsteon.protocol.http_reader_writer
Source: /usr/local/lib/python3.9/site-packages/pyinsteon/protocol/http_reader_writer.py:58
First occurred: June 23, 2022 at 9:14:58 PM (589 occurrences)  
Last logged: 3:01:16 PM
An client error occurred: Cannot connect to host 172.16.32.140:25105 ssl:default [Connect call failed ('172.16.32.140', 25105)]

I can ping the Hub fine, and the Insteon App works, so its online. Home Assistant just stops talking to it.

this is also in the logs

Logger: pyinsteon.protocol.http_transport
Source: /usr/local/lib/python3.9/site-packages/pyinsteon/protocol/http_transport.py:179  
First occurred: June 24, 2022 at 2:08:32 PM (8 occurrences)
Last logged: June 30, 2022 at 10:11:08 PM
Closing connection Hub after 30 retries

I have checked Docker, and there are no overlapping subnets.
Admin shutting down the switch port the that Hub is connected to, and bringing it back online will solve the issue for a bit, then errors again.

Similar Threads, no resolution

Thanks for your help, I’d like to find the solve for this.

This is an ongoing issue with the Insteon Hub that I have not been able to figure out for quite a while. Any help in debugging this issue would be very appreciated. The base issue is that the Hub only allows one connection simultaneously. For some reason, either HA or the Hub does not release a connection so the next connection attempt to read or write from the Hub fails. The only resolution appears to be restarting HA. There has to be a way to identify these stale connections and terminate them but it has not been obvious to me so far.

1 Like

I set a DHCP reservation for my hub with no default gateway. Home Assistant has been rock solid ever since.

I wonder if it has something to do with the way the new Insteon IOS app works? Its “faster” to load, because it never closes the connection? Or something?

If you want me to debug or get you any files or anything let me know, otherwise I am good for now.

Thanks. Good to know. I have suspected that the issue may have something to do with the connection back to Insteon but I am also pretty sure that is not the only issue. Anyway, thanks for the update that blocking access to Insteon’s servers solved the issue for you.

I’ve been having the same issue. Seems I have to reboot my insteon hub every few days now. I am a bit of a newbie to HA so my apologies for not being able to follow what you are saying you did to solve this. Did you do this on your router or insteon hub? Would love to get this issue fixed.

Update: I checked the Insteon app and under Settings, House, DHCP is set to ON.

Having same issue. Restarting Insteon hub several times per day. Tried blocking it’s Internet access but that did not help.
Allen

@teharris1, just piggybacking this thread because I have been facing the same problems with the hub disconnecting. I had been brainstorming a way to deal with my problem because inevitably, I realize that my hub stopped responding at bedtime when the lights should be turning off and I have to stomp downstairs to power cycle the hub and HA box.

But, my plan was to use a different smart outlet so that I could power cycle the insteon hub. Of course, I could set up a scheduled automation, but the problem is so random that it might happen well before my schedule and block other automations from running properly.

I have two ideas that when put together should enable a more automated recovery. I want to be able to monitor the state of the hub and trigger both a power cycle of the hub, but also an HA Insteon integration “restart”

  1. Since the logs are clearly identifying when the hub enters this “bad state”, I’d love to introduce some sensor that represents the hub/plm online/communicating/something-that-implies-operational state. Even better, instead of it simply saying up/down have it represent the retry count (or use two sensors).
  2. Ensure that there is an Insteon integration service that can “restart” the integration so that it properly resets itself after the hub cycles.

This way I could create an automation with a condition, such that when the retry count was > 10 times power cycle the smart outlet the hub is plugged in to, then wait 30 seconds, and reinitialiize the insteon integration.

This last idea might be a stretch, but given the new “Repair” system in HA, I wonder if some of this could be used to create a repair option for the Insteon integration?

@chuckdeal97 and @teharris1 - was going the exact same route of having a smart outlet to restart the hub, in fact, I had it restart overnight on a daily basis. But the issue of lost connectivity would still happen. I found a solution though! Has been working flawlessly for about two weeks now. So thought I would share for others to leverage.

The solution was to block internet access to the Insteon Hub. A DENY firewall rule at the router. Read that DENY is better than DROP, though my router only offers ACCEPT/DENY options anyways. It feels like the Hub gets stuck in some process trying to connect to Insteon servers, and I don’t have a subscription, and this is when HA loses connection.

Hope this helps others with similar issues.

1 Like

I’ve been experiencing the same issues. Seemingly randomly, my hub will stop working until it is power cycled. I tried blocking external internet access to the hub, as suggested here, and it seemed to help a little, but never really fixed the problem. I actually have a valid Insteon subscription, too.

We really need to get to the bottom of this problem - a flaky lighting control system is worse than no lighting control system at all. I’m getting close to factory resetting everything in my house (the hub plus about 30 devices) and re-configuring everything, but that’s a big project and no guarantee it will fix anything.

For the short term, I came up with a workaround using a spare Insteon plug-in on/off relay module, and a cheap $8USD Sonoff S31 switch (flashed with ESPHome firmware) to create an Insteon Watchdog.

I wrote a PyScript script which tries to change the state of the spare Insteon relay module. If it determines it was unable to change the state, it cycles the power on the Sonoff switch, which reboots the hub and sends a persistent notification, so I know a reboot has happened. I typically see 1-5 reboots per day.

The script is run once every 10 minutes from an automation.

PyScript code below. You’ll need to adapt it for your specific entity names. Hope it helps someone.

def check_insteon(watchdog_entity):
    off_trig = f"{watchdog_entity} == 'off'"
    on_trig = f"{watchdog_entity} == 'on'"
    
    cur = state.get(watchdog_entity)

    log.debug(f"cur = {cur}")

    success = None
    if cur == 'on':
        log.debug("Turning off")
        service.call("switch", "turn_off", entity_id=watchdog_entity)
        cur = state.get(watchdog_entity)

        log.debug(f"now = {cur}")
        log.debug("Waiting for off... " + off_trig)
        success = task.wait_until(state_trigger=[off_trig], timeout=10)
    elif cur == 'off':
        log.debug("Turning on")
        service.call("switch", "turn_on", entity_id=watchdog_entity)
        cur = state.get(watchdog_entity)

        log.debug(f"now = {cur}")
        log.debug("Waiting for on... " + on_trig)
        success = task.wait_until(state_trigger=[on_trig], timeout=10)
    else:
        log.debug(f"Unknown state")

    log.debug(f"success = {success['trigger_type']}")

    if success['trigger_type'] == 'state':
        log.debug("Insteon is alive.")
        return True
    else:
        log.debug("Insteon is not responding")
        return False
    
@service
def insteon_watchdog():
    checks = 3
        
    while checks > 0:
        id = task.create(check_insteon, 'switch.on_off_module_37_5c_60')
        done, pending = task.wait({id})        
        
        alive = id.result()
        
        if alive:
            return
    
        checks = checks - 1
        log.debug(f"Checks remaining {checks}...")
        
    log.debug("Insteon is not responding.  Resetting.")
    
    service.call("switch", "turn_off", entity_id="switch.insteon_hub_sonoff_s31_relay")
    task.sleep(3)
    service.call("switch", "turn_on", entity_id="switch.insteon_hub_sonoff_s31_relay")
    
    log.debug("Reset Insteon.")

    logbook.log(message="Watchdog reset Insteon Hub.", name="Insteon Watchdog")
    notify.persistent_notification(message="Watchdog reset Insteon Hub.")
    

The interesting thing about this problem is that the insteon hub / modem is up and running. I can ping it, I can use the insteon app and everything works just fine (outside of Home Assistant). The problem seems to lie with the communication between Home Assistant and Insteon. So, with that in mind, I proceeded on the assumption that there’s some sort of communications issue, like a stale network connection that hasn’t been closed properly - eg. HA is potentially trying to use a network connection that Insteon is no longer listening to. I’ve tried the following work-around, which works reliably for me. What I like about it, is that it doesn’t require restarting the insteon hub / modem or restarting home assistant.

Create an automation which simply makes an insteon call every 10 minutes. Think of this as a “keep-alive” or “ping” to keep the connection between HA and Insteon fresh and functional. The call I’ve chosen to use is to call the “insteon.scene_off” service, to a scene ID that doesn’t exist (that way, I don’t actually have lights / switches turning on and off with the automation), but you can use any insteon call you wish. The key is to have regular traffic flowing between HA and Insteon to keep the integration alive. Here’s the code for my automation. Change the service call or group number as desired to create your own ‘no-op’ call.

alias: Insteon Ping (Scene 213 off)
description: "Call Insteon.Scene_Off for an invalid scene (213) to keep the Insteon automation alive"
trigger:
  - platform: time_pattern
    minutes: /10
condition: []
action:
  - service: insteon.scene_off
    data:
      group: 213
mode: single
2 Likes

great write up, quick questions, if I copy and past directly into automation, will this work? or do I need to create something else? like the inteon.scene_off somewhere? I really like to get this from stop working.

There is some great stuff in this thread. Just FYI, I have reached out to the new owners of Insteon for some help on this. The core problem is that the Hub only allows one local connection at a time. (The insteon app comes in remotely over a separate connection and so it is not affected). In some networks that connection gets disrupted for a second or so and sometimes the Hub does not drop the connection. When this happens HA cannot reconnect. Restarting the Hub “fixes” the problem but I believe the core issue is in the Hub’s firmware.

Is anyone aware if there is a fix for this yet? I am about to try to switch to a USB PLM I have never used with my Raspberry Pi, but it’s going to be painful reconnecting everything to the PLM instead of the old hub. This is good information in this thread and it corresponds to what I have seen. During the times HA cannot do anything with Insteon, the hub does not respond to connections on the network (verified with netcat).

I hate putting in workarounds for stuff like this (like scheduling a tickler, rebooting the hub, etc.), and it’s about to drive me off the Insteon platform if I can’t resolve it since my family keeps getting frustrated with me when the automations don’t work properly. I used to use an ISY994i and the integration was flawless, but my serial PLM failed and I didn’t want to shell out the money for polisy not knowing if I was going to continue the investment with Insteon long term.

Hoping maybe Insteon can update these hubs to keep their service going. The only downside for me is I never subscribed to their latest service after the shutdown, so my hub just runs local. Hence, I wonder if a firmware upgrade, if one is ever available, will require a subscription.

(TLDR: If you’ve having this lost connection issue you can provide valuable troubleshooting information in this thread by going here, and then clicking the link to load your hub internal IP/port to test outside and separate from HA. Usually this page has basic hub details on it. If this page doesn’t load, it is most likely an issue with the hub itself. To be sure you can temporarily disable or restart HA. Try loading the hub local ip and port via your browser again and if the page doesn’t load, its a hub issue. If you want to ping the hub via command line remember that you cant ping a port so either telnet or use something like PaPing.)


I am currently troubleshooting this, or a very similar issue. I have a Insteon 2245-222 hub that is having very frequent periods of unresponsiveness to HTTP requests. Importantly, connectivity does eventually return without manual intervention, it can simply take a while. Wired lightswitches (2477D SwitchLinc Dimmers) and linked Mini remotes (2342-242) do not have issues and commands from them directly are always fine. Only HTTP requests fail.

I was curious about a way to track this to gather more information. Normal ping requests of the hub IP return successful whether it’s having an issue or not, however once you include the associated port you can see the issue. So a

telnet 192.168.1.123 25105

during an outage will be unsuccessful, but will be work fine while other HTTP requests are working.
(you can see your local hub IP and port by going to Get SmartLinc Info)

Attempting to find a way to actually track the outages I settled on PaPing which is a lightweight TCP port testing utility. Output looks the same as ping but you can point it at a port:
image

Above you can see the start to an outage. Keeping this running while researching today I noted the timestamps:

timeout start 3:04
timeout end 3:13

timeout start 3:27
timeout end 3:44

timeout start 3:55
timeout end 4:29 - power cycle

timeout start 4:47:35
timeout end 4:58

timeout start 5:39
timeout end 5:41 - power cycle

Given troubleshooting suggestions in this thread I confirmed an outage will resolve if I power cycled the hub.
I then tried setting up a firewall rule on my router to block the hub IP as well as stopping the home assistant container within docker.
These things had no effect as a new outage occurred anyway, however a power cycle did resolve it again.

Digging into the issue of the hub only allowing a single connection at a time I did find additional context here, however now things get a little murky. While it’s certainly true the hub will “lock out” other local connections, I’m not certain that is what is happening in my case, and others with this issue might want to review before making that assumption.

For one, I am able to successfully turn lights on and off via HTTP commands (browser or curl) on my desktop PC while simultaneously turning them on and off via the HA app on my phone, if not during an outage.
Second, I’ve had these outages occur without the HA container even running. I’ve also gone as far as unplugging my logitech harmony hub, alexa devices, and turning wifi off on my phone. I don’t believe there is anything else on my network that would ever establish a connection with the hub besides the insteon devices themselves.
Third, and possibly most strange, I discovered I can “brute force” a command through an outage and resolve it early.

If you aren’t familiar with insteon HTTP requests they look like:

http://USERNAME:[email protected]:25105/3?0262AABBCC0F11FF=I=3

http://USERNAME:[email protected]:25105/3?0262AABBCC0F1300=I=3

The first turns a light with device ID AABBCC on. The second turns a light with device ID AABBCC off. More info here.
To test if it works you can simply throw the request in your browser. Going just a bit further you can also use curl to make this request via batch file. Looks like:

@Echo off

curl http://USERNAME:[email protected]:25105/3?0262AABBCC0F11FF=I=3

Now I’m sure there are better ways of spamming HTTP requests, but I’ve just been spam opening the file a bunch. Usually around 5-10 times. The first or second request always fails, but with enough attempts, the requests seems to brute force their way through.
image
Here you can see the start to an outage, that I forced my way out of via spamming requests.

It’s like the hub is deciding to go to sleep randomly, but if you yell loud enough it will wake up. :roll_eyes:

From my perspective, the thing that would be really helpful would be the ability to log ANY network connections to or from the hub. That way, if it is actually this “single connection at a time” issue, I could see where that connection might be coming from. Sadly my router doesn’t have this capability. If you know how to do this via wireshark or other tool, please feel free to link a tutorial or let me know.

I mean the fix is to configure the hub with no default gateway so it cant talk to the Internet and only use Home Assistant and not the Insteon App

The issue is pretty well documented at this point, the hub keeps the connection open, and only allows one connection at a time.

Insteon is not going to fix our 7+ year old hubs….the very best we could hope for is a new hub that works with all the existing Insteon tech.

….come to think of it, it seemed like the new CEO was sending out email updates every couple weeks at first, and I have not seen any in a while. I wonder if they are facing the stark reality that the company randomly shutting down for 2 months is not good for customer retention.

That is also what I read, only one connection at a time. The connection out to the Internet may not count, IDK. But I don’t have their service, so I cannot even go in and reconfigure the hub. My issue could have been my HA was on one subnet, my Insteon on another, so perhaps my Ubnt EdgeRouter was closing the connections due to inactivity, or for whatever other reason losing the connection tracking in its state table. Or it could be that HASSOS was closing the connections due to inactivity, or whatever else. Nonetheless, the connection between HA and Insteon was obviously getting disconnected but left open on the Insteon hub side, resulting in this deadlock. The only resolution was to either wait it out (there must be some timeout on the hub’s firmware because it would resume after a day or two) or power cycle the hub.

I gave up and I had a USB PLM I sourced before the first Insteon debacle and I finally set it up with HA. Light years better. The only downside is that configuring switch<->switch Insteon links is not straightforward with the HA plugin as you have to know what to put in the ALDB link tables. If that could be improved in HA, the solution would almost replace the need for the older ISY, probably polisy and the Insteon hub. My only other dislike of the HA solution is how the remote switches are dealt with as events (although I sort of get this) and don’t show up in the devices. Also I wish you could rename the devices (and their respective entities) through the Insteon page rather than going back through the HA system Insteon integration page. Also it would be awesome if there were some automation templates created for people to get going quicker with the solution.

However, the current Insteon integration in HA is absolutely amazing as is, and the person maintaining it has done a phenomenal job for something that was done as open source and freely available. In fact their fix just recently to resolve the add device by address not working in the UI saved me from getting on a ladder to relink my fanlincs. They haven’t worked in several years as my hub somehow became disconnected from them, my serial PLM on my ISY failed, and I was dreading taking apart the low profile fans to get to the fanlinc buttons hidden in their housing against the ceiling. That type of break fix is something I don’t see in the commercial world anymore, sadly. Imagine if Insteon resolved something this fast and pushed out new firmware. Yeah, likely never going to happen. That’s why, IMO, I try to stick with HA for any smart home solution where I can.

On a side note, the hub, in my opinion, was always meant to be a turn key solution for the general consumer market, likely a last attempt to make Insteon as available as other technologies to a larger market where people aren’t as technically savvy and want an easier solution. The issue was, at almost $50 for a plug in module, when you can buy a wi-fi module that stands alone and has its own app for $15, the general consumer isn’t going to bite on this stuff. Eventually, those of us that loved the power of technologies like Insteon just start figuring out ways to make the cheap stuff work about as well and save a lot of money. Their shutdown was a huge blow, and I don’t think this stuff is ever going to recover to what is once was. Hence, about all we can do is find workarounds to the issues at hand now :’(

1 Like

How can I configure insteon with no default gateway without access to insteon app? Any guidance would be appreciated.

Use your DHCP server to set up a DHCP reservation with no, or a wrong, default route/gateway

Thank you so much, I have Unifi gateway. Under traffic management it is very complicated to block a cetian device from WAN (this is much different than traffic managment under UDM). Do you have any idea how I can go about this?

Following:

I have tried every thing listed in this forum and a few that aren’t and none has worked for me.