WebOS integration working badly on 0.105

Configuration
1

So I’ve upgraded from 0.104 to 0.105 (now 0.105.2) and my LG WebOS integration is really so poor. Loads and loads of errors and in my logbook I see a lot of status changes while it’s not changed.

afbeelding
afbeelding286×950 4.13 KB

And a lot of errors like these:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/asyncio/tasks.py", line 630, in _wrap_awaitable
    return (yield from awaitable.__await__())
  File "/usr/local/lib/python3.7/site-packages/websockets/client.py", line 547, in __await_impl__
    extra_headers=protocol.extra_headers,
  File "/usr/local/lib/python3.7/site-packages/websockets/client.py", line 290, in handshake
    status_code, response_headers = await self.read_http_response()
  File "/usr/local/lib/python3.7/site-packages/websockets/client.py", line 103, in read_http_response
    raise InvalidMessage("did not receive a valid HTTP response") from exc
websockets.exceptions.InvalidMessage: did not receive a valid HTTP response
2020-02-07 12:58:11 WARNING (MainThread) [homeassistant.helpers.entity] Update of media_player.tv_woonkamer is taking over 10 seconds
2020-02-07 13:00:54 WARNING (MainThread) [homeassistant.helpers.entity] Update of media_player.tv_woonkamer is taking over 10 seconds
2020-02-07 13:17:26 WARNING (MainThread) [homeassistant.helpers.entity] Update of media_player.tv_woonkamer is taking over 10 seconds
2020-02-07 13:22:11 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/websockets/client.py", line 101, in read_http_response
    status_code, reason, headers = await read_response(self.reader)
  File "/usr/local/lib/python3.7/site-packages/websockets/http.py", line 139, in read_response
    status_line = await read_line(stream)
  File "/usr/local/lib/python3.7/site-packages/websockets/http.py", line 213, in read_line
    line = await stream.readline()
  File "/usr/local/lib/python3.7/asyncio/streams.py", line 496, in readline
    line = await self.readuntil(sep)
  File "/usr/local/lib/python3.7/asyncio/streams.py", line 588, in readuntil
    await self._wait_for_data('readuntil')
  File "/usr/local/lib/python3.7/asyncio/streams.py", line 473, in _wait_for_data
    await self._waiter
concurrent.futures._base.CancelledError

This is my configuration:

webostv:
  name: TV woonkamer
  host: 192.168.178.109

My TV has a static IP.

2

I have the same problem, the webos TV status change continuously! anyone with this problem and a solution?

3

I did notice that the log explodes when I shut down the TV via HASS. As long as I don’t do that it seems to work a lot better. It still gives plenty of errors though.

4

What model tv do you have? Is it on wifi or wired? Did 0.104 work correctly and only 0.105 and later are broken?

5

I’ve got a OLED55B7V connected via Wi-Fi. On 0.104 it certainly did not work correct as it had a lot of time out errors ,but it worked miles better then 0.105. Like I said, it works acceptable as long as I don’t turn it off v ia HASS.

6

Is the network connection reliable? (Can you ping the TV from the machine running home assistant with reasonable results?)

Can you tell me whether you have “Quick Start+” enabled in the general settings, and also whether you have “Turn on via wifi” enabled under “Mobile TV On” in general settings? (Exact name and location of these may vary slightly, this is how they’re labeled/located on the C8)

7

Same issues with mine OLED B9 TV.

PS. Same issue is present also on my 2nd webos tv which is older

8

fwiw, i’m not having any issues with this component on my B8 with 0.105.4 - connection is wired

9

Can you please share your config ?

10

No problems here. Does it occur when you call the turn_off service or when you use the remote?
What WebOS version is installed?

I have an 58UH635V with WebOS 3 and its connected via wifi. And the only problems i had were to get the new config running after the changes in 0.104

11

Haven’t checked those settings yet. Not sure what they would mean for power usage when it’s turned off?

Getting less errors these days, but mostly no true information from the TV, so Hass thinks it’s off while it’s turned on. I believe I have WebOS 3 on my OLED TV. I could try to run it wired as it’s via WiFi now. All other devices run perfectly fine with good reception, so I doubt that’s it, unless the WiFi is crap in those TV’s.

12

heres my config:

