@asj is it possible to change the input on these TV's using your driver and app? I have a rule that runs 5 days a week that changes to one of the HDMI inputs. This worked on my TCL but I'm having a hard time figuring it out on this one.
Also @asj I was looking at home assistant and it looks like they are able to send icons with there notifications. Not a huge deal but do you know if this is possible through Hubitat?
Have a look after all the command to Current State and you should see a state called Available Inputs, If you don't look up and click Refresh Input List. Once you have the Available Inputs, it's a list of inputs the TV told me. Go find the commannd External Input and type in the string you want.
This is brand new code, but works for me and lists both my named HDMI input, and an un-named one. You can also launch built in apps, etc.
You can automate External Input in RM4 by calling a Custom Command, search the forum for where to find this,
Now the caveat: if the TV is on this will work just fine. I thinking writing an automation that turns on the TV and then changes the input is probably nearly impossible at the moment. The TV driver sends events at all the wrong time, and drops commands that fail. For example if sends switch.on when you issue the command on(), but the TV won't accept commands for ~2 mins. So for example you do an RM4 rule that's:
on()
wait for on
send commands()
This will fail at this time. You have to wait on time, which is kinda crummy. Should you send an on event when issuing the on command or when the TV is actually on and able to accept commands? Some devices send on() on the digital request and then physical on later. My next task is to get the events fixed up so they can automate work.
I haven't looked at his this is done at this time, I assume it's another parameter the drive doesn't send, so probably no. I'll keep this in mind.
@asj When I do this all I get is apps not HDMI etc am I doing something wrong? The good news is it changes when putting the proper app string in there. I tried a few variations on HDMI3, HDMI 3, hdmi3, hdmi 3, etc. Thanks for all your help by the way.
@joetlawson My pleasure, it's nice to see someone using it.
Couple of options:
- Give this a try
com.webos.app.hdmi1just change the number as needed. I killed some old code the cycled through a predefined list, and that was one of them. - Go into Inputs ->All Inputs and add it to the Launcher and then you give it a nice name and use that.
Is there a way to do the same with streaming apps — switching between them — as you have described above with physical inputs?
Yes this works in my version. First run click Refresh Inputs then look at the list it gives you back for the names. Keep in mind, my version is very much a work in progress and I'm not using it on my main hub yet. There's still a large laundry list of things I want to fix/improve first.
That's an amazing piece of functionality. Appreciate both you and those that came before for this amazing app.
As an aside, what is the LG mouse driver for?
It allows you to control the "mouse" cursor on the TV. Feel free to play with it, it's ok with a human driving it for now. The goal is to be able to do:
- Turn on the tv: tv.on()
- Launch Netflix: input("Netflix")
- Click on a viewer: mouse to x,y and click()
- Voila
If you move the "magic remote" and see a cursor you should be able to use the mouse drive in that case. Instead of going to an x,y location and clicking you can use left,right,up,down button presses as well.
I haven't validated it loads the mouse uri correctly all the time, and it looks like each time the main app connects it gets a new websocket address for the mouse. So when testing it by hand you have run "getMouseURI" before using the mouse.
1 Like
Your driver works great, Thanks for it!
Can you please clean up the logs? There's a ton of warnings whenever the TV is off even though it's because it can't connect to websocket (which is expected).
Thanks!
Also, it appears that when updating apps, at some point the TV thinks its off. Maybe it's because the currentinput becomes null during that period because it's trying to launch the newly updated app? I've had rules happen incorrectly a couple of times because of that. I've now added cancelable delays to those routines since it doesn't last long but would be nice if that could be fixed.
Thanks
So actually, was looking at this again and I have a few more questions.
First, some context:
I had been using HomeAssistant for my LG TV integration and it worked pretty well. It's essentially used to keep my Harmony remote in sync when someone uses a different remote or uses Alexa to launch the TV. It does this by running a rule to run the corresponding Harmony activity when a change in the TV input occurs.
I'm now trying to migrate that rules from HA and all my ST rules and devices to HE.
Issue:
Home Assistant gets a much faster status update when the TV is turned on or off, I just tried it multiple times and when I turn my TV on, it typically takes HA about 20s to notice while it takes HE about 30s. The difference is more drastic when I turn the TV off. It usually takes HA about 10-15s to notice the TV is off while it takes HE about 40s. I understand you're using websocket timeouts so the minimum time for off status to be noticed would be 30s. However, I wonder how HA is able to notice much faster. Would be great if that can be figured out and we could get faster status updates.
The other issue is the current input state. For some reason, when the TV is off, your driver switches the "CurrentInput" between null and the last input. I have rules that get triggered by a change in current input and they don't seem to get triggered when I turn the TV on. I can use rules to tackle this but I'm wondering why it doesn't always stay at null when the TV is off.
Example:
Current States
- CurrentInput : com.webos.app.hdmi4
- mute : false
- power : off
- switch : off
- volume : 6
Thanks!
@yototogblo oh I'm sorry, I replied to your post earlier today, but I didn't realize it was regarding the original driver. I've been talking about fork on a few threads and got confused. Please disregard what I said. 
No need to apologize. I also tried yours yesterday actually and like that it has the input name. Just wish it was still called currentInput vs channelName (since inputs are not channels :)) but not a big deal.
Everything I said also applies to yours as well though so looking forward to your changes. For the most part, I care about faster on/off reflections (hopefully we can figure out how HomeAssistant is able to detect those very quickly) and the currentInput (channelName in your case) changing to null or blank when the TV is off.
@yototogblo Thanks! A couple of items:
-
I updated the LG Webos Driver this morning, looks like it takes ~12s to detect off. It works like this: TV turns Off() and the websocket closes without perceptible delay. The driver then tries to reopen the socket with 2 of delay, which fails after 10s and sends the off() event. Total time is 12s. I think everyone must be trying to reconnect and hence not declaring the TV off on websocket close, since it could conceivably close for some other reason...? I think given the time to detect on (1-2 mins since the TV takes a long time to connect to the network regardless of poll interval) that seems inline for off detection.
-
I changed the name to channelName because it seems more consistent with the TV capability. It has the attribute
channelwhich must be a number, sochannelNameseemed more consitent. I just went through the Device Capabilities and MediaController seems to be the right thing capability actually. I'm not sure I love the nameactivitybut
? But I think this should be broken up. We have an app, and possibly a channel which are different. -
Looks like a channel name of null (which was "") doesn't work with events. This causes odd behavior where when displaying the device page (or maybe reading attributes) returns the last value, but on sendEvent() being called changes it to null, but doesn't actually store the value. So it looks like you have to send some string, so I send
[off]now.
Thanks for the updates. A few things though:
- I actually think the driver only fails after 30s not 10s. The logs say:
[failure: sent ping but didn't receive pong within 30000ms (after 5 successful ping/pongs)]. This would explain why I haven't seen any change in the device status being updated to "off" since installing your new code. Maybe this is a websocket setting and not something the driver can change? HA is doing it in much shorter somehow though.
- Thanks for renaming to off. Works much better now.
@yototogblo Interesting...are you using wifi or wired ethernet? I'm on wired, and the websocket gets closed by the TV, not a ping timeout.
It's hard to show the button timing with the remote, but it's actually the same for me with issuing an off() command via the websocket.
Edit: oh shoot, it's the mouse driver getting the web socket closed and logged. I must just have logging on the TV turned down. The log message for websocket reconnect is due to the same thing happening for the TV driver.
Ah okay. So your timeout should be about the same as mine then (and same as the other DTHs). I wonder if there's a way to get websocket to time out earlier. Still curious as to how it's done natively by HA.
What's funny about the HA comparison is that HA takes a longer time to recognize a change in input but recognizes the TV getting turned off and on much faster.
Hey man,
Power detection still doesn't work for me using your code. Was looking at the code and my logs and it appears my TV never sends that message of powering down. I have a LG C8 OLED BTW. Please anything I should try here?
