@dandanache, what a phenomenal driver -- thank you! I think I've used 3 or 4 different generations of LGTV webOS drivers in the past (all of which died at one point or another) and this one is the most full featured, not to mention very simple to setup. Mega props and wild appreciation!
With that said, a couple feature requests, if I might be so bold:
one of the previous drivers differentiated between a Switch (the act of turning the TV on or off) and Power (which indicated whether the TV was on). The difference came in handy -- not sure how easy or hard this is.
add other commands that are typical of a TV remote, particularly home, back, and up/down/left/right. Several of the prior drivers did this, fwiw.
Lastly -- curious what the use-case is for the Screen attribute and the Screen On/Off commands?
I don't know how to implement this; when my TV is turned off, its network stack is also turned off (no response to ping), can't figure out how to make that distinction.
This can be easily added as a custom command with one parameter, did not see the use-case for that; but folks are usually creative, so I'll see what I can about it.
I use TV as background noise (usually Discovery or some music channel) so I don't actually need to see the screen (less power drawn, protect OLED pixels ); I actually automated the TV to power on when mode changes from "Away" (I enter the front door); I should probably look into buying a smart radio instead (or use Sonos Radio).
I use the TV for background noise as well, with basically the same use case as you. Unfortunately, I have a WebOS 3.0 TV from 2015, so the Screen On/Off commands from your driver don’t work. There is, however, a way to navigate (using the remote) to the media player which has a selection to turn off the screen. I’d love to be able to navigate using menu/select/arrows using this driver. If you have the time and inclination, that’d be an awesome addition!
Created the driver and entered the static ip of the TV.
Approved the mobile notification on my screen.
Thoughts:
When the TV is off, I still show it active on my router's client list.
One article said to disable Quick Start+. Didn't make a difference.
I can see in the logs that the TV's IP becomes unreachable when it's off, despite all the correct settings being enabled. It works fine when the TV is on, which makes this even stranger. What's odd is that the LG ThinQ app can still access it turned off without any issues.
I noticed in "Network IP Control" there's a button under it that says "Generate Code." It appears it can be pressed and will display a code.
I wonder if this has something to do with the specific model of TV?
Let me know if you need anything else from me. Would really like to help get this working.
dev:3222025-02-05 08:34:49.812 AMinfoTV: LG C3 ⏲️ Automatically reverting log level to "Info"
dev:3222025-02-05 08:30:00.090 AMdebugTV: LG C3 pinging 192.168.2.18 ...
dev:3222025-02-05 08:25:00.042 AMdebugTV: LG C3 pinging 192.168.2.18 ...
dev:3222025-02-05 08:20:00.116 AMdebugTV: LG C3 pinging 192.168.2.18 ...
dev:3222025-02-05 08:15:00.042 AMdebugTV: LG C3 pinging 192.168.2.18 ...
dev:3222025-02-05 08:13:13.859 AMdebugTV: LG C3 fast ping terminated
dev:3222025-02-05 08:13:02.660 AMdebugTV: LG C3 fast pinging 192.168.2.18: 20 / 20 ...
dev:3222025-02-05 08:12:51.463 AMdebugTV: LG C3 fast pinging 192.168.2.18: 19 / 20 ...
dev:3222025-02-05 08:12:40.266 AMdebugTV: LG C3 fast pinging 192.168.2.18: 18 / 20 ...
dev:3222025-02-05 08:12:29.066 AMdebugTV: LG C3 fast pinging 192.168.2.18: 17 / 20 ...
dev:3222025-02-05 08:12:17.866 AMdebugTV: LG C3 fast pinging 192.168.2.18: 16 / 20 ...
dev:3222025-02-05 08:12:06.668 AMdebugTV: LG C3 fast pinging 192.168.2.18: 15 / 20 ...
dev:3222025-02-05 08:11:55.475 AMdebugTV: LG C3 fast pinging 192.168.2.18: 14 / 20 ...
dev:3222025-02-05 08:11:47.198 AMdebugTV: LG C3 fast ping terminated
dev:3222025-02-05 08:11:44.277 AMdebugTV: LG C3 fast pinging 192.168.2.18: 13 / 20 ...
dev:3222025-02-05 08:11:36.003 AMdebugTV: LG C3 fast pinging 192.168.2.18: 20 / 20 ...
dev:3222025-02-05 08:11:33.082 AMdebugTV: LG C3 fast pinging 192.168.2.18: 12 / 20 ...
dev:3222025-02-05 08:11:24.806 AMdebugTV: LG C3 fast pinging 192.168.2.18: 19 / 20 ...
dev:3222025-02-05 08:11:21.882 AMdebugTV: LG C3 fast pinging 192.168.2.18: 11 / 20 ...
dev:3222025-02-05 08:11:13.611 AMdebugTV: LG C3 fast pinging 192.168.2.18: 18 / 20 ...
dev:3222025-02-05 08:11:10.685 AMdebugTV: LG C3 fast pinging 192.168.2.18: 10 / 20 ...
dev:3222025-02-05 08:11:02.414 AMdebugTV: LG C3 fast pinging 192.168.2.18: 17 / 20 ...
dev:3222025-02-05 08:10:59.486 AMdebugTV: LG C3 fast pinging 192.168.2.18: 9 / 20 ...
dev:3222025-02-05 08:10:51.216 AMdebugTV: LG C3 fast pinging 192.168.2.18: 16 / 20 ...
dev:3222025-02-05 08:10:48.288 AMdebugTV: LG C3 fast pinging 192.168.2.18: 8 / 20 ...
dev:3222025-02-05 08:10:40.018 AMdebugTV: LG C3 fast pinging 192.168.2.18: 15 / 20 ...
dev:3222025-02-05 08:10:37.095 AMdebugTV: LG C3 fast pinging 192.168.2.18: 7 / 20 ...
dev:3222025-02-05 08:10:28.822 AMdebugTV: LG C3 fast pinging 192.168.2.18: 14 / 20 ...
dev:3222025-02-05 08:10:25.897 AMdebugTV: LG C3 fast pinging 192.168.2.18: 6 / 20 ...
dev:3222025-02-05 08:09:28.863 AMdebugTV: LG C3 ◀ Sending LAN command: wake on lan [REDACTED MAC]
dev:3222025-02-05 08:09:28.859 AMdebugTV: LG C3 ◀ Sending LAN command: wake on lan [REDACTED MAC]
dev:3222025-02-05 08:09:28.855 AMdebugTV: LG C3 ◀ Sending LAN command: wake on lan [REDACTED MAC]
dev:3222025-02-05 08:09:28.853 AMdebugTV: LG C3 🎬 Powering on ...
dev:3222025-02-05 08:08:02.092 AMdebugTV: LG C3 ◀ Sending LAN command: wake on lan [REDACTED MAC]
dev:3222025-02-05 08:08:02.087 AMdebugTV: LG C3 ◀ Sending LAN command: wake on lan [REDACTED MAC]
dev:3222025-02-05 08:08:02.082 AMdebugTV: LG C3 ◀ Sending LAN command: wake on lan [REDACTED MAC]
dev:3222025-02-05 08:08:02.079 AMdebugTV: LG C3 🎬 Powering on ...
dev:3222025-02-05 08:05:29.466 AMdebugTV: LG C3 ▶ Received message: {"type":"response","id":"hubitat_XXXXXX","payload":{"returnValue":true,"product_name":"webOSTV 23","model_name":"HE_DTV_W23O_AFABATAA","sw_type":"FIRMWARE","major_ver":"23","minor_ver":"20.54","country":"US2","country_group":"US","device_id":"[REDACTED DEVICE ID]","auth_flag":"N","ignore_disable":"N","eco_info":"01","config_key":"00","language_code":"en-US"}}
dev:3222025-02-05 08:05:29.402 AMdebugTV: LG C3 ▶ Received message: {"type":"response","id":"hubitat_XXXXXX","payload":{"returnValue":true,"features":{"dvr":false},"receiverType":"ATSC","modelName":"OLED55C3PUA","serialNumber":"[REDACTED SERIAL NUMBER]","programMode":false}}
First of all, great post! Lots of useful info, nicely formatted, nice...
It's normal that the TV's IP is unreachable when it is off.
There are two ways to "pair" the TV with Hubitat:
Using the TV screen notification (the driver uses this pairing method)
Using the pairing code that you get when you click the "Generate Code", no screen notification on this case (I did not implement this)
I see the TV's IP address is 192.168.2.18. I assume it is provisioned using DHCP and you have the necessary reservation configured in your router to make sure the TV gets the same IP every time.
Wake-on-LAN is built upon broadcast messaging, it can generally only be used within a subnet.
If Hubitat's IP address is something like 192.168.2.xxx, chances are the two IPs are in the same subnet, so we can rule this out.
From the logs, looks like Hubitat is sending the Wake-on-LAN packages to all MAC addresses of the TV, so I guess that these messages don't reach the TV:
Either Hubitat and the TV are not in the same subnet.
Or there is some networking equipment (router, switch) sitting between Hubitat and the TV that filters these Wake-on-LAN packages. Is Hubitat connected to the same 5GHZ Wi-Fi, or using a wired connection?
I am really curious how the LG thinQ app turns the TV on. They can either use the same Wake-on-LAN mechanism (but your phone is probably connected to the same Wi-Fi), or use the phone Bluetooth radio (same as the remote), but this is unlikely.
Thanks for the quick reply and also for making this device driver by the way .
Thanks for the explanation, makes sense.
192.168.2.6 and therefore is on the same subnet.
My Hubitat is hardwired to an ASUS router that I’ve set up as a media bridge. It wirelessly connects to my main router and simply passes data through (nothing beyond that setup on it).
Your question got me thinking in a new direction. I realized the ASUS router (acting as the media bridge) has a built-in feature to send Wake-on-LAN (WOL) commands by specifying the MAC address. I tested it out, and sure enough, it instantly powered on the TV.
Let me know if there's anything else I can provide or help you with (see screenshot below).
I'm pretty sure that your ASUS router is filtering the WOL packages sent by Hubitat.
This is what Copilot said when I asked it how to configure an ASUS router for WOL pass-through. Some suggestions, like disabling the firewall, are a bit crazy
Copilot answer
To ensure that your Asus router configured as a media bridge does not block or filter Wake-on-LAN (WOL) packets sent by other devices, you can try the following steps:
Disable Firewall (if applicable): Ensure that the router's firewall is not blocking WOL packets. You can do this by going to the router's web interface, navigating to the "Firewall" settings, and temporarily disabling the firewall. Test if this resolves the issue.
Enable Broadcast Forwarding: WOL packets are typically broadcast packets. Check if your router has a setting for broadcast forwarding or broadcast packet handling and make sure it is enabled.
Port Forwarding: Configure port forwarding for UDP port 9 (the default port for WOL packets) to ensure that WOL packets are properly routed to the target device. To do this, go to the "Port Forwarding" section of your router's web interface and create a rule for UDP port 9.
Enable IGMP Snooping: If your router supports IGMP snooping, enabling this feature can help manage multicast traffic more effectively, which can include WOL packets.
Check for Firmware Updates: Ensure that your router firmware is up to date, as updates can sometimes resolve issues related to packet filtering and network performance.
Here's a more detailed guide on some of the settings that may help:
Broadcast Forwarding:
Access your router's web interface.
Navigate to the "Advanced Settings" section.
Look for an option related to "Broadcast Forwarding" or "Broadcast Packet Handling" and enable it.
Port Forwarding:
Access your router's web interface.
Navigate to the "WAN" or "Port Forwarding" section.
Create a new port forwarding rule:
Service Name: WOL
Port Range: 9
Local IP: The IP address of the target device
Protocol: UDP
IGMP Snooping:
Access your router's web interface.
Navigate to the "Advanced Settings" or "LAN" section.
Look for an option related to "IGMP Snooping" and enable it.
If you have followed these steps and are still experiencing issues, it may be worth reaching out to Asus support for further assistance.
If you need more details or have any other questions, feel free to ask!
Thanks for helping me narrow down the issue, it’s been a bit of a puzzle. My research turned up mixed results on whether this older setup (in bridge mode) filters WOL commands. Back when Asus' AiMesh was still in its early stages, I had terrible luck with stability and ended up abandoning it.
But I decided to give it another shot and converted the router back into an AiMesh node. So far, it’s working smoothly, and more importantly, the TV commands are functioning as expected.
Appreciate the help. Look forward to using this device driver to write some voice routines.
This driver is great, and is much more reliable than the one I was using previously. Thanks for the outstanding work!
My use case is somewhat different than most: I don't want to use Hubitat to control the TV; I want the TV to tell Hubitat when it turns on and off in order to control lights. I've tried various approaches over time: A previous driver mostly worked, but sometimes rapidly alternated between indicating on and off, which caused my lights to flash on and off. Not good. I then tried an outlet that reports power draw, but that led to some false negatives and positives. The most reliable previous approach was to use Home Assistant to determine when the TV turns on, but the HA device bridge occasionally failed.
In case it helps anyone, this is how I made it work (very reliably) with this LGTV with webOS driver:
-Make sure the TV's QuickStart+ feature is on (settings-->general-->additional settings). I'm not sure if this is the same as the "Always Ready" setting described in the readme for this driver. The readme says to turn that off, but things work more smoothly for me with it on, in conjunction with the next step:
-In the driver's settings, change ping interval to none. (I find with QuickStart+ turned on, pinging results in the TV turning on for a second, then off.)
-This may not work for everyone, but I have a Marantz receiver which connects to the TV via eARC so that it turns on when the TV is turned on, and which reliably reports that event to Hubitat--its websocket remains open when the power is off, unlike the LG TV. I made a rule that is triggered by the receiver turning on or changing to the TV input; after a 1 second delay, it sends an initialize command to the TV. The TV then reports correctly that it is on, and I can use that event to trigger lighting. (I don't use the receiver turning on to directly trigger lighting, or I might find myself in the dark when listening to music.)
Has anyone figured out the timing on when to use 'Start Activity' once the TV gets turned on?
The activity is activated by an Amazon Echo call using a virtual switch:
If the TV switch CHANGES to on, it will try and start the corresponding activity.
If the TV switch is ALREADY on, it will try and start the corresponding activity.
#1 condition doesn't work most of the time. I can see on the 'Events' tab of the device driver startActivity is called, but the activity doesn't start.
#2 condition works consistently.
Is there something else I should be doing or keying off of to make this work reliably? I've tried a 'wait command' and that does not seem to help either.
Delay the switch = on Hubitat event until TV is ready to process commands - @salieri
To use the new TV Remote feature, you must first enable the functionality in the "Preferences" tab. The driver requires a child device to send TV Remote button commands, so if you don't need this feature, you may prefer to keep it disabled and avoid dealing with the child device.
Once enabled, you can use the "Push Remote Buttons" custom function (you don't interact directly with the child device):
Example buttons sequence: MENU WAIT:2000 LEFT ENTER WAIT:1500 DOWN DOWN DOWN BACK.
By default, a pause of 350 ms is added between button pushes. You can override this by using the special 'WAIT:xxx' instruction, where xxx = time, in milliseconds, to wait before sending the next button push.
First off, thanks so much for putting together the child device remote logic — I can’t wait to see how it works! That said, I’m having issues with version 1.6.0. When I attempt to connect to the TV, the connection never succeeds. I tried version 1.5.2 again, and it worked fine for me.
Here’s my log file for the initial connection attempt of 1.6.0:
Any thoughts on what’s happening here? One thing that’s different with this version and 1.5.2 is that I never seem to be prompted to accept the connection on the TV like I do with 1.5.2. Maybe there’s something going on there?
Holy cow, it works for me! Using the pushRemoteButtons command, I'm able to replicate the routine that I had the Harmony Hub IR blaster doing. I can finally retire that old thing...and it'll be so nice!
It's amazing that this old WebOS 3.0 LG TV is still able to be controlled via Hubitat. In order to turn off the screen on version 3.0, you need to open the Media player via the Home screen, then navigate to the screen off button. Just for reference, my command string looks like:
HOME WAIT:2000 UP UP UP RIGHT RIGHT LEFT LEFT ENTER WAIT:5000 UP RIGHT WAIT:1000 RIGHT WAIT:1000 ENTER
All those keystrokes seem to be needed to land me in the same place in the interface each time. Then I just hit ENTER again to turn the screen back on.
Thanks so much for implementing this... I'm stoked!!