webostv:
  - host: !secret lg_living_room
    name: Living Room TV
    turn_on_action:
      service: wake_on_lan.send_magic_packet
      data:
        mac: "a8:23:fe:0c:92:af"
    customize:
      sources:
        - youtubetv
        - netflix
13

Yes, those settings definitely both increase power usage when the TV is off, though they have other advantages. I’m not advocating to set them one way or the other, just want to know how you have them set to help diagnose.

It would also be very useful to look at the output of pinging the TV from the machine running home assistant. Also for others having similar issues. It would also be useful information to know if switching to wired solves the issue.

(0.105 reduced some of the connection polling intervals to try to make state changes more responsive in a range of different scenarios, but it’s indeed possible this could cause issues on poor/intermittent connections)

14

Just checked, and Quickstart+ was already turned on, and Turn on by Wifi was off. I turned it on and restarted Hass, but now the status of the TV just goes to on/off and controlling it via Hass seems to have no effect. All other devices on the WiFi have zero issues. I’ll have to get it off my wall to try it via ethernet, should be a better idea anyways, but I’m not sure if it will fix my problems.

15

Having the output of ping from the home assistant machine to the tv when it’s on would be very useful from anyone having issues with it intermittently flipping between states for no reason.
(So far I believe this has only been reported on wifi.)

If the connection quality is poor in a way which can cause such an effect it should be obvious from this output.

On my wired connection it looks like this:

ping 192.168.1.53
PING 192.168.1.53 (192.168.1.53) 56(84) bytes of data.
64 bytes from 192.168.1.53: icmp_seq=1 ttl=64 time=0.205 ms
64 bytes from 192.168.1.53: icmp_seq=2 ttl=64 time=0.288 ms
64 bytes from 192.168.1.53: icmp_seq=3 ttl=64 time=0.241 ms
64 bytes from 192.168.1.53: icmp_seq=4 ttl=64 time=0.195 ms
64 bytes from 192.168.1.53: icmp_seq=5 ttl=64 time=0.281 ms
64 bytes from 192.168.1.53: icmp_seq=6 ttl=64 time=0.292 ms
64 bytes from 192.168.1.53: icmp_seq=7 ttl=64 time=0.249 ms
64 bytes from 192.168.1.53: icmp_seq=8 ttl=64 time=0.239 ms
64 bytes from 192.168.1.53: icmp_seq=9 ttl=64 time=0.224 ms
64 bytes from 192.168.1.53: icmp_seq=10 ttl=64 time=0.241 ms
64 bytes from 192.168.1.53: icmp_seq=11 ttl=64 time=0.301 ms
64 bytes from 192.168.1.53: icmp_seq=12 ttl=64 time=0.235 ms
64 bytes from 192.168.1.53: icmp_seq=13 ttl=64 time=0.297 ms
64 bytes from 192.168.1.53: icmp_seq=14 ttl=64 time=0.222 ms
64 bytes from 192.168.1.53: icmp_seq=15 ttl=64 time=0.253 ms
64 bytes from 192.168.1.53: icmp_seq=16 ttl=64 time=0.216 ms
64 bytes from 192.168.1.53: icmp_seq=17 ttl=64 time=0.320 ms
64 bytes from 192.168.1.53: icmp_seq=18 ttl=64 time=0.246 ms
64 bytes from 192.168.1.53: icmp_seq=19 ttl=64 time=0.199 ms
64 bytes from 192.168.1.53: icmp_seq=20 ttl=64 time=0.218 ms
64 bytes from 192.168.1.53: icmp_seq=21 ttl=64 time=0.253 ms
64 bytes from 192.168.1.53: icmp_seq=22 ttl=64 time=0.232 ms
64 bytes from 192.168.1.53: icmp_seq=23 ttl=64 time=0.290 ms
64 bytes from 192.168.1.53: icmp_seq=24 ttl=64 time=0.272 ms
64 bytes from 192.168.1.53: icmp_seq=25 ttl=64 time=0.231 ms
64 bytes from 192.168.1.53: icmp_seq=26 ttl=64 time=0.267 ms
64 bytes from 192.168.1.53: icmp_seq=27 ttl=64 time=0.227 ms
64 bytes from 192.168.1.53: icmp_seq=28 ttl=64 time=0.224 ms
64 bytes from 192.168.1.53: icmp_seq=29 ttl=64 time=0.247 ms
64 bytes from 192.168.1.53: icmp_seq=30 ttl=64 time=0.233 ms
64 bytes from 192.168.1.53: icmp_seq=31 ttl=64 time=0.219 ms
64 bytes from 192.168.1.53: icmp_seq=32 ttl=64 time=0.202 ms
64 bytes from 192.168.1.53: icmp_seq=33 ttl=64 time=0.249 ms
64 bytes from 192.168.1.53: icmp_seq=34 ttl=64 time=0.221 ms
16

