log into karaf and use bundle:uninstall
see also
http://docs.openhab.org/administration/bundles.html
Thank you for the hint.
I was searching since my last post and found these posts: Couldn't install any bindings in OH2 - #2 by rlkoshak
I made the mistake to delete both mentioned folders and not only the content…:(
The result was that openhab did not start at all. The folders were created after two reboots and now openhab is back up 
I wanted to check your hint to bundle:uninstall but there must be another problem now…it was so nice that everything worked before exept some error messages… 
Starting http://<ip-address>:8080/start/index there is following loader without end after 30min:
“Please stand by while UIs are being installed. This can take several minutes”
First I thought it must be something with the rights of the folders but there are newly created files in the folder.
I searched different articles but I did not change any java settings, time settings,…
Also after some reboots no ending and the UIs are not accessable.
karaf messages are ok like before the folder deleting
bundle:list does not say anything about “…hue…” from errors above
openhab.log says:
[WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/volume1/homes/openhab2/addons/org.openhab.binding.lgwebos-2.2.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.lgwebos [10]
Unresolved requirement: Import-Package: org.eclipse.jdt.annotation; resolution:=“optional”
Unresolved requirement: Import-Package: org.eclipse.smarthome.core.library.types
Unresolved requirement: Import-Package: org.eclipse.smarthome.config.discovery
Update on Sun, 19.11. I finally reinstalled the OpenHab with the newest snapshot for my Synology DS216play with
and everything works fine now 
Now it works fine:
items:
Number LG_TV0_KeyDummySpecial ""
Number LG_TV0_KeyDummyArrow “”
rules:
rule "LG_TV0_KeyDummySpecial"
when Item LG_TV0_KeyDummySpecial received command
then
switch receivedCommand{
case 0: sendHome(“192.168.0.11”)
case 1: sendOK(“192.168.0.11”)
case 2: sendBack(“192.168.0.11”)
}
end
rule "LG_TV0_KeyDummyArrow"
when Item LG_TV0_KeyDummyArrow received command
then
switch receivedCommand{
case 0: sendLeft(“192.168.0.11”)
case 1: sendDown(“192.168.0.11”)
case 2: sendUp(“192.168.0.11”)
case 3: sendRight(“192.168.0.11”)
}
end
sitemap:
Switch item=LG_TV0_KeyDummySpecial icon=“television” mappings=[0="\u2302", 1=“OK”, 2="\u21FD"]
Switch item=LG_TV0_KeyDummyArrow icon=“television” mappings=[0="\u2190", 1="\u2193", 2="\u2191", 3="\u2192"]
Thanks a lot for this great enhancement!
I want to bring the Source/Input selection to HomeKit so I can switch from my iPhone.
From BasicUI it works perfect:
items:
String LGTV_Application “Quelle [%s]” (gLGTV) {channel=“lgwebos:WebOSTV:192_168_XX_XX:appLauncher”}
Sitemap:
Switch item=LGTV_Application mappings=[“com.webos.app.hdmi1”=“Unitymedia”,“com.webos.app.hdmi2”=“Apple TV”]
The idea: To combine the application selection (just the idea, doesn’t work)
items:
String LGTV_Channel_Unity “Unity” (gLGTV) [ “Switchable” ] { channel=“lgwebos:WebOSTV:192_168_XX_XX:appLauncher:com.webos.app.hdmi1”}
How can I do it? Any idea?
Hi,
you could create a dummy Item and depending on the selection, using a rule, send it to the different real items.
Sebastian
I also thought about a rule but I wanted to solve it in items in one line if possible.
It is ok, i did it with rules and it works now. Thank you for the quick answer @sprehn !
If you don’t mind post your solution. I could imagine that more people are interested how this could work. I think it is a great idea.
Sure no problem. Feedback and enhancements allowed 
This is my Items file
I already had the AppLauncher for my BasicUI so I added the Button for iPhone / HomeKit:
String LGTV_Application “Quelle [%s]” (gLGTV) {channel=“lgwebos:WebOSTV:192_168_XX_XX:appLauncher”}
Switch LGTV_Channel_iPhone “Apple TV” (gLGTV) [ “Switchable” ]
I only need to and can Switch between 2 Inputs. One button is enough for me.
This is my rules file:
rule “TV Input from iPhone Switch”
when Item LGTV_Channel_iPhone changed
then
switch (LGTV_Channel_iPhone.state) {
case OFF: {sendCommand( LGTV_Application, “com.webos.app.hdmi1”)}
case ON: {sendCommand( LGTV_Application, “com.webos.app.hdmi2”)}
default: {sendCommand( LGTV_Application, “com.webos.app.hdmi1”)}
}
end
Result is an “Apple TV” Button. If it is not pressed, Input is Unitymedia (TV).
Switch it ON: Apple TV
Switch it OFF: Unitymedia (TV)
hello @sprehn, I was successfully installed this binding on windows machine, and I now want to move to raspberry pi. Currently I am using 2.2.0 SNAPSHOT version of binding and unable to use 2.1.0 SNAPSHOT
On RPi, OH cannot see my TV, it is showed as offline, and I cannot scan any TV too. logging is not helping yet, since when I scan for TV, no logs are created.
Is there any suggestion for me to take?
On RPis you may have to configure your local IP address of your PI in the binding configuration.
btw. this will go away in the next version, but that will break compatibility with 2.1.0, therefore I have not published this yet.
Configuring local IP still does not work. This is the debug log where 192.168.1.7 is my TV IP, and 192.168.1.79 is my RPi IP. I changed configured IP to TV IP, scan for items. Change back to RPi IP, scan for items.
2017-11-26 23:43:44.106 [DEBUG] [org.openhab.binding.lgwebos ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.model.script.engine.action.ActionService}={component.name=action.lgwebos, component.id=0, service.id=364, service.bundleid=9, service.scope=bundle} - org.openhab.binding.lgwebos
2017-11-26 23:43:44.122 [DEBUG] [org.openhab.binding.lgwebos ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=binding.lgwebos.handler, component.id=11, service.id=365, service.bundleid=9, service.scope=bundle} - org.openhab.binding.lgwebos
2017-11-26 23:43:44.134 [DEBUG] [org.openhab.binding.lgwebos ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.config.discovery.DiscoveryService, org.openhab.binding.lgwebos.internal.discovery.LGWebOSDiscovery}={service.pid=binding.lgwebos, localIP=192.168.1.7, component.name=binding.lgwebos, component.id=1, service.id=363, service.bundleid=9, service.scope=bundle} - org.openhab.binding.lgwebos
2017-11-26 23:43:44.154 [DEBUG] [.internal.discovery.LGWebOSDiscovery] - Config Parameters: {service.pid=binding.lgwebos, localIP=192.168.1.79, component.name=binding.lgwebos, component.id=1}
2017-11-26 23:43:44.155 [DEBUG] [.internal.discovery.LGWebOSDiscovery] - localIP parameter explicitly set to: 192.168.1.79
2017-11-26 23:43:44.169 [DEBUG] [org.openhab.binding.lgwebos ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.model.script.engine.action.ActionService}={component.name=action.lgwebos, component.id=0, service.id=367, service.bundleid=9, service.scope=bundle} - org.openhab.binding.lgwebos
2017-11-26 23:43:44.193 [DEBUG] [org.openhab.binding.lgwebos ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=binding.lgwebos.handler, component.id=11, service.id=368, service.bundleid=9, service.scope=bundle} - org.openhab.binding.lgwebos
2017-11-26 23:43:44.208 [DEBUG] [org.openhab.binding.lgwebos ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService, org.openhab.binding.lgwebos.internal.discovery.LGWebOSDiscovery}={service.pid=binding.lgwebos, localIP=192.168.1.79, component.name=binding.lgwebos, component.id=1, service.id=366, service.bundleid=9, service.scope=bundle} - org.openhab.binding.lgwebos
2017-11-26 23:51:32.056 [DEBUG] [org.openhab.binding.lgwebos ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.model.script.engine.action.ActionService}={component.name=action.lgwebos, component.id=0, service.id=367, service.bundleid=9, service.scope=bundle} - org.openhab.binding.lgwebos
2017-11-26 23:51:32.073 [DEBUG] [org.openhab.binding.lgwebos ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=binding.lgwebos.handler, component.id=11, service.id=368, service.bundleid=9, service.scope=bundle} - org.openhab.binding.lgwebos
2017-11-26 23:51:32.089 [DEBUG] [org.openhab.binding.lgwebos ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.config.discovery.DiscoveryService, org.openhab.binding.lgwebos.internal.discovery.LGWebOSDiscovery}={service.pid=binding.lgwebos, localIP=192.168.1.79, component.name=binding.lgwebos, component.id=1, service.id=366, service.bundleid=9, service.scope=bundle} - org.openhab.binding.lgwebos
2017-11-26 23:51:32.112 [DEBUG] [.internal.discovery.LGWebOSDiscovery] - Config Parameters: {service.pid=binding.lgwebos, localIP=192.168.1.7, component.name=binding.lgwebos, component.id=1}
2017-11-26 23:51:32.114 [DEBUG] [.internal.discovery.LGWebOSDiscovery] - localIP parameter explicitly set to: 192.168.1.7
2017-11-26 23:51:32.127 [DEBUG] [org.openhab.binding.lgwebos ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.model.script.engine.action.ActionService}={component.name=action.lgwebos, component.id=0, service.id=370, service.bundleid=9, service.scope=bundle} - org.openhab.binding.lgwebos
2017-11-26 23:51:32.146 [DEBUG] [org.openhab.binding.lgwebos ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=binding.lgwebos.handler, component.id=11, service.id=371, service.bundleid=9, service.scope=bundle} - org.openhab.binding.lgwebos
2017-11-26 23:51:32.159 [DEBUG] [org.openhab.binding.lgwebos ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService, org.openhab.binding.lgwebos.internal.discovery.LGWebOSDiscovery}={service.pid=binding.lgwebos, localIP=192.168.1.7, component.name=binding.lgwebos, component.id=1, service.id=369, service.bundleid=9, service.scope=bundle} - org.openhab.binding.lgwebos
I think you should publish the new version, with big announcement to prevent random people people to replace the binding for OH 2.1.0 to let beta testers try it with 2.2.0.
Here you go:
Please read the change log carefully before you upgrade:
Completely removed Action support. This will be implemented later in a separate bundle.
Removed localIp Config parameter. Using NetworkAddressService to find primary interface instead.NOTE: this version breaks compatibility with OH 2.1.0. You have to run at least 2.2.0 snapshot.
you should set the ip of your RP: 192.168.1.79
if that does not work there may be another issue and the new version may not help you. But give it a try.
Hey,
I have great news to share!
This morning my pull request was accepted into the main project.
We should see this binding appear in the next 2.2.0-snapshot build.
I would like to say Thank You to all of you, who tested and help bring this to this state.
Kind Regards
Sebastian
PS: Please continue to use the releases posted on this forum as long as you run OH 2.1
7 Likes
congratulations on the release! I cannot try the snapshot build yet, but just a question, if actions are removed in your latest build, how can we control the TV?
Hi,
Is webOS 3.5 supported by this binding?
Thx
Hi,
unfortunately I cannot give you a clear answer. Anything supported by Connect SDK. I would think it is supported. Are you experiencing any issue?
Sebastian
you can still use items and channel ans send commands to them via rules
I have a WebOS 3.5 TV and I’m having a weird problem with it in combination with this binding.
Basically, what happens is that when I turn off the TV (LG OLED65C7) at night it turns back on a few seconds later. Then, it finally turns off about 5 minutes later.
The weird thing is, I’ve never seen this, only my flatmate has seen it happen (he stays up much later than me). When I try to reproduce this behaviour during the day it doesn’t happen.
I’m wondering if it’s a combination of the TV’s panel maintenance mode and the binding trying to reconnect after the TV turned off. If the TV has been on for more than 4 hours then it will start a panel maintenance routine the moment you turn it off, the TV isn’t entirely off when it’s doing this. I suspect the TV can be turned on by trying to connect to it when it’s in this mode.
Hi,
normally this could not be the binding, as turning the TV on is not supported by Connect SDK. The only way I found this to work to send a wake on lan packet via the WOL binding.
maybe it has to do with the maintenance. If you experience this again, it would be worth capturing openhab logs. But as I said, I doubt it is related to this binding.
Kind Regards
Sebastian