HTTP Binding stops refreshing after a while

I’m having this weird issue with the http binding. I’m using it to get information from my thermostat and yahoo weather. It works fine other than the fact that every once in a while it just stops working. I’ll notice that my charts have flatlined and the temperature values on my dashboard have been “stuck” on one set temperature for a while.

Once I restart, the actual value is registered and everything starts working as expected again. Why would this happen? I’ve tried having it refresh every minute and every 30 seconds and I still get the same issue.

Connection issue possibly? Have you left a ping going in the background to see if your losing connection?

Have you combed through the openhab.log file looking for suspicious lines?

The log file just tells me there’s a “read time out”. But when I restart OpenHab, it connects again and updates fine for a while.

2016-01-08 16:33:37.338 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2016-01-08 16:33:37.340 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from ‘tstat’
2016-01-08 16:33:42.427 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2016-01-08 16:33:42.428 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from ‘tstat’
2016-01-08 16:33:47.439 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2016-01-08 16:33:47.440 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from ‘tstat’
2016-01-08 16:33:52.451 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2016-01-08 16:33:52.452 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from ‘tstat’
2016-01-08 16:34:12.482 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2016-01-08 16:34:12.483 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from ‘tstat’
2016-01-08 16:34:17.663 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2016-01-08 16:34:17.664 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from ‘tstat’
2016-01-08 16:34:22.675 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2016-01-08 16:34:22.677 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from ‘tstat’
2016-01-08 16:50:12.116 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2016-01-08 16:50:12.118 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from ‘http://weather.yahooapis.com/forecastrss?w=2389611&u=f
2016-01-08 17:06:34.415 [INFO ] [g.openhab.model.script.Weather] - Temperature evolved of -1 degrees.
2016-01-08 18:11:16.060 [INFO ] [g.openhab.model.script.Weather] - Temperature evolved of -1 degrees.
2016-01-08 18:24:28.680 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2016-01-08 18:24:28.681 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from ‘http://weather.yahooapis.com/forecastrss?w=2389611&u=f
2016-01-08 19:13:00.162 [INFO ] [g.openhab.model.script.Weather] - Temperature evolved of -2 degrees.
2016-01-08 19:20:08.295 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2016-01-08 19:20:08.296 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from ‘http://weather.yahooapis.com/forecastrss?w=2389611&u=f
2016-01-08 20:13:45.405 [INFO ] [g.openhab.model.script.Weather] - Temperature evolved of -2 degrees.
2016-01-08 20:23:45.731 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2016-01-08 20:23:45.734 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from ‘http://weather.yahooapis.com/forecastrss?w=2389611&u=f
2016-01-08 21:04:19.022 [INFO ] [g.openhab.model.script.Weather] - Temperature evolved of -1 degrees.
2016-01-08 21:05:19.987 [INFO ] [g.openhab.model.script.Weather] - Temperature evolved of 0 degrees.
2016-01-08 21:06:20.529 [INFO ] [g.openhab.model.script.Weather] - Temperature evolved of -1 degrees.
2016-01-08 23:00:01.965 [ERROR] [.myopenhab.internal.MyOHClient] - Socket.IO error: com.github.nkzawa.engineio.client.EngineIOException: xhr poll error

It seems like the root cause of the issue is networking, as opposed to software, but I’m not fully sure of that. At the time ERRORs are being logged, can you separately perform curl commands to query those same URLs from the same computer that’s running openHAB? In other words, has a network problem appeared from the perspective of that computer, and openHAB is only logging it?

The reason I thought it was software related was because when I restart openHAB with “sudo /etc/init.d/openhab restart”, everything seems to connect again and work for a while. Until something happens and it disconnects again. I lost connection again since last night and this is the error that I’m seeing in the log:

2016-01-10 06:54:24.883 [ERROR] [.myopenhab.internal.MyOHClient] - Socket.IO error: com.github.nkzawa.engineio.client.EngineIOException: xhr poll error

I believe that log error is fairly common and related only to my.openhab.org. The issue with the HTTP binding seems to be that something happens to the network continuity from your openHAB server to the server you are trying to poll, but it’s difficult to diagnose from a distance, and even up close the issue could be with your router, ISP, their providers, the remote server, or anything along that path. If you are watching the server log more “Fatal transport error: java.net.SocketTimeoutException: Read timed out”, try to use curl at a command prompt to reach the same server the same way as your items, and see if the problem can be seen outside of openHAB. I wish I had more to offer on it right now!