I’d have to check that tonight.

In even worse news, I had to disable the component in my install completely because it was causing my TV to misbehave. It kept saying it had to restart the current app to make space. It was just on regular TV so nothing special. It kept restarting the TV ‘app’ every few seconds, and as soon as I restarted Hass without the component it was working normally again. So not sure what’s going on here…

17

(Sounds like a memory leak in the TV firmware which is being provoked by the continuous connect/disconnect somehow.)

18

For what it’s worth, similar output for me on wifi (where I don’t have any connection drop/state change issues)

ping 192.168.1.191
PING 192.168.1.191 (192.168.1.191) 56(84) bytes of data.
64 bytes from 192.168.1.191: icmp_seq=1 ttl=64 time=1.72 ms
64 bytes from 192.168.1.191: icmp_seq=2 ttl=64 time=2.42 ms
64 bytes from 192.168.1.191: icmp_seq=3 ttl=64 time=2.32 ms
64 bytes from 192.168.1.191: icmp_seq=4 ttl=64 time=2.46 ms
64 bytes from 192.168.1.191: icmp_seq=5 ttl=64 time=2.32 ms
64 bytes from 192.168.1.191: icmp_seq=6 ttl=64 time=3.02 ms
64 bytes from 192.168.1.191: icmp_seq=7 ttl=64 time=2.46 ms
64 bytes from 192.168.1.191: icmp_seq=8 ttl=64 time=2.29 ms
64 bytes from 192.168.1.191: icmp_seq=9 ttl=64 time=2.32 ms
64 bytes from 192.168.1.191: icmp_seq=10 ttl=64 time=1.40 ms
64 bytes from 192.168.1.191: icmp_seq=11 ttl=64 time=2.37 ms
64 bytes from 192.168.1.191: icmp_seq=12 ttl=64 time=2.36 ms
64 bytes from 192.168.1.191: icmp_seq=13 ttl=64 time=2.47 ms
64 bytes from 192.168.1.191: icmp_seq=14 ttl=64 time=2.64 ms
64 bytes from 192.168.1.191: icmp_seq=15 ttl=64 time=2.51 ms
64 bytes from 192.168.1.191: icmp_seq=16 ttl=64 time=2.33 ms
64 bytes from 192.168.1.191: icmp_seq=17 ttl=64 time=2.37 ms
64 bytes from 192.168.1.191: icmp_seq=18 ttl=64 time=2.40 ms
64 bytes from 192.168.1.191: icmp_seq=19 ttl=64 time=2.35 ms
64 bytes from 192.168.1.191: icmp_seq=20 ttl=64 time=2.40 ms
64 bytes from 192.168.1.191: icmp_seq=21 ttl=64 time=1.46 ms
64 bytes from 192.168.1.191: icmp_seq=22 ttl=64 time=2.52 ms
64 bytes from 192.168.1.191: icmp_seq=23 ttl=64 time=2.39 ms
64 bytes from 192.168.1.191: icmp_seq=24 ttl=64 time=1.36 ms
64 bytes from 192.168.1.191: icmp_seq=25 ttl=64 time=1.33 ms
64 bytes from 192.168.1.191: icmp_seq=26 ttl=64 time=1.31 ms
19

Any news here? I have exactly the same issues with my LG OLED55C8LLA which doesn’t show the correct status anymore in HA. I’m running 106.6.
The log says:

Integration: Media player ([documentation](https://www.home-assistant.io/integrations/media_player), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+media_player%22))
First occured: 5:09:49 PM (53 occurences)
Last logged: 5:25:17 PM

Updating webostv media_player took longer than the scheduled update interval 0:00:10

Connection lost. Reconnecting…

My config is quite simple:

webostv:
  host: 192.168.178.33
  name: LG WebOS Smart TV

Ping to the TV works without any problems and I didn’t change any settings on it.

20

Are you on wifi or wired? Can you actually post the output of ping as above?