Connect SDK Binding (for LG WebOS TVs)

webos
connectsdk
Tags: #<Tag:0x00007f0153674750> #<Tag:0x00007f01536741b0>

(Sebastian Prehn) #285

Now check your openhab log file (userdata/logs/openhab.log) for messages

but I cannot say what to look for at the momment.

And what does paperui say under Configuration > Things? Is the device online?


(Chad) #286

@sprehn

I opened PaperUI and found it offline. Then I pressed the edit button in the bindings list, didn’t change anything, pressed save and then this came up in the log. Maybe this is just standard, but maybe there are some clues here. The TV is now connected/online…

Here’s some log activity:

> 2017-10-05 15:48:21.895 [DEBUG] [org.openhab.binding.connectsdk      ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.model.script.engine.action.ActionService}={service.pid=action.connectsdk, component.name=action.connectsdk, component.id=9, service.id=113, service.bundleid=10, service.scope=bundle} - org.openhab.binding.connectsdk
> ==> /var/log/openhab2/events.log <==
> 2017-10-05 15:48:21.927 [hingStatusInfoChangedEvent] - 'connectsdk:WebOSTV:192_168_1_32' changed from OFFLINE (COMMUNICATION_ERROR): connectsdk:WebOSTV:192_168_1_32 not found under connect sdk devices to UNINITIALIZED
> 2017-10-05 15:48:21.945 [hingStatusInfoChangedEvent] - 'connectsdk:WebOSTV:192_168_1_32' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
> ==> /var/log/openhab2/openhab.log <==
> 2017-10-05 15:48:21.951 [DEBUG] [org.openhab.binding.connectsdk      ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=binding.connectsdk.handler, component.id=20, service.id=116, service.bundleid=10, service.scope=bundle} - org.openhab.binding.connectsdk
> 2017-10-05 15:48:21.963 [DEBUG] [org.openhab.binding.connectsdk      ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.config.discovery.DiscoveryService, org.openhab.binding.connectsdk.internal.discovery.ConnectSDKDiscovery}={service.pid=binding.connectsdk, localIP=192.168.1.31, component.name=binding.connectsdk, component.id=10, service.id=112, service.bundleid=10, service.scope=bundle} - org.openhab.binding.connectsdk
> 2017-10-05 15:48:21.991 [INFO ] [ternal.discovery.ConnectSDKDiscovery] - {service.pid=binding.connectsdk, localIP=192.168.1.31, component.name=binding.connectsdk, component.id=10}
> 2017-10-05 15:48:21.994 [DEBUG] [ternal.discovery.ConnectSDKDiscovery] - localIP parameter explicitly set to: 192.168.1.31
> 2017-10-05 15:48:22.014 [DEBUG] [org.openhab.binding.connectsdk      ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.model.script.engine.action.ActionService}={service.pid=action.connectsdk, component.name=action.connectsdk, component.id=9, service.id=931, service.bundleid=10, service.scope=bundle} - org.openhab.binding.connectsdk
> ==> /var/log/openhab2/events.log <==
> 2017-10-05 15:48:22.034 [hingStatusInfoChangedEvent] - 'connectsdk:WebOSTV:192_168_1_32' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
> 2017-10-05 15:48:22.043 [hingStatusInfoChangedEvent] - 'connectsdk:WebOSTV:192_168_1_32' changed from INITIALIZING to OFFLINE
> ==> /var/log/openhab2/openhab.log <==
> 2017-10-05 15:48:22.046 [DEBUG] [org.openhab.binding.connectsdk      ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=binding.connectsdk.handler, component.id=20, service.id=932, service.bundleid=10, service.scope=bundle} - org.openhab.binding.connectsdk
> 2017-10-05 15:48:22.052 [DEBUG] [org.openhab.binding.connectsdk      ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService, org.openhab.binding.connectsdk.internal.discovery.ConnectSDKDiscovery}={service.pid=binding.connectsdk, localIP=192.168.1.31, component.name=binding.connectsdk, component.id=10, service.id=930, service.bundleid=10, service.scope=bundle} - org.openhab.binding.connectsdk
> 2017-10-05 15:48:24.809 [DEBUG] [ctsdk.handler.AbstractChannelHandler] - Subscribed org.openhab.binding.connectsdk.handler.VolumeControlVolume on IP: 192.168.1.32
> ==> /var/log/openhab2/events.log <==
> 2017-10-05 15:48:24.814 [hingStatusInfoChangedEvent] - 'connectsdk:WebOSTV:192_168_1_32' changed from OFFLINE to ONLINE: Device Ready
> ==> /var/log/openhab2/openhab.log <==
> 2017-10-05 15:48:24.824 [DEBUG] [ctsdk.handler.AbstractChannelHandler] - Subscribed org.openhab.binding.connectsdk.handler.VolumeControlMute on IP: 192.168.1.32
> 2017-10-05 15:48:24.834 [DEBUG] [ctsdk.handler.AbstractChannelHandler] - Subscribed org.openhab.binding.connectsdk.handler.LauncherApplication on IP: 192.168.1.32
> 2017-10-05 15:48:24.845 [ERROR] [ectsdk.handler.MediaControlPlayState] - 0 null null
> ==> /var/log/openhab2/events.log <==
> 2017-10-05 15:48:24.854 [vent.ItemStateChangedEvent] - LG_TV0_Power changed from OFF to ON
> 2017-10-05 15:48:24.925 [vent.ItemStateChangedEvent] - LG_TV0_Application changed from NULL to netflix
> 2017-10-05 15:48:24.933 [vent.ItemStateChangedEvent] - LG_TV0_Volume changed from NULL to 0.14000000

