Appreciate some guidance on the best way to implement this.. using @armand ās roku integration I am looking to implement logic that when the roku is paused or stopped lights brighten and when resumed they return to a dimmed. But for this to only happen when Iām in āmovie modeāā¦ I am controlling lighting through scenesā¦
An Evenning Scene - based on time of day
A Night Scene - based on time of day
A Movie Scene - can be manually activated
When the movie scene is activated AND the roku changes to paused or stopped I want to brighten the lights by returning to the time activated scene(evenning or night) and then when its resumed return to the movie scene.
This is what I have so far which works, but.. I only want this rule to run when the movie scene is activated to start with. I canāt just add a condition on this because when the content is paused the scene would change..
What would be the cleanest way to implement this? I could just build the brighten logic directly in to the rule, but thats then going to be cumbersome to modify - scenes make this easier to maintain..
Trigger events:Roku transportStatus paused OR Roku transportStatus stopped
Actions to run:
IF (Scene - Movie is on) THEN
Scenes per mode:
Evening: Scene - Evening Lights
Night: Scene - Night
Wait for event: Roku transportStatus is playing
Activate: Scene - Movie (or scenes per mode?)
END-IF
There is a possible oddity here: if the status goes from paused to stopped (not sure if this would ever happen), the "Wait" would get cancelled (triggers cancel waits), the actions would start over again, and it's likely nothing would happen--including the eventual scene restore--since the Movie scene would not be on, which prevents the rest of the rule from doing anything. There are ways around this, but they are more complicated to write, so I figured I'd start with something simple that might work.
Any other Roku transportStatus changes are fine, since they will not re-trigger your rule, and when it starts playing again, the "Wait for event" will catch it and re-activate your original scene (if other status besides "playing" would be appropriate, you can modify this wait as needed; Rule 4.1 lets you use "Wait for conditions" if that makes more sense for you).
Others might have better/different ideas; otherwise, this seems like a good starting point to me.
Thanks for following up. If a player is paused, eventually the screen save kicks in which changes the state to stopped, as the app is shut down, to load the screen saver.
Frankly, I am just happy people are using the driver, as improvements only happen based on need, and my needs were satisfied a long time ago.
This all started for me, because the Harmony solution only handled activities. I modified it to support launching apps, and sending various remote control commands, but it was still not what I needed, because harmony does not sync with the TV. So, I created this based on the SmartThings version that was a basic remote, and added all the features I needed, and re-wrote their logic as there were things I did no like. I am still a groovy newbie, but I know a lot of languages, so with some reference materials, I was able to piece together a code style I prefer, and logic that was more optimized. Next will be a better solution for handling refreshes, and state, and maybe some more code cleanup. Always looking for the cleanest solutions... and happy to implement any recommended enhancements that make sense. I noticed I also still have a lot of work to do on the integration app.
OK, so looks like my rule will need to be modified. I'm thinking an "easy" way (but still more complicated) would be to use Private Boolean to track if the rule did its thing already and then only change things back if that is the case.
Though thinking about this more: in that case, the original rule would probably work--just add a "Set Private Boolean: False (this rule)" after the "Scenes per mode" in the IF THEN, and wrap the contents of the ELSE in an IF (Private Boolean is False) THEN ... END-IF, and add a "Set Private Boolean: True" before the last END-IF.
Missing an END-IF at the very end (or really before the "Set Private Boolean True" if you want--worst case is you'll set it true when it already is, but it might prevent it from getting stuck false in some weird edge case), but otherwise, yeah, basically what I was thinking.
and happy to implement any recommended enhancements that make sense. I noticed I also still have a lot of work to do on the integration app.
I'm thinking an "easy" way (but still more complicated) would be to use Private Boolean to track if the rule did its thing already and then only change things back if that is the case.
