@yototogblo I think you missed my point:
- Mine doesn't timeout. The socket closes nicely as the TV shuts off.
- I'm wondering what's different (other than TV itself) so Wifi vs wired would be a the most obvious.
Yeah, I'm connected to wired though so not sure why I don't get the power off notification from the TV. Maybe it's a setting on the TV? I'll play around with it later to try to figure out what it could be.
Also, wondering if it could be because I have it connected to HA. I just shut down HA and tried again though and ran into the same issue.
Hey @cybrmage, pls do you know if it's possible to change the initial default timeout from 30s? In my case, this is causing my power off detection to take too long (since for some reason, my TV isn't sending a power down message). I'd like to reduce the default timeout to about 10s.
Thanks!
Ah, so I finally got it working and it's now instant off and almost instant on! The solution was to turn Quick Start+ on.
@asj It appears your code never gets to the "power down". The event sent by the TV when powering down goes to the handler_getForegroundAppInfo in yours (that's the id in the message received) and it never goes into the parseStatus method. As a result, the "power down" still takes a while with your code.
@cybrmage Your code still has a lot of debugs logged even when "log debug" is turned off. I can attempt to clean up the code a bit if you want.
Thanks guys for this. Works beautifully for me now!
@yototogblo can you send me the log message generated by this line
log_debug("handler_getForegroundAppInfo: got: $data")
My TV doesn't behave this way, and I'd like to see the message it's sending you.
I haven't dug into the mouse driver yet, but the rest of the driver and app work sweetly. I even created a dashboard that mimics a remote control. Infinite options from here! 
Two things I noticed along the way:
- Does the "Home" command in the device driver work? It doesn't for me. When I use the LG remote, it works fine, but not using the driver.
- Regarding switching inputs, I can now easily switch between apps (e.g., between YouTube TV and Amazon Prime Video), but not between "hard inputs" (i.e., HDMI ports). Is there a way to do this also that perhaps I'm missing?
Thanks again.
@mluck Glad it's working for you.
- Home doesn't work on the main driver at the moment, it actually has to get forwarded to the mouse driver, and I haven't written the code yet to do it. (it's like 2 lines, but it's needed for up,down,left,right,etc,etc) and I'm not 100% confident the mouse driver is good enough yet to be good. Seems ok, but I haven't run it long enough to be confident in it to force others to use it. Of course if you want to play with it you can just issue commands to the mouse driver.
- have a look up in the thread, you can specific the entire 'app name' for the hdmi input and select it that way. On my TV I can also name the inputs and it shows up then. I need to grab the list of external inputs and just append them to make it easier.
Unfortunately I'm traveling until Christmas, so everything is a bit on hold at the moment from my side.
Weird, I can name the input on my TV something nice. But that name doesn't show up in the driver. Are you saying it should? It's not a big deal either way--cuz I just use com.webos.app.hdmi[N] and it works fine. Peace.
@mluck did you click the ‘Get External Inputs’ button after naming them? (Or what ever I called it) I don’t refresh the input list Automatically at the moment. Other wise...What ever works for the next weeks until I’m back in town.
Yup. No worries. I’m gone too. Let’s sort out in January. Happy holidays.
1 Like
I could use some help getting this application to work with my 2019 LG OLED65E9PUA TV.
- I have installed the application code and driver code that cybrmage posted in comment #48.
- I then go to my applications, click the Install User App button, select the 'LG Smart TV Discovery 2012+' option, and am taken to the 'LG TV Search Started!' page.
- I sit on the search page for 15-30 minutes, but nothing is ever found. I simply wait at this screen forever with no results found.
Do I need to do something special on the TV to make it discoverable?
UPDATE: Turns out the TV needs to be powered on, not just connected to power, in order for it to be discovered. However, now I have run into a second issue.
Once the app finds my TV, I select it from the drop down menu, and proceed, I am taken to a screen which reads:
WebOS TVs can not be paired from the application. The driver will attempt to pair with the TV when it is initialized. Please authorize the pairing from the TV using the TV remote control. Please click Done.
Well, this is a vague message. What do I do from here? The message seems to say that if I go to my TV, an option will magically appear out of nowhere asking me to pair, but this is not the case. When I go downstairs to my TV and begin moving through menus, I am not asked to pair anything. Even when I go to the TV's device connection menu, there are no options to pair with Hubitat.
When @ozsmarthome ran into this problem, @cybrmage updated code and that seemed to fix the problem. However, as far as I can tell I am already running this improved code so I do not understand why I am running into the same issue.
UPDATE: This is frustrating. I managed to overcome my roadblock by simply clicking on the LG Smart TV Discovery 2012+ app, selecting my TV from the drop down menu, and then proceeding to the next page over and over again. On roughly the 4th try, all of the sudden a prompt magically appeared on the screen of my TV asking if I wanted to accept an incoming connection. I approved this message and now the TV is successfully connected to Hubitat.
Oh technology... You can be a filthy camel sometimes.
1 Like
Just a heads up, been using @cybrmage's version and my hub had been getting slowdowns. I contacted Support about it and they said it's because the hub is getting a lot of websocket error messages (every few microseconds) that makes it unresponsive at times. The error messages also don't show up in the logs.
WebSocketInterface.SocketSendThread - InterruptedException during WebSocket thread: sendQueue.take {} java.lang.InterruptedException.
@asj, any chance you fixed this error in your version? Also, any chance you fixed the "power down" issue? Sorry I hadn't sent you the logs. I had @cybrmage and had spent a lot of time making rule machine apps to work with it (RM can be a pain to write) so didn't want to start changing versions again
Thanks
@yototogblo There's a good likelihood I did. The websocket reconnection logic was one of the first things I re-wrote and then did further updates to it a few weeks ago using an limited quadratic backoff. (just a fancy way of saying 1s, 2s, 4s, 8s until the max reconnect time is reached, for example 60s) Funny enough I don't think anything so complicated is needed, either the TV is off and it'll be 2 minutes until it turns on again, or it's on. 
Anyways, I digress.
TL;DNR, I think it should behave better, hub slowdowns is something I run into and am well aware of avoiding. That said, I only run this on my dev hub, yet it doesn't slow down.
I'm also aware of what a pain RM4 rules are to update and change, it just a huge time sink doing programming that way. Sorry, I'd say it should be compatible, but the LG webos driver kind of did it's own thing and I'm trying to pull it more inline with "standards" 
Does it error out every time it tries to reconnect and fails? I still like the idea of "almost instant on" rather than waiting 2 mins (or up to 60s)
The driver reports digital on when it sends the WoL packet, but then reports physical on once it's established the websocket. That takes 2 mins on my TV (well feels like it, haven't timed it) since that's how long it takes for the TV to connect to the network and accept the WS connection.
There's an important distinction between digital on and physical on. All commands sent before physical on will be dropped and not sent to the TV. This makes rules a pita, so I was debating a queue and issuing recent commands once the WS is established. The mouse driver does this, but I'm worried it might be confusing to have the TV turn on then perform commands a while after they were issued, especially if they're contradictory.
I have "Instant On" on my TV (never goes completely off) and it takes about 1-2 second to accept the WS connection when turned on. As such, Hubitat is almost instant at reporting it as on (I had my refresh time at 5s which might have also been a reason for the slowdown). That's useful for me as I run Harmony activities as soon as the TV turns on.
For my curiosity, what's digital on? Why does it care about digital on vs physical on? Why not only have one "on" when the TV is actually on? I'm guessing it has something to do with not wanting to wait 2 mins?
A lot of devices distinguish between being digitally being asked to turned on, vs physically being on. For example I asked a bulb to turn on, but then it reports back being turned on. Or someone toggled a switch to turn it on, and the hub made no request at all.
I'll have to see if instant on makes a difference on mine. It feels crummy polling constantly anyways....surely there's something better...anyways for another day.
I think 5s is a bit fast, I'd suggest slowing it down to 10s -15s based on my experience with hubitat's timeouts.
Cool thanks.
Any idea if your code now properly get to the "power down" function i.e. the parseStatus method?
