Issue of the topic: I am using adb to assess whether my fireTV stick is in Standby or not. To this end I have ExecBinding running the following script every 3 seconds:
STATE=$(/usr/bin/adb shell "dumpsys activity activities | grep ResumedActivity")
if [ -z "$STATE" ]
then
echo "OFF"
else
echo "ON"
fi
I created a rule that will switch off the TV and Receiver when the FireTV goes into standby.
Generally, the setup behaves as expected. However, occasionally, the rule is triggered when I start an application on the FireTV and switches off receiver and TV just to instantly switch it on again. I assume that "/usr/bin/adb shell “dumpsys activity activities | grep ResumedActivity” returns null for a short period of time while the app is starting.
Is there a way to avoid this behavior? Perhaps by changing the rule in a way that it it ony triggeres if FireTVstate_returnValue==“off” for at least 1 minute? Or is there a perhaps a better way to check whether FireTV stick is in standby or not?
Of course. Start a timer when first gone ‘offline’, the eventual action being to do whatever is required. When going ‘online’, cancel the timer if it is running.
Of course checking every three seconds is a bit excessive if it’s all going to be delayed anyway.
A timer is certainly a good idea. Thanky you very much for the suggestion. However, thus far I was only using GUI for the setup and script’s done with Blockly. As I understand, timers are not (yet) implemented in blockly, are they?
Any further input on how I would have to modify the script to include a timer would be highly appreciated.
I maybe have another generell question about rules. Can a rule be triggered again while it is still running or can only one instance of each rule exist at a time?
I am checking FireTVstate_returnValue every 3 seconds, as the rule also switches on power of TV/Receiver.
That’s right. So your desire outstrips your means to achieve it. You can learn something new. Javascript rules will have most in common with Blockly.
In OH3 it is one at a time, further triggers will be queued.
But don’t worry about that, when using timers properly a rule starts a timer with an independent existence, and then the rule will exit, ready to run again.
Next time, depending on conditions, it might cancel or reschedule the independent timer.
It’s a very common technique e.g. for door lights timers, and the current lack of it is a major Blockly handicap that is being worked on.
An alternative approach is to use a dummy Item with ‘expire’ feature scheduling. This is so basic that it is difficult to cancel or reschedule, but it can be done. A second rule can then trigger off the expring dummy Item to perform whatever action is needed.
EDIT - that reminded me to produce this
Hopefully, learning something new will not make me forget things I already knew. I will invest some time in understanding the concepts of timers in javascript then. Could be helpful for other stuff, too.
Meanwhile I have also discovered a way to modify/improve the bash script that runs with execbinding, so that it does not switch off randomly anymore. (The following script works for a FireTV 4K stick.)
STATE and RECENT are two variables that store the output of the adb commands as a string.
$STATE and $RECENT simply return the string
The “conversion” is done in the if-statment
-z string is true if the string is null (an empty string) -n string is true if the string is not null
should not return anything. This does not seem to be the case for you FireTV Stick, thus the script is not working for you. Is it possible that you have a 1st Gen fireTV stick?
@Oliver
Thanks for the hint to use the adb binding. It is relativly new and not included in my openhab 3.0. Do you know wether this binding can reliably detect whether a FireTV stick is in “standby”?
I upgraded openhab and added the adb binding. It indeed seems to work flawlessly with the fireTV stack. Thanks again.
However, reaction time to trigger rules is rather poor.
I assume this is due to the refreshTime for status updates that is minimum 10 seconds. Do you by chance have an idea how I can accelerate reaction time when the state changes from “off” to "on?