LG webOS TV automations fails after updating to 2025.11; entities are now 'unavailable' (they were 'off' in previous HA versions)

[bravespirit84]

If you are affected by this issue you are missing an automation to turn on the TV, follow https://www.home-assistant.io/integrations/webostv#turn-on-automation-trigger to create an automation, most commons ones are using WOL (which you probably used before just with a custom component)

The problem

Hello, I just updated HA to 2025.11 and since the update both my LG screens fails to work with HA anymore. They were just fine prior the update.

Reloading the integration seems to fix the issue for a few seconds, then both devices go back to 'unavailable'.

Logs under System \ Logs show:

Logger: frontend.js.modern.202511050
Source: components/system_log/__init__.py:331
First occurred: 15:51:32 (4 occurrences)
Last logged: 18:00:12
Uncaught error from Firefox 144.0 on Windows 10 Error: Failed to execute 'define' on 'CustomElementRegistry': the name "lg-remote-control-editor" has already been used with this registry 68965/</A.prototype.define (node_modules/@webcomponents/scoped-custom-element-registry/src/scoped-custom-element-registry.ts:180:12) ct/< (/hacsfiles/LG-WebOS-Remote-Control/lg-remote-control.js:30:100) t (/hacsfiles/LG-WebOS-Remote-Control/lg-remote-control.js:1:250) /hacsfiles/LG-WebOS-Remote-Control/lg-remote-control.js:272:27

What version of Home Assistant Core has the issue?

core-2025.11.0

What was the last working version of Home Assistant Core?

core-2025.10.4

What type of installation are you running?

Home Assistant OS

Integration causing the issue

webostv

Link to integration documentation on our website

https://www.home-assistant.io/integrations/webostv/

Diagnostics information

Logger: frontend.js.modern.202511050
Source: components/system_log/init.py:331
First occurred: 15:51:32 (4 occurrences)
Last logged: 18:00:12
Uncaught error from Firefox 144.0 on Windows 10 Error: Failed to execute 'define' on 'CustomElementRegistry': the name "lg-remote-control-editor" has already been used with this registry 68965/</A.prototype.define (node_modules/@webcomponents/scoped-custom-element-registry/src/scoped-custom-element-registry.ts:180:12) ct/< (/hacsfiles/LG-WebOS-Remote-Control/lg-remote-control.js:30:100) t (/hacsfiles/LG-WebOS-Remote-Control/lg-remote-control.js:1:250) /hacsfiles/LG-WebOS-Remote-Control/lg-remote-control.js:272:27

Example YAML snippet

Anything in the logs that might be useful for us?

I've read the release notes of 2025.11 "The state of LG webOS TV media player entities that do not have an automation trigger to turn on the device will be set to unavailable instead of off."
I do have a script tho, that handles powering on/off one of the two devices. It still shows as unavailable with the newest update.

I dot NOT have an automation for powering the second device, as I've been using a simple 'button' with wake-on-lan to turn it on.

Do I really need to create bogus automations just to circumvent this issue? It seems overkilling to me and I do not understand the logic for marking the devices 'unavailable' now, instead of 'off'

Additional information

No response

[home-assistant]

Hey there @thecode, mind taking a look at this issue as it has been labeled with an integration (webostv) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of webostv can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign webostv Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

webostv documentation
webostv source
_{^{(message by IssueLinks)}}

[bravespirit84]

In addition to my previous comment, I can't even create a bogus automation as I am given no actions:

[teymur1988]

Hi there

I updated to 2025.11 last night and I have exactly the same issue. My 3 LgWebOS TVs now show unavailable when off, and I always used a script in HA that sends WOL to their MAC to turn them on. What's the workaround for this now? Creating an automation? Would you please be so kind provide an example? What should be triggering it? As per the integration docs there is an action called webostv.turn_on to turn the TV on, however I do not see that in my list of actions:

What do we do with this?

Regards

Teymur

[thecode]

In addition to my previous comment, I can't even create a bogus automation as I am given no actions:

There is a typo in the docs (I didn't notice it until now), it is an automation trigger not an action, on the same place you are now use the Trigger to select the device and the Device requested to turn on

[thecode]

@bravespirit84 you are mixing to issues which are not related, the error in the issue topic and your description is related to a custom element not related this repo, there is already an issue for it upstream madmicio/LG-WebOS-Remote-Control#164

For the other, see my previous reply, you don't need to create a fake automation, just link the button you have today to the media player using the device requested to turn on automation trigger, this will make the media player turn on button (or action) to actually call your custom button.

[teymur1988]

In addition to my previous comment, I can't even create a bogus automation as I am given no actions:

There is a typo in the docs (I didn't notice it until now), it is an automation trigger not an action, on the same place you are now use the Trigger to select the device and the Device requested to turn on

Thank you. I've got mine working now.

[etakpte]

Hi @thecode ,

It seems i have the same issue. WebOS TV becomes unavailable after 10s since i am on 2025.11.

�[36m2025-11-06 14:51:52.148 DEBUG (MainThread) [aiowebostv] connect(192.168.31.113): uri: ws://192.168.31.113:3000, max_msg_size: 8388608�[0m
�[36m2025-11-06 14:51:52.218 DEBUG (MainThread) [aiowebostv] connect(192.168.31.113): uri: wss://192.168.31.113:3001, max_msg_size: 8388608�[0m
�[36m2025-11-06 14:51:52.337 DEBUG (MainThread) [aiowebostv] send(192.168.31.113): hello�[0m
�[36m2025-11-06 14:51:52.344 DEBUG (MainThread) [aiowebostv] exception(192.168.31.113): WSMessageTypeError('Received message 8:1008 is not WSMsgType.TEXT')
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/aiowebostv/webos_client.py", line 358, in connect_handler
    await self._get_hello_info(main_ws)
  File "/usr/local/lib/python3.13/site-packages/aiowebostv/webos_client.py", line 189, in _get_hello_info
    response = await ws.receive_json()
               ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/client_ws.py", line 407, in receive_json
    data = await self.receive_str(timeout=timeout)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/client_ws.py", line 388, in receive_str
    raise WSMessageTypeError(
        f"Received message {msg.type}:{msg.data!r} is not WSMsgType.TEXT"
    )
aiohttp.client_exceptions.WSMessageTypeError: Received message 8:1008 is not WSMsgType.TEXT�[0m
�[36m2025-11-06 14:51:54.862 DEBUG (MainThread) [aiowebostv] disconnect(192.168.31.113): already disconnected�[0m
�[36m2025-11-06 14:51:54.865 DEBUG (MainThread) [aiowebostv] connect(192.168.31.113): uri: ws://192.168.31.113:3000, max_msg_size: 8388608�[0m
�[36m2025-11-06 14:51:54.898 DEBUG (MainThread) [aiowebostv] connect(192.168.31.113): uri: wss://192.168.31.113:3001, max_msg_size: 8388608�[0m
�[36m2025-11-06 14:51:55.078 DEBUG (MainThread) [aiowebostv] send(192.168.31.113): hello�[0m
�[36m2025-11-06 14:51:55.098 DEBUG (MainThread) [aiowebostv] exception(192.168.31.113): WSMessageTypeError('Received message 8:1008 is not WSMsgType.TEXT')
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/aiowebostv/webos_client.py", line 358, in connect_handler
    await self._get_hello_info(main_ws)
  File "/usr/local/lib/python3.13/site-packages/aiowebostv/webos_client.py", line 189, in _get_hello_info
    response = await ws.receive_json()
               ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/client_ws.py", line 407, in receive_json
    data = await self.receive_str(timeout=timeout)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/client_ws.py", line 388, in receive_str
    raise WSMessageTypeError(
        f"Received message {msg.type}:{msg.data!r} is not WSMsgType.TEXT"
    )
aiohttp.client_exceptions.WSMessageTypeError: Received message 8:1008 is not WSMsgType.TEXT�[0m
�[36m2025-11-06 14:52:05.116 DEBUG (MainThread) [aiowebostv] connect(192.168.31.113): uri: ws://192.168.31.113:3000, max_msg_size: 8388608�[0m
�[36m2025-11-06 14:52:05.202 DEBUG (MainThread) [aiowebostv] connect(192.168.31.113): uri: wss://192.168.31.113:3001, max_msg_size: 8388608�[0m
�[36m2025-11-06 14:52:05.381 DEBUG (MainThread) [aiowebostv] send(192.168.31.113): hello�[0m
�[36m2025-11-06 14:52:05.387 DEBUG (MainThread) [aiowebostv] exception(192.168.31.113): WSMessageTypeError('Received message 8:1008 is not WSMsgType.TEXT')
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/aiowebostv/webos_client.py", line 358, in connect_handler
    await self._get_hello_info(main_ws)
  File "/usr/local/lib/python3.13/site-packages/aiowebostv/webos_client.py", line 189, in _get_hello_info
    response = await ws.receive_json()
               ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/client_ws.py", line 407, in receive_json
    data = await self.receive_str(timeout=timeout)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/client_ws.py", line 388, in receive_str
    raise WSMessageTypeError(
        f"Received message {msg.type}:{msg.data!r} is not WSMsgType.TEXT"
    )
aiohttp.client_exceptions.WSMessageTypeError: Received message 8:1008 is not WSMsgType.TEXT�[0m
�[32m2025-11-06 14:52:05.391 INFO (MainThread) [homeassistant.components.webostv.media_player] LG webOS TV entity media_player.lg_webos_tv_oled65g33la is unavailable�[0m

[dominikconrads]

I have the same problem. As a result, automations that check whether the LG TV is turned on or off no longer work.
The integration only works correctly when the TV is turned on; if you turn it off, it becomes unavailable after a few seconds.

Same issue here. Automations involving this integration fail unless TV is on.

@bravespirit84 Can I suggest the title is updated to include something along the lines of "Automations involving LG TV integration failing to trigger" as it may help people find the issue. I initially dismissed this issue thinking it was an issue with simply an automation not firing.

Thanks for raising.

[Tundersepa]

Mul on sama probleem. Selle tulemusena ei tööta enam automatiseerimised, mis kontrollivad, kas LG teler on sisse või välja lülitatud.
Integreerimine töötab õigesti ainult siis, kui teler on sisse lülitatud; Kui lülitate selle välja, muutub see mõne sekundi pärast kättesaamatuks.

[bravespirit84]

@bravespirit84 you are mixing to issues which are not related, the error in the issue topic and your description is related to a custom element not related this repo, there is already an issue for it upstream madmicio/LG-WebOS-Remote-Control#164

For the other, see my previous reply, you don't need to create a fake automation, just link the button you have today to the media player using the device requested to turn on automation trigger, this will make the media player turn on button (or action) to actually call your custom button.

Thanks, I was looking for a similar error prior filing mine.

I would like to know the rationale behind the decision to mark 'unavailable' the devices that were 'off' before. As the time goes by, this issue is becoming a pain for not just myself but other users.

I will test the automation/button suggestion you made as soon as I have access to my HA instance and will revert back if working (tho I admit this sounds an overkilling process to turn on TV's but it's my humble opinion here...). If this is the plan on the long term to stay, I highly recommend write a thorough step-by-step "how to" guide in the integration webpage

[thecode]

I would like to know the rationale behind the decision to mark 'unavailable' the devices that were 'off' before. As the time goes by, this issue is becoming a pain for not just myself but other users.

The is an explanation here #155164 and home-assistant/architecture#1251, I initiated this discussion since it was should be the state of a device when there is no connection to the device, some devices represneded this as unavailable and some as off, this also lead to confusion when reviewing PRs since some reviewers accepted it and some not.

Note that this would not affect anyone who followed the installation procedure and created an automation in the first place. I was aware that some have skipped this step and that people that are using the frontend card are sometime using it to turn on the TV but this is not the right way to do it. In the long term I might add WOL functionality directly into the integration, I have already tested this on few TVs but due to lake of testers and differences between TVs I did not release it yet.

I will test the automation/button suggestion you made as soon as I have access to my HA instance and will revert back if working (tho I admit this sounds an overkilling process to turn on TV's but it's my humble opinion here...). If this is the plan on the long term to stay, I highly recommend write a thorough step-by-step "how to" guide in the integration webpage

Yes, I noticed the docs are not up to date with HA and not clear, I will work on that.