openhab / openhab1-addons

Add-ons for openHAB 1.x
Eclipse Public License 2.0
3.43k stars 1.71k forks source link

New LG-Binding leads to Load-Leak #1700

Closed cribskip closed 9 years ago

cribskip commented 9 years ago

Hi,

I'm using the 1.4.0 LG-TV Bundle built by @martinfluchgmxnet some time ago. After PR #925, I got the first cloudbees build and installed it. Works fine with these openhab.cfg-settings:

LgTV Binding

Host of the first lgtv device to control

lgtv:.host=# Port of the lgtv to control (optional, defaults to 60128)# lgtv:.port=# Host of the first lgtv device to control # lgtv:.host=# Port of the lgtv to control (optional, defaults to 60128)# lgtv:.port=

The lgtv:main.host value is the ip address of the lgtv .

The lgtv:main.port value is TCP port address.

The lgtv:main.serverport is TCP port address on the openhab system to receive lgtv status messages (only first occurance is used for all tvs)

The lgtv:main.xmldatafiles location to put xml files with the information of availiable channels and apps (optional)

The lgtv:main.checkalive check if tv is availiable every 60secs

The lgtv:main.pairkey - the pairkey / if it's empty the device shows the pairkey at every connection attempt

lgtv:wohnzimmer.host=10.0.0.26 lgtv:wohnzimmer.port=8080 lgtv:wohnzimmer.pairkey=736855 lgtv:wohnzimmer.serverport=9080 lgtv:wohnzimmer.xmldatafiles=./ lgtv:wohnzimmer.checkalive=15

As I turn off my TVs power by KNX, I changed the check alive to 15 seconds.

Yesterday, my openhab server acted strange: no ssh-login possible (timeouts), ping still possible, openhab not doing apparently anything. Boils down to this binding as replaced by the old one it keeps going fine.

Freezes came to life about 10 hours after TV turned off.

TL, DR: New LG-Binding with checkalive=15 seems to increase CPU load to deadly ranges.

Thanks for the great efforts and work, Sascha

PS: #1686 is not the case - subfolders were already deleted ;)

teichsta commented 9 years ago

@martinfluchgmxnet could you please take care of this? Preferably before Saturday night?

martinfluchgmxnet commented 9 years ago

Hi @cribskip

Does it work with the default Keepalive Setting in your Environment?

Martin

martinfluchgmxnet commented 9 years ago

After quick Check of the sources the config value is not used, 10secs are currently hardcoded - so the change of the value cannot Lead to the bug. Is the error reproduceable?

If so @cribskip - can You increase the log Level of lgtv binding to Debug and attach the Logs to the issue / in my Environment the binding is Running since 1 week

@teichsta / sorry earliest chance to make deeper Checks is next Weekend

Martin

cribskip commented 9 years ago

Hi,

I'd like to help debug this but I don't know what to put in my logback.xml, can anybody help?

Maybe this is a coincidence with my.openhab. As I suffer the same problem as mentioned in #1702, maybe both bindings escalate up to this state.

I'm running on a dual-core ARM board with Ubuntu and java 1.8.0_06-b23. Here's also my used bindings: org.openhab.binding.astro-1.5.1.jar org.openhab.binding.exec-1.5.1.jar org.openhab.binding.fritzbox-1.5.1.jar org.openhab.binding.homematic-1.6.0-SNAPSHOT-pb14.jar org.openhab.binding.http-1.5.1.jar org.openhab.binding.knx-1.5.1.jar org.openhab.binding.lgtv_1.4.0.jar org.openhab.binding.networkhealth-1.5.1.jar org.openhab.binding.onkyo-1.5.1.jar org.openhab.io.myopenhab-1.4.0-SNAPSHOT.jar org.openhab.persistence.rrd4j-1.5.1.jar

Sascha

cribskip commented 9 years ago

Ok, so today this issue got me again, but I've used the old 1.4.0 build of this bundle. Seems the error originates from another cause.

Sorry for upseting the apple cart...

Sascha