Core: Unstable WebOS integration

[jacekpaszkowski]

The problem

It's first time i've tried using webos integration and it seems to unstable. Often media_player entity has 'off' state but my tv is phisically turned on. There are also erros in log.
TV and RPi is connected via cable, my WebOS version is 04.71.25.

TV was constantly on for last 1,5 hours but state changes very often

Environment

• Home Assistant Core release with the issue: 0.107.7
• Last working Home Assistant Core release (if known): ?
• Operating environment (Home Assistant/Supervised/Docker/venv): Hass.io
• Integration causing this issue: webos
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/webostv/

Problem-relevant configuration.yaml

webostv:
  host: !secret lg_tv_ip
  name: 'Living room LG TV'
  turn_on_action:
    service: wake_on_lan.send_magic_packet
    data:
      mac: "XX:XX:XX:XX:XX:XX"

Traceback/Error logs

2020-04-02 16:38:55 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/aiopylgtv/webos_client.py", line 373, in consumer_handler
    while not closeout_task.done():
UnboundLocalError: local variable 'closeout_task' referenced before assignment

2020-04-02 16:41:00 WARNING (MainThread) [homeassistant.components.media_player] Updating webostv media_player took longer than the scheduled update interval 0:00:10
2020-04-02 16:41:11 WARNING (MainThread) [homeassistant.components.media_player] Updating webostv media_player took longer than the scheduled update interval 0:00:10
2020-04-02 16:41:22 WARNING (MainThread) [homeassistant.components.media_player] Updating webostv media_player took longer than the scheduled update interval 0:00:10
2020-04-02 16:41:45 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/aiopylgtv/webos_client.py", line 373, in consumer_handler
    while not closeout_task.done():
UnboundLocalError: local variable 'closeout_task' referenced before assignment

Additional information

[probot-home-assistant[bot]]

Hey there @bendavid, mind taking a look at this issue as its been labeled with a integration (webostv) you are listed as a codeowner for? Thanks!

[bendavid]

This has been discussed in the forums here
https://community.home-assistant.io/t/webos-integration-working-badly-on-0-105/169787

Please post the output of "ping" from your home assistant machine to the tv to confirm whether you have a stable network connection.

[jacekpaszkowski]

Hmm, some packets are missing?

PING LGwebOSTV.lan (192.168.1.22): 56 data bytes
64 bytes from 192.168.1.22: seq=1 ttl=64 time=2.985 ms
64 bytes from 192.168.1.22: seq=8 ttl=64 time=0.463 ms
64 bytes from 192.168.1.22: seq=11 ttl=64 time=1.339 ms
64 bytes from 192.168.1.22: seq=12 ttl=64 time=3.569 ms
64 bytes from 192.168.1.22: seq=17 ttl=64 time=0.509 ms
64 bytes from 192.168.1.22: seq=18 ttl=64 time=0.454 ms
64 bytes from 192.168.1.22: seq=21 ttl=64 time=4.475 ms
64 bytes from 192.168.1.22: seq=24 ttl=64 time=0.442 ms
64 bytes from 192.168.1.22: seq=25 ttl=64 time=0.572 ms
64 bytes from 192.168.1.22: seq=26 ttl=64 time=0.558 ms
64 bytes from 192.168.1.22: seq=27 ttl=64 time=3.697 ms
64 bytes from 192.168.1.22: seq=28 ttl=64 time=3.003 ms
64 bytes from 192.168.1.22: seq=30 ttl=64 time=0.638 ms
64 bytes from 192.168.1.22: seq=34 ttl=64 time=1.324 ms
64 bytes from 192.168.1.22: seq=40 ttl=64 time=2.354 ms
64 bytes from 192.168.1.22: seq=41 ttl=64 time=0.451 ms
64 bytes from 192.168.1.22: seq=42 ttl=64 time=1.958 ms
64 bytes from 192.168.1.22: seq=44 ttl=64 time=2.922 ms
64 bytes from 192.168.1.22: seq=48 ttl=64 time=4.057 ms
64 bytes from 192.168.1.22: seq=49 ttl=64 time=1.554 ms
64 bytes from 192.168.1.22: seq=53 ttl=64 time=0.697 ms
64 bytes from 192.168.1.22: seq=55 ttl=64 time=0.520 ms
64 bytes from 192.168.1.22: seq=57 ttl=64 time=0.516 ms

