LGWebOS Binding (for LG WebOS TVs)

I suspect this is the SSDP notification that the device is going offline. Since the 2.4 binding is based on SSDP events it was working. However, relying on SSDP caused many other issues. Therefore, I based the new version on plain network connectivity. Also, I am not sure, if with the OH abstraction on SSDP / UPNP that I could distinguish between the “hello” and “goodbye” notification. Should really work without it.

So the TV did not properly close the websocket session. The websocket library times out. Which leads to follow up errors, described below.

first case, the websocket client is in a bad state.
second case, binding thinks it is already connecting, therefore does not retry.

Don’t have a solution yet. Just thought I share what I found so far.

Thank you for your comments. Let me know if I can help you.

Olli

Hi, after I updated OH from 2.4 stable release to 2.5.0.M4 I reworked file based lgwebos thing definition which worked fine under 2.4 which was:

Thing lgwebos:WebOSTV:tv1 [ deviceId="215e4288-a709-48d7-b700-159887983ff1" ]

According to current lgwebos binding docu, with updating to OH2.5 I changed to following definition as thing “lgwebos:WebOSTV:5f80e631-ea31-93bf-35ab-ebfda4d33xxx” was found in Paper UI Inbox:

Thing lgwebos:WebOSTV:5f80e631-ea31-93bf-35ab-ebfda4d33abf „OLED55E6V“ [ ]

All my attempts to get thing online resulted in OFFLINE - CONFIGURATION_ERROR Missing parameter “host” . Due to this error message I also tried this – based on binding docu - but without success:

Thing lgwebos:WebOSTV:5f80e631-ea31-93bf-35ab-ebfda4d33abf „OLED55E6V“ [ localIP="192.168.2.201" ]

And - openHAB’s primary IP address is configured under network settings according to binding docu (Paper UI – Configuration – System – Network settings – Primary Address 192.168.2.201/24 [=subnet as required] ).
Below the DEBUG logs:

