Hub api endpoint mostly timing out

The API end point of my SmartApp on my hub recently began frequently hanging and thus not receiving my api call or returning any response. This is the API endpoint on the actual hub, that can be gotten in the app by using something like:

settings.hostHub.localIP + “:” + settings.hostHub.localSrvPortTCP

So in my case I make can make a http POST request to my hub at http://192.168.1.187:39500 which will cause my Smartapp to do something.

Anyway I started getting mostly timeouts at this hub api endpoint last Thursday. A few requests go thru, but most just hang forever.

Since these requests just hang, I never see my smartapp get invoked or log any information on the developer portal smart app logs in order to debug.

I’m wondering if anyone has any other debugging ideas, or has ever had any similar experiences that might point me to the issue.

Even though this problem just started for me last Thursday, after working fine for a few years, I don’t see any other posts about any outage or firmware issue in the forum about it, so I’m assuming something could be wrong with my hub. But I just can’t think of any other way to figure that out, or try to reset it, or otherwise fix it.

I did unplug it for several minutes to try to “reset” it, but that had no effect.

Any advice appreciated!

I don’t think ST opens any endpoints on the hub directly. Everything needs to go through the cloud. Where did you find this doc about direct endpoints on the hub?

3 Likes

Yes the ST hub does allow direct communication on the LAN via HTTP, I’ve been doing that for several years in a variety of ways, at least until last Thursday. It’s called a Lan Service Manager in the Smartthing docs:

https://docs.smartthings.com/en/latest/cloud-and-lan-connected-device-types-developers-guide/building-lan-connected-device-types/division-of-labor.html

Since it’s all on the LAN, it works even when the hub has no Internet, there is no cloud involved. The gist of it is in your SmartApp you subscribe to location events like so:

subscribe(location, null, onHTTPRequest, [filterEvents:false])

And then in onHTTPRequest() you handle any incoming HTTP requests, and have your SmartApp do whatever it needs to do. You get the local LAN ip and port of the ST hub by allowing the user to select a hub when they install the smartapp:

preferences {
    section("SmartThings Hub") {
      input "hostHub", "hub", title: "Select Hub", multiple: false, required: true
    }
}

Then with that selected hub you can get the IP and Port of your specific SmartApp on the ST hub as I described:

def getSmartThingsEndpoint() {
    return settings.hostHub.localIP + ":" + settings.hostHub.localSrvPortTCP
}

Here’s my Lan Service Manager project: https://github.com/rkroboth/smartthings_lan_service_manager

It has a groovy SmartApp that goes on the ST Hub, and a PHP portion that runs on a raspberry pi. Both of these devices communicate with each other – the ST Hub reports device changes to the raspberry pi, and the raspberry pi reports device changes to the ST hub, and they stay in sync this way.

More specifically, here is the groovy SmartApp part of this system, which listens for incoming HTTP requests on the ST Hub’s ip addy:

The problem is that last Thursday the ST Hub endpoint just started hanging, most of the time (but not all of the time – sometimes the endpoint works just fine like always). And I can’t figure out how to debug this, as a hanging connection to a black box (ST Hub) doesn’t give any info… nothing in the logs on the Smartthings dev console, just a hang… after several years of working just fine.

Seem unlikely they deprecated something, or it would just never work right? Seems more likely there’s some sort of problem with my hub?

However, seems unlikely to be a network problem on the hub, as all the ST hub’s communications back to the mothership seem to still work fine.

To me it sounds like a software error in the ST Hub, like some sort of loop it gets stuck in intermittently. I can’t find a way to see if some new firmware was installed last Thursday though.

I’m just out of ideas and frustrated, as my entire house and thousands of dollars is built around this service, and now nothing is working…

For mine, HTTP GET hangs for about 4-5 seconds, but if I set a header with “Content-Length: 0”, it goes through immediately (ugly workaround).

Maybe you can try setting “Content-Length” in your HTTP POST.

I don’t see anywhere in the documentation where it says you can connect to the hub directly? That’s pretty much against the entire ST architecture. the service manager runs in the ST cloud and communicates with the hub using hubAction which makes the hub communicate with local devices. If it did work, I’m reasonably sure it was probably due to a bug in the hub firmware. Maybe @Brad_ST can confirm

All SmartApps run in the ST cloud. The hub doesn’t run SmartApps locally (as yet and we’re hoping that ST will change this sometime soon, we’re all for it !!)

I saw your code and I see that you’re using a hubAction to communicate with your LAN host.
As my understanding of the ST architecture goes, the hubAction executes in the cloud, which sends the request to the hub to contact the LAN device, takes the response from the LAN device, converts/encrypts the response into a binary stream, sends it back to the ST cloud then decrypts it and relays it back to your SmartApp.
So if you internet connection goes offline, your hubAction won’t work since the hub can’t communicate with the cloud and the SmartApps are running in the cloud.

2 Likes

I’m positive I got this from some documentation, there’s no way I would have just made this up randomly and then it happened to work. I found numerous other SmartApps that work the exact same way, for example here’s one that’s much simpler but uses the same process: https://github.com/Welasco/NodeFirePlace

In any case, I will make an attempt to find further docs.

I also did try adding a content-length header, but still have the same problem. But that was a brilliant idea, as lots of web servers do hang without a content length so that would have made perfect sense.

1 Like

By the way – is there a way to see exactly when my firmware was last updated on the hub? So I can see if it was last Thursday? Of course if my requests locally are just getting forwarded to the cloud, then it wouldn’t matter, the problem could be completely outside of my LAN. Would be interesting to know from somebody who knows.

You could try and look at your IDE -> My Hubs -> List Events and scroll back till you find something

1 Like

So the documentation I linked up above seems to be describing the way I designed this:

https://docs.smartthings.com/en/latest/cloud-and-lan-connected-device-types-developers-guide/building-lan-connected-device-types/division-of-labor.html

It specifically says in the diagram under “How It Al Works”: “Messages to and from devices sent over LAN” – with arrows pointing back and forth between the devices and the hub.

From there I just researched exactly how you send a message to the hub from the device like described, and found that you use the procedure I described above. I found that by finding numerous examples of people doing this in their SmartApps, like the fireplace app I linked above…

1 Like

HTTP POST appears to be fine as it includes the correct Content-Length size.

[OK] -- curl -vvv http://IP:PORT/  --data "abc"
[OK] -- curl -vvv http://IP:PORT/ -sL -H 'Content-Length: 0'
[Hang 4-5 sec] -- curl -vvv http://IP:PORT/

I’m doing this in a device handler (not smartapp).

1 Like

Hmm I see it now, tucked away in the docs. Maybe someone from the ST staff can clarify:
https://docs.smartthings.com/en/latest/cloud-and-lan-connected-device-types-developers-guide/building-lan-connected-device-types/building-the-device-type.html#making-outbound-http-calls

Ok scrolling through that event log was very helpful. I see the hub went offline for about 4 minutes last Thursday, and that’s exactly when the problem started. The hub has gone offline 19 more times since then. (only one of those was me, manually power cycling it).

I found the hub info there too, it says firmware 000.025.00026 and was last updated 2019-03-27 6:36 PM UTC. So I’d say a firmware update was not the problem.

My local network is running smoothly, I just double checked it. At this point I’m thinking my hub is screwed up, maybe lightning hit it or something last Thursday… and I’ll just go buy a new hub… any other thoughts before I do that?

Thanks for ya’lls help.

I got my hands on another hub, and this one is working with no problems. So I guess maybe my hub got damaged last week. I’m chalking it up to that – thanks for all the feedback and testing!

2 Likes