and ping to my NAS - looks more stable

PING animus-nas.lan (192.168.1.20): 56 data bytes
64 bytes from 192.168.1.20: seq=0 ttl=64 time=1.052 ms
64 bytes from 192.168.1.20: seq=1 ttl=64 time=0.357 ms
64 bytes from 192.168.1.20: seq=2 ttl=64 time=0.572 ms
64 bytes from 192.168.1.20: seq=3 ttl=64 time=0.283 ms
64 bytes from 192.168.1.20: seq=4 ttl=64 time=0.684 ms
64 bytes from 192.168.1.20: seq=5 ttl=64 time=0.478 ms
64 bytes from 192.168.1.20: seq=6 ttl=64 time=0.333 ms
64 bytes from 192.168.1.20: seq=7 ttl=64 time=0.402 ms
64 bytes from 192.168.1.20: seq=8 ttl=64 time=0.586 ms
64 bytes from 192.168.1.20: seq=9 ttl=64 time=0.423 ms
64 bytes from 192.168.1.20: seq=10 ttl=64 time=0.395 ms
64 bytes from 192.168.1.20: seq=11 ttl=64 time=0.477 ms
64 bytes from 192.168.1.20: seq=12 ttl=64 time=0.373 ms
64 bytes from 192.168.1.20: seq=13 ttl=64 time=0.339 ms
64 bytes from 192.168.1.20: seq=14 ttl=64 time=0.384 ms
64 bytes from 192.168.1.20: seq=15 ttl=64 time=0.366 ms
64 bytes from 192.168.1.20: seq=16 ttl=64 time=0.686 ms
64 bytes from 192.168.1.20: seq=17 ttl=64 time=0.685 ms
64 bytes from 192.168.1.20: seq=18 ttl=64 time=0.558 ms
64 bytes from 192.168.1.20: seq=19 ttl=64 time=0.712 ms
64 bytes from 192.168.1.20: seq=20 ttl=64 time=0.498 ms
64 bytes from 192.168.1.20: seq=21 ttl=64 time=0.396 ms
64 bytes from 192.168.1.20: seq=22 ttl=64 time=0.479 ms
64 bytes from 192.168.1.20: seq=23 ttl=64 time=0.546 ms
64 bytes from 192.168.1.20: seq=24 ttl=64 time=0.398 ms
64 bytes from 192.168.1.20: seq=25 ttl=64 time=0.351 ms

[bendavid]

There is also a small bug in the error handling in aiopylgtv here which I'll fix, but the underlying cause of the issue is probably the packet loss.
(The websocket library is effectively pinging repeatedly and will drop the connection if this fails.)

[jacekpaszkowski]