==> /var/log/openhab2/openhab.log
2019-11-02 19:47:59.984 [DEBUG] [org.openhab.binding.lgwebos         ] - BundleEvent STARTING - org.openhab.binding.lgwebos
2019-11-02 19:48:00.141 [DEBUG] [org.openhab.binding.lgwebos         ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingActions}={service.id=512, service.bundleid=259, service.scope=singleton} - org.openhab.binding.lgwebos
2019-11-02 19:48:00.276 [DEBUG] [org.openhab.binding.lgwebos         ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={service.id=511, service.bundleid=259, service.scope=bundle, component.name=org.openhab.binding.lgwebos.internal.LGWebOSHandlerFactory, component.id=306} - org.openhab.binding.lgwebos
2019-11-02 19:48:00.285 [DEBUG] [org.openhab.binding.lgwebos         ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.upnp.UpnpDiscoveryParticipant}={service.id=513, service.bundleid=259, service.scope=bundle, component.name=org.openhab.binding.lgwebos.internal.discovery.LGWebOSUpnpDiscoveryParticipant, component.id=307} - org.openhab.binding.lgwebos
2019-11-02 19:48:00.289 [DEBUG] [very.LGWebOSUpnpDiscoveryParticipant] - Found LG WebOS TV: (RemoteDevice) Identity: (RemoteDeviceIdentity) UDN: uuid:5f80e631-ea31-93bf-35ab-ebfda4d33abf, Descriptor: http://192.168.2.211:1949/, Root: true
2019-11-02 19:48:00.304 [DEBUG] [discovery.LGWebOSUpnpDiscoverySearch] - Start LGWebOS device background discovery
2019-11-02 19:48:00.313 [DEBUG] [org.openhab.binding.lgwebos         ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=514, service.bundleid=259, service.scope=bundle, component.name=org.openhab.binding.lgwebos.internal.discovery.LGWebOSUpnpDiscoverySearch, component.id=308} - org.openhab.binding.lgwebos
2019-11-02 19:48:00.330 [DEBUG] [org.openhab.binding.lgwebos         ] - BundleEvent STARTED - org.openhab.binding.lgwebos
==> /var/log/openhab2/events.log
2019-11-02 19:48:00.176 [hingStatusInfoChangedEvent] - 'lgwebos:WebOSTV:5f80e631-ea31-93bf-35ab-ebfda4d33abf' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
2019-11-02 19:48:00.205 [hingStatusInfoChangedEvent] - 'lgwebos:WebOSTV:5f80e631-ea31-93bf-35ab-ebfda4d33abf' changed from INITIALIZING to OFFLINE (CONFIGURATION_ERROR): Missing parameter "host"

Could anybody help to “get my thing online”?

My environment: openHAB on Raspberry PI3 with Raspbian Jessie.

Regards,
Andy

Hi @sprehn,

I hope I am posting in the right way, this is my first.

Currently using openhab2 and LG webOS binding version 2.5.0.M4. I have a OLED55B7V with
deviceOSReleaseVersion 3.8.0 and deviceOSVersion 4.1.0.

The binding works very well for me, except I see problems due to the fact that my TV is using external speakers. Whenever the volume is changed on the TV itself, I see the following error in the openhab logs.:

2019-11-03 22:15:05.824 [WARN ] [bos.internal.handler.LGWebOSTVSocket] - Error while processing message: {“type”:“response”,“id”:9,“payload”:{“changed”:[“volume”],“returnValue”:true,“cause”:“volumeDown”,“volumeMax”:100,“scenario”:“mastervolume_ext_speaker_urcu_oss”,“muted”:false,“volume”:-1,“action”:“changed”,“active”:false}} - in response to request: ServiceCommand [requestId=-1, type=subscribe, target=ssap://audio/getVolume, payload=null] - Error Message: Value must be between 0 and 100

Obviously, a trivial issue, but is there anything I should do to fix this problem?

Martin

Thx for reporting.

{“type”:“response”,“id”:9,“payload”:{“changed”:[“volume”],“returnValue”:true,“cause”:“volumeDown”,“volumeMax”:100,“scenario”:“mastervolume_ext_speaker_urcu_oss”,“muted”:false,“volume”:-1,“action”:“changed”,“active”:false}}

It looks like we have to ignore values which are sent back under scenario mastervolume_ext_speaker_urcu_oss

Hi Andy,

Documentation link is for the old version. “localIP” config is gone in this version.
instead use “host” to set the ip of your TV and “key” to set the secret key that is exchanged between both.

Kind Regards
Sebastian

Just FYI, even though the volume is reported as -1, the volume on the external speakers is adjusted. Thank you for responding!

does somebody have this binding working with a TV in another subnet as the opehab server is in?

Sure, the external speakers won’t be affected.
I tried it myself. With my external speakers attached via HDMI ARC

2019-11-07 13:50:21.493 [TRACE] [bos.internal.handler.LGWebOSTVSocket] - Message [in]: {“type”:“response”,“id”:2,“payload”:{“changed”:[“volume”],“returnValue”:true,“cause”:“volumeDown”,“scenario”:“mastervolume_ext_speaker_arc”,“muted”:false,“volume”:0,“action”:“changed”,“active”:false}}

the value reported in “volume” does not make any sense, as the tv has no way of telling what the external receiver or amplifier is set to.

That is why I have not subsribed to this channel in my personal setup.

Without external speakers the message looks like this:

2019-11-07 13:51:07.589 [TRACE] [bos.internal.handler.LGWebOSTVSocket] - Message [in]: {“type”:“response”,“id”:2,“payload”:{“changed”:[“volume”],“returnValue”:true,“cause”:“volumeUp”,“scenario”:“mastervolume_tv_speaker”,“muted”:false,“volume”:5,“action”:“changed”,“active”:false

I will change the binding to only subscribe to “scenario” “mastervolume_tv_speaker”

Ok, this fix is merged to master and should be available in the next snapshot builds

Hi,

noticed that the timeout is very simple to reproduce. No activity for 5mins. But in my case the system will reconnect without issues. My idea to fix this is to generate some small traffic at half the timeout settings rate.

The other issue seems to be the internal state machine, which prevents the system from getting out of state CONNECTING.

I have coded a few changes, but need a bit of time to test them…

Sebastian

@memphiz Olli, pull request got merged. with next snapshot build you could retest. hope this issue you reported is solved now

1 Like

Yes, makes sense. Thanks again!

I just made an update to 1748. I will now observe this for a few days and then give a feedback again.
Thank you very much for your effort.

1 Like

Thank you, Sebastian, for your hint how to configure the webosTV thing. With setting “host” now it is online.
Only I do not know the value to set the secret key. That’s why each time I restart the binding or OH, my TV asks on the screen for approval of connection request. No secret key is shown on my OLED55E6 (webOS 3.34). I do not remember if it was shown when I set up connection the very first time in 2017. Does anybody knows how to find the secret key?
Nevertheless now I use actions for in-/decreasing channel, works perfect. Next I will change my rules to use the other actions.

Regards,
Andy

Hi,

have no access to my setup, so cannot verify…

Whenever you approve the connection request a new key will be generated and sent back to you via the response from tv to openhab. You could actually enable TRACE log level and see it pass over the wire.

An easier way should be to find it in Paper UI.
Once your TV is connected as a thing (after you approved on TV), please check the Thing details in paper ui. Configuration property is called “key”.

Found the key - works.
Thanks @sprehn.

Hi Sebastian,

I found some other issues:
-when I change the volume via RC openhab does not recognize the change. This occours only on my webOS 4.5 TV. webOS 3 seems to work fine.
-channel names and numbers(application livetv) are not recognized by openhab in most cases.

Olli

volume change only makes sense when using internal speakers. just disabled this in all other cases.

will look into channel observation

Thank you so much for the note. In fact, the audio output was set to Internal+Optical