(Sebastian Prehn) #287

RC2 Released
I invite everyone to test this.

Notable changes:

  • The binding is now called lgwebos binding. This will make it easier to find the binding. Users will not care how this is implemented under the hood. This means you will have to configure a new “Thing”.

  • A couple of channels were removed or consolidated. The volume channel now works as a Dimmer and accepts Percent Type, Inc/Dec Type, On/Off Type.

  • Binding will connect the device immediately once added from the inbox. No need anymore to first connect a channel.

Documentation


(Chad) #288

@sprehn I’ll give it a try. Can it installed while v2.1 is running? Can the bindings both be run at the same time?

First thing on my system was several channels were missing in 2.2:
2.1:

2.2 channels:


(Sebastian Prehn) #289

yes, I run it with 2.1 as well.

It is correct the new binding has less channels. I removed channel mediaState, which I believe is not working correctly.
VolumeUp and VolumeDown are now integrated into Volume. Just send Increase or Decrease to Volume channel. Volume channel is now a dimmer instead of a number.

Similarly all Media Control channels were consolidated into mediaPlayer, except Stop (as Media Player does not offer this command).


(Chad) #290

Thanks for clarification.

I’m up and running on the new binding. I’ll report any issues if I get any.


(Sebastian) #291

Hello @sprehn,

I’m a newbie with openhab2. I’ve installed it yesterday and wan’t to pair my LGwebOStv now. I’ve put your .jar file in my addons folder and restarted my openhab server. The problem with the duplicated network address could be solved by adding the raspberry ip in the localip-setting.But it can’t find any LG-devices by scanning the network. The option “LG connect apps” is activated on my tv and the openhab.log is out of any failures. Is there any option to debug your binding to see a more detailed log? The pairing between my smartphone and my tv is still working, so the network settings should be correct (I can also ping my lg-device from raspberry). Can I set the IP of my tv manually to check the connection?

Thanks in advance for your help!


(Sebastian Prehn) #293

Hi @HSVSebastian,

When you set the localIp did you set the IP which is on the same network as your TV? Just want to double check you did not set 127.0.0.1.

In order to enable debug logging log into Karaf console:

ssh -p 8101 openhab@localhost  // password is habopen
log:set DEBUG org.openhab.binding.lgwebos

You will find logs under userdata/logs/openhab.log

Now see if you can spot sth yourself, or post the output here.

Kind Regards
Sebastian


(Sebastian) #294

@sprehn at first thanks for your quick response.
Yes, it was the network-IP of my raspberry.

After setting correct debug mode, the log was without any failures, but I think I could find the problem. My iptables Firewall is configured to strict. After clearing the firewall rules I can see my TV and all functions work fine! It’s a perfect binding!

Can you help me with configuring my firewall rules?

At the moment I have following rules:

##### BEGIN #####
:INPUT DROP [159:12505]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [140:13492]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -s 192.168.2.0/24 -p tcp -m state --state NEW -m tcp --dport ssh_port -j ACCEPT
-A INPUT -s 192.168.2.0/24 -p tcp -m state --state NEW -m tcp --dport 8090 -j ACCEPT
-A INPUT -s 192.168.2.0/24 -p tcp -m state --state NEW -m tcp --dport 8080 -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
##### END ###

I think you will use an alternative port for network scaning, isn’t it?

Thanks for your help!


(Sebastian Prehn) #295

Hi,

ok, that’s an interesting question, and I don’t have the answer ready, but maybe we can develop the solution together.

You would definitely need to allow TCP traffic from your openhab device to the TV on port 3001.
Then for SSDP discovery you need to allow UDP traffic to this multicast address 239.255.255.250 port 1900

Now the tricky part is. That responses will be sent back to the source IP and Port of the request. See:

So if your multicast was sent from local port 47001 (this one will change every time) to port 1900 on the multicast address. the response from the tv would be sent back to port 47001 on your openhab server. This is a challenge to configure in your firewall. Check this out:


but I suspect you have to accept incoming UDP packets from all port. At least I see that the TV responds back to openhab on a high (random) port as well.

Would be exciting to see if you could post a working ruleset.


(Sebastian) #296

Thanks for your explanation!

The only rule, which is necassary to be added is following:

-A INPUT -s 192.168.2.0/24 -p udp -m state --state NEW -m udp --dport 32768:61000 -j ACCEPT

this should be all emphemeral ssdp ports, if we can trust this configuration:
https://gist.github.com/egeste/780ef7fa540ddc7462be

In my iptables-configuration it’s unnecassary to open TV port 3001 seperately because I’ve added following line above, which maintains all established traffic, which was started by raspberry:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Now I can control my TV witch Openhab! Thank yopu very much!


(Ryan Smith) #297

Just wanted to post a quick tip as I spent a day or so scanning through all the great suggestions yet still couldn’t for the life of me discover the tv.

It turned out I couldn’t connect via OpenHab OR the Android app ect.

The “strange but true” solution:
On the TV open the Settings
Open Network
Check the Name is something short eg. lgtv (mine defaulted to “[LG] WebOS Television” which is what was causing the problem)

The moment I changed the name (well within the time it took to walk from the lounge to my study) the tv was sitting their waiting to be added as a thing.


(Tejo) #298

Finally working on RC2. With RC1 I have no luck. Thanks for great work, unfortunately my TV does not support wake on lan, so I still have to rely on IR blaster to turn on TV. Keep it up!


(Róbert Zeman) #299

Its possible send WOL packet to wake up tv from RPi 2 ? Because everything except turn on is ok
TV support WOL, i was wake tv from computer and this is ok.


(Nicke) #300

@sprehn, using autodiscovery everything works perfect.
However, I’m using items file and I want to use .things file also.
It does not matter what I select in my .things file as it still does not pick up correctly in openhab.
What would a .things file look like?

lgwebos:WebOSTV:192_168_1_6 "LGWebOS3" [ ipAddress="192.168.1.6" ]

Also, I am seeing everyone uses “connectsdk”, but my openhab chooses “lgwebos” as binding ID.
But that is probably due to old binding usage and I’m using the new one (on openhab 2.2 nightly)


(Sebastian Prehn) #301

Use the WOL binding and add a rule to send the WOL to your TV when switch for power receives the ON command. See Documentation.


(Sebastian Prehn) #302

The old name of the binding is connectsdk, but I renamed it to lgwebos. I published a release, see RC2. Not sure which version you get from the nightly builds.
I have no experience with things files myself. The property name should be localIP instead of ipAddress . maybe it also needs to be binding.lgwebos.localIP, not sure.


(Nicke) #303

@sprehn, I’m using the RC2 of your binding.
Normally in my .things file I have according to above.
And syntax should be:
Thing <binding_id>:<type_id>:<thing_id> “Label” [ ]

It seems your binding is not picking up the IP of the TV.
I tried localIP but it didnt work.


(Sebastian Prehn) #304

ah, true, for the thing there is no property. the IP is in the thing id.


(Nicke) #305

Yeah, I figured so.
So it takes thing ID and in the binding it does something to use it as IP address of TV.
However, that will not work with .things file.
It’s no biggie for me, I will just have to “add tv via discovery”.
But maybe you can make a note of this if/when you revisit your binding to adapt it into openhab standards :slight_smile:
Great binding, cheers!