Is OH (1.8.3) on Windows more stable than on Linux?

I have two demo systems running; one on a R Pi another on Windows 10.

On the RPi I get:
2016-07-06 11:43:46.782 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out 2016-07-06 11:43:46.784 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from 'YahooWeatherCache' 2016-07-06 11:46:29.674 [INFO ] [c.internal.ModelRepositoryImpl] - Refreshing model 'lights.items' 2016-07-06 12:00:38.718 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out 2016-07-06 12:00:38.724 [ERROR] [.o.b.http.internal.HttpBinding] - No response received from 'YahooWeatherCache'

On Windows I get:
2016-07-06 11:46:34.580 [INFO ] [runtime.busevents ] - Weather_Temperature state updated to 13 2016-07-06 11:46:34.589 [INFO ] [runtime.busevents ] - Weather_LastUpdate state updated to 2016-07-06T11:46:34 2016-07-06 11:46:35.589 [INFO ] [runtime.busevents ] - Weather_Humidity state updated to 52 2016-07-06 11:47:35.896 [INFO ] [runtime.busevents ] - Weather_Temperature state updated to 13 2016-07-06 11:47:35.901 [INFO ] [runtime.busevents ] - Weather_LastUpdate state updated to 2016-07-06T11:47:35 2016-07-06 11:47:36.902 [INFO ] [runtime.busevents ] - Weather_Humidity state updated to 52 2016-07-06 11:48:36.824 [INFO ] [runtime.busevents ] - Weather_Temperature state updated to 13 2016-07-06 11:48:36.828 [INFO ] [runtime.busevents ] - Weather_LastUpdate state updated to 2016-07-06T11:48:36 2016-07-06 11:48:37.833 [INFO ] [runtime.busevents ] - Weather_Humidity state updated to 52 2

Same configuration when it comes to Yahoo.weather… both using weatherCache…
Why the difference. Anyone else observed something similar?

The Raspberry Pi’s network connection is either misconfigured or faulty in some way. If on wi-fi, try a wired Ethernet connection, or vice versa, make sure your default route, DNS servers, etc., are configured correctly.

I run openHAB 1.8.3 on a Raspberry Pi 2 and I find it extremely reliable.

1 Like

Thanks, both are wired, same switch…
Would also think that the rPi is highly reliable…
Maybe it is related to the cache, rather than the ‘machine’ itself?!
Maybe it is not a OS question in the end…

Have a couple of RPi2s running with OH1.8.3 -> up and running and fully stable.
Seems like a (http) connection issue. Do you have more details?

1 Like

I had some serious issues (extremly slow response, unreliability) on my Beaglebone black on Debian Wheezy running the default java version (Open JRE version 7) I installed with

apt-get install default-jre

After replacing this version with the Java 8 JRE, everything runs very smoothly again.

Maybe you face the same issue?

1 Like

Will have a look… I would assume that OH would pull form the cache, whether it is updated or not… I will create new post is this is the issue.

Mine is:
java version "1.8.0_65" Java(TM) SE Runtime Environment (build 1.8.0_65-b17) Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)
on
"Raspbian GNU/Linux 8 (jessie)"

Same version here on a RPi2, runs without any problems and is very reliable …

1 Like

Do you have a dedicated power supply on your Pi? Have you tried a different power supply or USB cable?

Thank you all…
Yes, network, power supply are all OK.
My question was relating to the different results of the weatherCache on two identical OH configurations, yet on different OS configurations.

The only think I can think of that would cause an issue with the Weather would be the number of calls in a given time frame. I know when I’m tweaking things and constantly restarting OH it takes a while before the weather actually updates again.

I thought that too, but the two systems run in parallel, one is complaining, the other isn’t.
I do not know how the weather binding works, or what happens to the cache. In my opinion, the cache should not be deleted when new information cannot be obtained. It is better to have old data than no data at all.