A couple more things? Idea for how to determine power state and screen state? #122
Replies: 5 comments 1 reply
-
Given the restrictions you've mentioned, we could only have three states: powered on, powering off and unknown/offline. It's also a bit tricky given the TV is also offline while powering on, which could lead to wrong information (although sending WoL is ok if the TV is already on). I could add a function |
Beta Was this translation helpful? Give feedback.
-
Yes, that would be great. In NodeRed you then could setup a passive loop if unknown to wait for expected state until timeout (if such was setup). |
Beta Was this translation helpful? Give feedback.
-
I just noticed, the retry timeout... Nice. |
Beta Was this translation helpful? Give feedback.
-
I should be able to test this and add it to my project in a day or so. Thanks! |
Beta Was this translation helpful? Give feedback.
-
For what I needed works. Not perfect, as we discussed, but best I think we can do given the limits of the API from the WebOS, that I can see. |
Beta Was this translation helpful? Give feedback.
-
A couple more things? Idea for how to determine power state and screen (mute) state?
GIven that CEC protocol has an explicit query for power state, i.e. 'pow', which returns 'standby' or 'on' respectively, I am trying to think of how to do same via WebOS/ip control methods. Thus it appears, unless I am wrong, that getIpControlState() can return true even if the TV is powered off, but the network stack has not dropped, which happens 2 to 3 minutes after explicit power off. I am thinking I might try getCurrentApp() if getIpControlState() returns true... if getCurrentApp() is null, then maybe the TV is in the process of powering down and the network stack is dying (so to speak). Of course, if connect() or poweronandconnect() fails, I can assume TV is off, likely offline.
And, then there is screen state, I have not looked at the PDF information or search WebOS API as yet, but a way to know if the screenmute is enabled would be nice to have. For now, I assume screenmute is not engaged when my program logic in NodeRed starts, and if any command issued other than screenmute or videomute, I assert screenmute flag is false (not great or completely accurate), of course if power off, I set my internal screenmute flag to true, power on internal screenmute flag false. allmuteoff is no brainer.
The UI controls reflect the various flags or states, of course mute, volume, input states are easy to come by the logic in lgtv-ip-control module.
Beta Was this translation helpful? Give feedback.
All reactions