Have you tried to leave a ping running in the background?

I haven’t tried leaving a ping running in the background but I did try to reach the server using curl while openHAB couldn’t connect. Right now openHAB isn’t updating the HTTP binding but when I use curl to access the same api, I get a response just fine. But openHAB was not updating.

Again, I restarted openHAB and it’s now updating again. What’s weird is that it’s not just my wifi thermostat that stops working, it’s also my yahoo weather. I’m using HTTP binding for both of these and they both seem to fail after a while but then start working again once I restart OpenHAB.

On which version of openHAB is this occurring? If you are not on openHAB 1.8, do you mind upgrading?

I was on 1.7 but just upgrade to 1.8 this morning. So far so good. I’ll let you know towards the end of the day how it went. It usually doesn’t last a full day so we’ll see. Thank you for your help!

1 Like

So that worked for about 9 hours but then it timed out again. This is the error I got in the log after it timed out:

2016-01-11 17:36:25.853 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out

This was the last entry even though it says 5:36, my data shows that it last contacted yahoo weather at 6:38. Not sure why there isn’t a Read timed out error closer to that time.

Anyways, I’m wondering if my refresh rate has something to do with it. I had it getting an update from my thermostat every 30 seconds which is a little much. So I changed that to every 2 minutes. We’ll see if this helps any.

It’s conceivable that polling something twice a minute for hours exhausted some resource or exposed some bug in the thermostat, local OS, network stack, etc. Slowing it down to once every 2 minutes might either solve the issue or make it last 4X longer (about 36 hours). Anyway…I think that’s a good change. Let us know what you see. Also, is your operating system up to date?

I changed the refresh rate to every 10 minutes (600,000 ms). It worked from 7pm yesterday to about 11am today. I just restarted it again now at 12pm to see how long it’ll last again.

Ok, so it’s been almost 48 hours and it’s still going strong. It must’ve been the polling for some reason. Thank you for the help!

So changing the refresh rates just prolonged the time it took before quitting again but it did eventually fail again. It’s almost as if after a certain number of HTTP requests, it just stops responding. All my other data seems fine but anything that I have requesting data from the HTTP binding, just stops. I’ll continue to do some testing and let you know if I find anything out.

Another user here reported that this may be related to using a Raspberry Pi 2 to run OpenHAB. He was seeing a similar situation and ended up moving his setup to an actual server and he no longer had this issue. I would really like to try and get this working on my Raspberry Pi 2 so I’ll keep trying and see if I can figure out how to make it work. Thanks!

I use the HTTP binding to poll wunderground every 30 minutes on an RPi2 for three locations, and it absolutely never enters a continuous failure state:

http:xxxWeather.url=http://api.wunderground.com/api/KKKKK/conditions/q/XXXXX.xml
http:xxxWeather.updateInterval=1800000
http:yyyWeather.url=http://api.wunderground.com/api/KKKKK/conditions/q/YYYYY.xml
http:yyyWeather.updateInterval=1800000
http:zzzWeather.url=http://api.wunderground.com/api/KKKKK/conditions/q/ZZZZZ.xml
http:zzzWeather.updateInterval=1800000

I wonder if there is something about your tstat that is not closing its side of the socket or leaving the connection in some unfinished state, and this is eventually exhausting some resource in the JVM? I don’t know offhand how to diagnose this, but there ought to be a way to examine TCP connections. Sorry I don’t have more to offer atm.

I use http to pull data from several PoKeys57 boards every 10 seconds without issue.

I am getting this same error. It does not seem worth starting a new thread when the issue is nearly identical.

I am using v1.8.1 and have been for awhile. I use the http binding to control an instance of VLC on a computer that controls my homes sound system.

The issue is that when VLC is not activated on this computer the cache item updates timeout, which is to be expected. The problem is that after awhile openhab seems to crash and stops updating all items. Activating VLC does not fix the issue once openhab has crashed and the only option is to restart openhab.

While the timeout is to be expected when VLC is not running, having the entire openhab system crash because a cache item is not working for an extended period of time does cause problems. It seems like a more minor issue overall, but does mean that the openhab system is less stable than I originally thought. Hopefully someone is able to identify this issue so it does not carry over to openhab 2.