Hub goes inactive at random times

So…looking for any advice here. My V2 hub goes inactive at random times and for no apparent reason. My Internet connection is solid, IP addressing on the local network correct and working perfectly…nothing wrong that is apparent.

Any suggestions on what else I should look for? This has happened several times now and it appears the only cure is to remove the battery and power to the unit…wait a bit and then power back up. I’ve even taken to rebooting the hub every 24 hours but that did not help.


And interestingly enough, the device continues to be pingable from the local network…by name and IP address.

Brain dead?

I seem to be having a similar problem. My hub stopped controlling my Hue lights about an hour ago, my motion sensors still seem to be working and registering but nothing is being triggered. Doesn’t seem to be any reason for it, it happened yesterday too.

One thing you can do is make sure the proper ports are open on your firewall.

You can follow find port info on the following support article.

1 Like

In all honesty, people think their internet connection is solid for but for the majority it actually is, dropping packets quicker than I drop brain cells listening to Trump but that’s another story.

Pinging the hub locally solidly doesn’t mean that it can be reached by ST’s servers remotely without dropping packets and it’s ST’s servers that send you a push notification when they can’t reach your hub. Additionally, not only do some routers drop packets horribly, some don’t even like to create new connections and get overwhelmed, especially if you torrent.

It’s worth checking the ports @slagle is talking about but honestly they’re outbound ports and for the most part, unless you specifically configure your setup to block outbound connections, it’s highly unlikely that you are, but still worth a check.

So…in attempting to reboot the hub via the SmartThings site, I get the following in live logging…

Scheduling Auto Rescheduler…

329e4bf7-07d9-4df5-a4a1-58234d0a9dda ‎6‎:‎20‎:‎08‎ ‎PM: debug getChildDevices(true), children=1

329e4bf7-07d9-4df5-a4a1-58234d0a9dda ‎6‎:‎20‎:‎08‎ ‎PM: info Refreshing data…

329e4bf7-07d9-4df5-a4a1-58234d0a9dda ‎6‎:‎18‎:‎16‎ ‎PM: error Connection reset @ line 261

329e4bf7-07d9-4df5-a4a1-58234d0a9dda ‎6‎:‎18‎:‎15‎ ‎PM: info Scheduling Auto Refresh…

329e4bf7-07d9-4df5-a4a1-58234d0a9dda ‎6‎:‎18‎:‎15‎ ‎PM: info Last refresh was 27.6961 minutes ago

‎6‎:‎17‎:‎35‎ ‎PM: info Waiting on events…

The Java Exception tells me that the connection was likely closed or a buffer overflow occurred. I used to write lots of code (many years ago) and handling exceptions was core to good function. I don’t understand why this device would spout an error such as this and not recycle itself. IMHO this is just poor error handling.

I get the “cloud” portion of this system but understand why there isn’t a local interface into the hub for times such as these.

Funny thing, my apps reports that the hub is inactive but it still tells me when a state change occurs (e.g., I turn off a light). Tells me that the “cloud” services are a little too simple at this point.

I get your statement about Internet connections and, yes, that could be the issue here. But then why do all my other devices not have similar problems? Rhetorical question but leads me to believe that the code in the hub is not yet robust.

I will check ports but given that it works “a lot” of the time, the ports must be working “some of the time.” I have a Netgear R8000 Nighthawk and have never had problems with it randomly closing inbound or outbound ports.

What’s interesting is some “limbic” action is occurring. The Live Logs tell me that some communications are occurring. It reports when my SmartPhone presence has “left” after shutting down the mobile app.

Because they’re usually creating outbound connections that will usually resend packets if they’re dropped and nothing is monitoring them externally.

That being said, the R8000 is a great router, my parents have the R7000 and the stock firmware is indeed very good so you should be okay. That being said just run a continuous ‘ping’ to ‘’ (use the -t options if you’re on Windows), leave it running for a few minutes and then when you stop it, see how many packets were dropped.

Ran a S*(t load…0% loss.

kinda a shot in the dark, but can you run a ping test and check for packet fragmentation? It’s probably fine, but I’ve seen some odd network behavior before when the packets were being fragmented because the MTU’s were set too large. … ping [-f] [-l ] [host] you can start with 1500 packet size and go from there…

I have this issue. Did any one else solve this