Help with Roku ECP and storing variable


#1

Hi All,

I have a basic piston trigger my Roku to launch the IP camera viewer Pro application when there is motion sensed by my front door if my bedroom TV is on and open to the front door camera (http://ROKU IP:8060/launch/143683/dev?menu=no&view=single&camera=0). This is using the Roku ECP (https://developer.roku.com/en-ca/docs/developer-program/debugging/external-control-api.md).

It then waits 30 seconds and then goes back to the roku home page.

Using the Roku ECP, I see I can query the active app using GET (http://ROKU IP:8060/query/active-app)

Example response:
?xml version=“1.0” encoding=“UTF-8” ?>
active-app>
app id=“12” type=“appl” version=“5.0.81179041”>Netflix
/active-app>

What I would like to do first is have the piston query the roku and store the ID# of the active when the motion is sensed. Then after the 30 second wait, have it use the stored ID# to have roku reopen that channel.

Any help would get appreciated.
Thank you!


#2

See if this makes sense, I assumed (never assume lol) that the app ID’s are always 2 digits.

|+469ms|║║App ID = 12| 
|+470ms|║║Executed virtual command log (2ms)|
|+472ms|║╚Execution stage complete. (382ms)|

Edit: I had to replace the < > as it was making the display of the variable funky and I couldn’t make out what was I trying to extract.


#3

Hi eibyer,

So app ID can be longer then 2 digits, I’ve seen upwards or 5-6 digits.

I imported teh piston and the piston does store the response. Any way to store just the digit in a variable and then I can call on that variable to input to a post http call?

Here is a screenshot of the results of your pipston now.


#4

Yeah that output can be stored in a variable, which is what I had originally set it up to do. I will have to adjust the expression to make it more dynamic when the app id length changes.

I will repost when I get to a PC.


#5

Here is the revised piston, I tested it on a couple of apps… hopefully it catches the app id on other roku apps you use.

+556ms ║║App ID = 12

+159ms ║║App ID = 2285


#6

Hi @eibyer,

So lokos like it is working and it’s pulling the ID# and storing it in the variable “appID”. It fires the first post and open teh IP camera viewer but then unfortunately it doesn’t send the second post.

Here is a screenshot of the piston I have. can you let me know if there is anything wrong I’m doing or help make it work correctly?


#7

I believe there’s another event that happens after a webcall and that might be canceling the 30 sec timer. I would try and set the task cancelation policy (TCP) to Never. I can’t test it at the moment.


#8

Thanks, I can give that a shot. Where can I find this setting?


#9

Click on the ‘with’ and then the cog icon at the bottom, look for the TCP.


#10

Cool, found it. I’ll report back with my results.


#11

Hi @eibyer,

Looks like that did the trick. Working as expected.

I would like to add an additional check. Before the last post to move back to that previous channel. Can I have the piston check the running app again and if it is the IP camera viewer (id="143683) then continue on with sending that post or if it sees any other then the IP camera viewer to cancel the rest?

Basically if during the 30 second wait time I went back to viewing my streaming I don’t want the piston to send a command to reopen the channel and interrupt.

Possible?


#12

Not sure that can be accomplished in one piston as we’re talking about doing multiple web calls and using both responses in the logic. This might be a two-piston task and I’m not even sure that will work.

Before the last web call, execute an external piston that will retrieve the current appID and save it to a global variable. The first piston then waits the 30 secs, checks the global variable and compares it to the first piston’s stored appID. Sounds a little convoluted. :slight_smile:


#13

Hmm OK, I will give it a shot.

You’re recommendation is to scrap that check or is there some other way I can achieve what I want in some other fashion?


#14

The check is a good thing but probably needs a little bit more work. I will give it a shot later tonight when I get home.


#15

Thanks, tried but failed. I guess if you can give it a shot and let me know what you come up with. Thanks!


#16

So I was able to get it working. This is what I have. Does this make sense or is there a better method?


#17

That looks good to me, if there are other ways to do it then it would be just a matter of preference. Great job!