:( so do you have any idea what is the cause of this issue? Why the packets are dorpped? It has been working more stable in previous versions of HA or WebOS?

[bendavid]

Older versions did not attempt to keep track of the TV state in real time, did not have persistent connections, etc, so would have been much less sensitive to poor connections.

The NAS and the TV are connected to the same ethernet switch? Try a different ethernet cable to the TV if you have one?

[jacekpaszkowski]

some more tests.

ping TV from my router:

root@OpenWrt:~# ping -c 20 LGwebOSTV.lan
PING LGwebOSTV.lan (192.168.1.22): 56 data bytes
64 bytes from 192.168.1.22: seq=0 ttl=64 time=4.085 ms
64 bytes from 192.168.1.22: seq=1 ttl=64 time=0.465 ms
64 bytes from 192.168.1.22: seq=2 ttl=64 time=3.080 ms
64 bytes from 192.168.1.22: seq=3 ttl=64 time=2.383 ms
64 bytes from 192.168.1.22: seq=4 ttl=64 time=2.529 ms
64 bytes from 192.168.1.22: seq=5 ttl=64 time=5.203 ms
64 bytes from 192.168.1.22: seq=6 ttl=64 time=0.509 ms
64 bytes from 192.168.1.22: seq=7 ttl=64 time=0.481 ms
64 bytes from 192.168.1.22: seq=8 ttl=64 time=2.575 ms
64 bytes from 192.168.1.22: seq=9 ttl=64 time=0.556 ms
64 bytes from 192.168.1.22: seq=10 ttl=64 time=0.487 ms
64 bytes from 192.168.1.22: seq=11 ttl=64 time=0.441 ms
64 bytes from 192.168.1.22: seq=12 ttl=64 time=3.015 ms
64 bytes from 192.168.1.22: seq=13 ttl=64 time=0.550 ms
64 bytes from 192.168.1.22: seq=14 ttl=64 time=0.480 ms
64 bytes from 192.168.1.22: seq=15 ttl=64 time=0.534 ms
64 bytes from 192.168.1.22: seq=16 ttl=64 time=0.488 ms
64 bytes from 192.168.1.22: seq=17 ttl=64 time=4.053 ms
64 bytes from 192.168.1.22: seq=18 ttl=64 time=3.213 ms
64 bytes from 192.168.1.22: seq=19 ttl=64 time=0.626 ms

ping hassio from router:

root@OpenWrt:~# ping -c 20 hassio-master.lan
PING hassio-master.lan (192.168.1.245): 56 data bytes
64 bytes from 192.168.1.245: seq=0 ttl=64 time=5.776 ms
64 bytes from 192.168.1.245: seq=1 ttl=64 time=6.519 ms
64 bytes from 192.168.1.245: seq=2 ttl=64 time=6.485 ms
64 bytes from 192.168.1.245: seq=3 ttl=64 time=8.802 ms
64 bytes from 192.168.1.245: seq=4 ttl=64 time=8.795 ms
64 bytes from 192.168.1.245: seq=5 ttl=64 time=7.194 ms
64 bytes from 192.168.1.245: seq=6 ttl=64 time=1.120 ms
64 bytes from 192.168.1.245: seq=7 ttl=64 time=0.760 ms
64 bytes from 192.168.1.245: seq=8 ttl=64 time=8.614 ms
64 bytes from 192.168.1.245: seq=9 ttl=64 time=4.446 ms
64 bytes from 192.168.1.245: seq=10 ttl=64 time=5.874 ms
64 bytes from 192.168.1.245: seq=11 ttl=64 time=5.172 ms
64 bytes from 192.168.1.245: seq=12 ttl=64 time=0.753 ms
64 bytes from 192.168.1.245: seq=13 ttl=64 time=6.513 ms
64 bytes from 192.168.1.245: seq=14 ttl=64 time=0.852 ms
64 bytes from 192.168.1.245: seq=15 ttl=64 time=0.684 ms
64 bytes from 192.168.1.245: seq=16 ttl=64 time=3.487 ms
64 bytes from 192.168.1.245: seq=17 ttl=64 time=5.257 ms
64 bytes from 192.168.1.245: seq=18 ttl=64 time=6.285 ms
64 bytes from 192.168.1.245: seq=19 ttl=64 time=3.603 ms

and again ping from hassio to tv

➜  ~ ping -c 20 LGwebOSTV.lan
PING LGwebOSTV.lan (192.168.1.22): 56 data bytes
64 bytes from 192.168.1.22: seq=1 ttl=64 time=0.569 ms
64 bytes from 192.168.1.22: seq=2 ttl=64 time=2.752 ms
64 bytes from 192.168.1.22: seq=3 ttl=64 time=0.449 ms
64 bytes from 192.168.1.22: seq=5 ttl=64 time=3.600 ms
64 bytes from 192.168.1.22: seq=6 ttl=64 time=2.765 ms
64 bytes from 192.168.1.22: seq=8 ttl=64 time=3.988 ms
64 bytes from 192.168.1.22: seq=9 ttl=64 time=0.526 ms
64 bytes from 192.168.1.22: seq=15 ttl=64 time=4.800 ms
64 bytes from 192.168.1.22: seq=16 ttl=64 time=2.413 ms
64 bytes from 192.168.1.22: seq=19 ttl=64 time=2.936 ms

I don't experience any network issues in my network, also on tv i can smoothly play 4K video from Netflix etc.

[jacekpaszkowski]

also no problem from my PC

Pinging 192.168.1.22 with 32 bytes of data:
Reply from 192.168.1.22: bytes=32 time=1ms TTL=64
Reply from 192.168.1.22: bytes=32 time=1ms TTL=64
Reply from 192.168.1.22: bytes=32 time=2ms TTL=64
Reply from 192.168.1.22: bytes=32 time=4ms TTL=64
Reply from 192.168.1.22: bytes=32 time=4ms TTL=64
Reply from 192.168.1.22: bytes=32 time=4ms TTL=64
Reply from 192.168.1.22: bytes=32 time=3ms TTL=64
Reply from 192.168.1.22: bytes=32 time=4ms TTL=64
Reply from 192.168.1.22: bytes=32 time=7ms TTL=64
Reply from 192.168.1.22: bytes=32 time=1ms TTL=64
Reply from 192.168.1.22: bytes=32 time=2ms TTL=64
Reply from 192.168.1.22: bytes=32 time=3ms TTL=64
Reply from 192.168.1.22: bytes=32 time=5ms TTL=64
Reply from 192.168.1.22: bytes=32 time=3ms TTL=64
Reply from 192.168.1.22: bytes=32 time=5ms TTL=64
Reply from 192.168.1.22: bytes=32 time=2ms TTL=64
Reply from 192.168.1.22: bytes=32 time=3ms TTL=64
Reply from 192.168.1.22: bytes=32 time=8ms TTL=64
Reply from 192.168.1.22: bytes=32 time=1ms TTL=64
Reply from 192.168.1.22: bytes=32 time=8ms TTL=64

Ping statistics for 192.168.1.22:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 8ms, Average = 3ms

also no drops when pinging router from my hassio

➜  ~ ping -c 20 openwrt.lan
PING openwrt.lan (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=1.122 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=3.526 ms
64 bytes from 192.168.1.1: seq=2 ttl=64 time=4.492 ms
64 bytes from 192.168.1.1: seq=3 ttl=64 time=6.977 ms
64 bytes from 192.168.1.1: seq=4 ttl=64 time=6.263 ms
64 bytes from 192.168.1.1: seq=5 ttl=64 time=6.238 ms
64 bytes from 192.168.1.1: seq=6 ttl=64 time=4.096 ms
64 bytes from 192.168.1.1: seq=7 ttl=64 time=0.802 ms
64 bytes from 192.168.1.1: seq=8 ttl=64 time=3.102 ms
64 bytes from 192.168.1.1: seq=9 ttl=64 time=5.766 ms
64 bytes from 192.168.1.1: seq=10 ttl=64 time=4.226 ms
64 bytes from 192.168.1.1: seq=11 ttl=64 time=6.309 ms
64 bytes from 192.168.1.1: seq=12 ttl=64 time=3.793 ms
64 bytes from 192.168.1.1: seq=13 ttl=64 time=6.979 ms
64 bytes from 192.168.1.1: seq=14 ttl=64 time=5.753 ms
64 bytes from 192.168.1.1: seq=15 ttl=64 time=5.139 ms
64 bytes from 192.168.1.1: seq=16 ttl=64 time=4.110 ms
64 bytes from 192.168.1.1: seq=17 ttl=64 time=7.499 ms
64 bytes from 192.168.1.1: seq=18 ttl=64 time=4.051 ms
64 bytes from 192.168.1.1: seq=19 ttl=64 time=3.836 ms

[jacekpaszkowski]

i've tried another cable and no change

➜  ~ ping -c 20 LGwebOSTV.lan
PING LGwebOSTV.lan (192.168.1.22): 56 data bytes
64 bytes from 192.168.1.22: seq=0 ttl=64 time=0.757 ms
64 bytes from 192.168.1.22: seq=1 ttl=64 time=0.467 ms
64 bytes from 192.168.1.22: seq=2 ttl=64 time=2.711 ms
64 bytes from 192.168.1.22: seq=3 ttl=64 time=2.804 ms
64 bytes from 192.168.1.22: seq=8 ttl=64 time=1.573 ms
64 bytes from 192.168.1.22: seq=10 ttl=64 time=0.657 ms
64 bytes from 192.168.1.22: seq=12 ttl=64 time=0.440 ms
64 bytes from 192.168.1.22: seq=14 ttl=64 time=2.561 ms
64 bytes from 192.168.1.22: seq=16 ttl=64 time=0.460 ms
64 bytes from 192.168.1.22: seq=17 ttl=64 time=0.460 ms
64 bytes from 192.168.1.22: seq=18 ttl=64 time=1.032 ms

random packets drops

[bendavid]

What does the network topology look like? Hassio and TV are connected directly to the same switch? (The switch is the one built in to the router?)

[jacekpaszkowski]

TV is connected directly to the router, i have also have a switch and hassio and NAS are connected to that switch.

Now i've made yet another test and disabled webostv platform in my configuration. and now ping works ok!

➜  ~ ping -c 20 LGwebOSTV.lan
PING LGwebOSTV.lan (192.168.1.22): 56 data bytes
64 bytes from 192.168.1.22: seq=0 ttl=64 time=0.469 ms
64 bytes from 192.168.1.22: seq=1 ttl=64 time=0.479 ms
64 bytes from 192.168.1.22: seq=2 ttl=64 time=0.452 ms
64 bytes from 192.168.1.22: seq=3 ttl=64 time=0.454 ms
64 bytes from 192.168.1.22: seq=4 ttl=64 time=0.377 ms
64 bytes from 192.168.1.22: seq=5 ttl=64 time=0.479 ms
64 bytes from 192.168.1.22: seq=6 ttl=64 time=0.512 ms
64 bytes from 192.168.1.22: seq=7 ttl=64 time=0.450 ms
64 bytes from 192.168.1.22: seq=8 ttl=64 time=0.482 ms
64 bytes from 192.168.1.22: seq=9 ttl=64 time=0.465 ms
64 bytes from 192.168.1.22: seq=10 ttl=64 time=0.616 ms
64 bytes from 192.168.1.22: seq=11 ttl=64 time=0.470 ms
64 bytes from 192.168.1.22: seq=12 ttl=64 time=0.529 ms
64 bytes from 192.168.1.22: seq=13 ttl=64 time=0.528 ms
64 bytes from 192.168.1.22: seq=14 ttl=64 time=0.491 ms
64 bytes from 192.168.1.22: seq=15 ttl=64 time=0.476 ms
64 bytes from 192.168.1.22: seq=16 ttl=64 time=0.423 ms
64 bytes from 192.168.1.22: seq=17 ttl=64 time=0.583 ms
64 bytes from 192.168.1.22: seq=18 ttl=64 time=0.460 ms
64 bytes from 192.168.1.22: seq=19 ttl=64 time=0.672 ms

so maybe TV block connection when there is to many requests?

[jacekpaszkowski]

I've made some debugging and setup again webostv integration, restarted TV couple of times and now it looks that it works more predictable.
But still each 4-5 minutes state of media_player goes 'off' for ~15 sec.
When state goes off there are also missing ping packets. After 5-10 missed packets ping back to work and then after couple of seconds media_player state goes back to 'on'.
I think state and ping problem occurs when line 210 in media_player.py is executed:

await self._client.connect()

[jacekpaszkowski]

Well, i'm not sure if direct use of self._client.is_on (direct call to external evice) inside state property is valid. As far as i know HA dev docs it is not recommended. I've made some changes locally and now component works more stable.

I've added new variable in init()

self._state = None

variable is updated at the end of async_update()

if self._client.is_on:
    self._state = STATE_ON
else:
    self._state = STATE_OFF

and state property just:

return self._state

What do you think?

[bendavid]

_client.is_on does not have any call to the external device. The copying of state in async_update should not be needed since this should be handled by the asynchronous callbacks. There is a bug at https://github.com/bendavid/aiopylgtv/blob/dd913365ddeba210597411f6a0a75587ab822a42/aiopylgtv/webos_client.py#L370-L377 which I will fix (closeout_task can be uninitialized) and this would rather be the proper fix to ensuring that STATE_OFF is propagated to home assistant when the client disconnects from the TV, but the underlying problem of course is that the connection is unstable and the client is randomly disconnecting.

[jacekpaszkowski]

Ok, thank you for the clarification. Looking forward for the fix in aiopylgtv :)

[jacekpaszkowski]

Off topic question but maybe you can tell me if it is possible to connect to specific BT device using webos.select_sound_output servic. I'm only able to switch source to bt_soundbar but soundbar doesn't connect. I know there are open issiues at LG forums about automatic BT connection.
https://lgcommunity.us.com/discussion/619/bluetooth-never-auto-connects-to-paired-devices

Thanks

[jacekpaszkowski]

Today integration suddenly stopped working. For last 4 hours the entity havn't beed updated.
I've addes some additional logging and it seems that it hangs at line await self._client.connect()

After restart works.

[pandanz]

I am having the same issue as jacekpaszkowski. Reboot fixes it but then it stops working again after a few hours. No packet loss.

[camochu]

Same problem here. After HA reboot tv works OK, but after same hours my tv usually is not accessible and I need to reboot HA again. TV always had some packet loss because it's connected through PLC's. I'm not sure what version of HA starts to present the issue

[isk0001y]

I found out that power_state is turning into None pretty quick.

this seems to be a result from one of these 2 conditions:

• from self.connection being None, leading to the Not Connected exception, and get_power_state being None
• the payload being simply None, just because the universe had a different opinion on that.

I managed the necessary stability by

• Not considering None as "Off"
• Not setting self.connection and self.input_connection to None in the finally-block of the connect_handler method.

Maybe you want to consider?

[jacekpaszkowski]

My important conclusion after a few days of various tests.

I had no ideas what the problem might be and I tried to use the new switch. Now there is big difference it's much more stable. It's weird because I haven't noticed other problems on my network so far. However, now "ping" to my tv is also stable.

[isk0001y]

I still think that the webos_client.py seems to have 1-2 bugs that I tried to point at...

[kerorek]

I am having this exact issue, which only started after a recent upgrade. Further, I ran 400 pings to my LG TV and did not drop a single one.

---

64 bytes from 192.168.1.98: icmp_seq=401 ttl=64 time=6.02 ms
64 bytes from 192.168.1.98: icmp_seq=402 ttl=64 time=5.35 ms
64 bytes from 192.168.1.98: icmp_seq=403 ttl=64 time=6.23 ms
64 bytes from 192.168.1.98: icmp_seq=404 ttl=64 time=6.68 ms
64 bytes from 192.168.1.98: icmp_seq=405 ttl=64 time=5.62 ms
^C
--- 192.168.1.98 ping statistics ---
405 packets transmitted, 405 received, 0% packet loss, time 404598ms
rtt min/avg/max/mdev = 4.106/5.859/11.733/1.226 ms
[hass@testhoose ~]#

Any suggestions for those seeing the issue without underlying network problems?

[bendavid]

I found out that power_state is turning into None pretty quick.

this seems to be a result from one of these 2 conditions:

• from self.connection being None, leading to the Not Connected exception, and get_power_state being None
• the payload being simply None, just because the universe had a different opinion on that.

I managed the necessary stability by

• Not considering None as "Off"
• Not setting self.connection and self.input_connection to None in the finally-block of the connect_handler method.

Maybe you want to consider?

There IS a bug in the disconnect handling as I pointed to earlier, and which I will get around to fixing, but this is NOT going to solve the underlying issue if you're suffering from random disconnects, only make the integration handle them more gracefully.

The specific changes you're proposing essentially amount to having the client library ignore a disconnect, which is not the right thing to do.

[isk0001y]

I still wonder why you would set a connection to None even in success case, because finally will always set it to None; making other methods fail
Am I wrong?

[bendavid]

The finally black of the connect_handler method is handling the disconnection of a connection. While the connection is open, that coroutine waits here
https://github.com/bendavid/aiopylgtv/blob/1d7e9cc7a5a85b59e1ab588ab0e9cfdf8864197f/aiopylgtv/webos_client.py#L265

Or are you referring to somewhere else that the connection is set to None?

[Giancky79]

hi, after update di HA 110.2, webostv have same problem of disconnection

[dusankeprta]

Well , I have the same issue as Jacek , occurs every couple seconds , HA status of tv device is going from off/on to on/off , similar picture depicted by Jacek.

[dusankeprta]

[pandanz]

any update on this issue? It is still happening with 0.114.1

[jacekpaszkowski]

To honest, for me after "fixing" my local network problems it works well and stable.

[logan893]

The code in aiopylgtv which this integration is based on could be made more robust. A single failed ping while the TV is on will show as a power-off event in Home Assistant.

I made some modifications to add re-try functionality, which makes it more robust. The ping itself doesn't seem critical for operations.
https://github.com/home-assistant/core/issues/36508#issuecomment-695802164

[FransTwisk]

I'm experiencing the exact same thing on my LG55B6V WebOS tv. Home Assistant randomly sets the TV to status 'off' even when it's simply not. TV is connected using WiFi, might try LAN soon, because automations are now being triggered while they shouldn't.