Call Piston with Arguments - Need Syntax


#1

1) Give a description of the problem
Trying to send an integer (number of seconds) to another piston. Have set the value in a local variable and passing as an argument. Not sure how to define a variable in the receiving piston to accept the integer and load it into a local variable.

2) What is the expected behavior?
(PUT YOUR INFO HERE)

3) What is happening/not happening?
(PUT YOUR INFO HERE)

4) Post a Green Snapshot of the pistonimage

5) Attach any logs (From ST IDE and by turning logging level to Full)
(PASTE YOUR LOGS HERE BETWEEN THE MARKS THEN HIGHLIGHT ALL OF THE LOGS SND CLICK ON THE </> ICON TO FORMAT THEM)


Echo Speaks piston with variables
Need an example of using global variables to trigger a piston (which uses values in variables)
#2

I use this feature in a couple pistons that I have. It sort of looks like you have it there though… But I use the same variable name in both pistons. This is what it looks like in the piston that gets called.

image

What part are you stuck on?


#3

This is an example piston I posted which shows the calling piston:


#4

Thank you Mike - will look into this shortly!


#5

When you send arguments, do they have to be stored in a variable? Or, can you specify values directly in the “Execute Piston” statement?


#6

To me it looks like the only option is to have them be in a variable if you want to pass arguments along.


#7

Do I need to call the variables by the same name in both pistons? In other words, the calling piston uses a variable called waitTime(integer). Does the piston I’m calling need to have the same “waitTime(integer)” defined? Or, can I call it something else?


#8

I just tried using different names and it didn’t seem to work. So I’d advise naming the variables the same in both.


#9

Really appreciate the feedback, Mike!


#10

I know this is an old discussion - but I have 2 questions:

  1. how you can see the value of the argument getting passed?
  2. Say that I pass an argument from a boolean (true/false) to another piston, does the piston that the argument was passed to retain that value, or is it cleared each time?

#11

Try logging $args on the other end to see what’s being passed and I believe it gets cleared each time. You can view the variable list in the piston editor and I believe $args shows null each time (not 100% on that).


#12

Do you know the syntax for that?

My piston that I’m passing arguments to:

The log and variable panel:

Thanks for the help, i really appreciate it!!


#13

This is an excerpt from a piston passing a textMessage variable to my speaker piston.

This is part of the receiving end…
image


#14

And this is a simplified version of what I think yours is doing…

Sender…

Receiver…

Log…
image


#15

I see now how that works. I’m still learning the arguments/logging stuff, hence all the beginner level questions. Setting up the log command that way worked perfectly.

Do you know how i would check to see if the argument passed onto the receiving piston is cleared after each run?


#16

I just executed the piston again by itself with no argument.

image


#17

Well, that was an easy solution to the question. Guess I should have thought of doing that!

Thanks again for your help, I’ve got this working so far. :smiley:


#18

Sorry for the delayed response. I just saw this post.

In all my testing, the $args always show as null unless the argument is coming in at that exact moment. I think the reason @eibyer’s second test came up false is because he has his $args hard coded in the top section. If there are no $args in the define section, then they will be null 99.9% of the time.


#19

I actually didn’t realize that it didn’t have to be hardcoded in the variables section.


#20

Hi all, bumping this topic as I’ve been seeing some strange behavior in this regard recently:

TLDR; wondering if there’s a race condition at play when assigning $args.something to a local variable?

I’m building an expandable irrigation system for 4 circuits so far. In short; I decided on a parent-child model, where the parent/master piston executes 4 child pistons, passing a set of arguments/parameters over to them. The 4 child pistons are exactly identical except for which device (solenoid valve) they are controlling and a friendlyname. Everything else like duration is passed down as arguments from the parent.

The funky thing I experienced is that although functionally identical in code to it’s duplicated siblings, one of the child pistons would NOT receive it’s arguments, i.e. they were all null. I found this thread, however although related by title, it was about calling pistons with parameters via URL. The difference that here it’s just one piston calling another.

I debugged the heck out of it and it appeared that SOMETIMES the child piston would gets it arguments, yet most times not, which led me to contemplate if this argument transference business perhaps is subject to a race condition of sorts. I’d really like to ask you guys for feedback if you have any experience to corroborate this theory?

I should add what really freaked me out is that while this problem appeared between the master/parent piston, who’s job it is to schedule irrigation events, the problem did NOT manifest itself when I called the offending child piston from a second egg-timer/manual parent piston.

I can’t say for sure that I solved or nailed it it, as it’s a bit of a belt-and-suspenders hack I’ve implemented to see if it would make a difference. Yet what I frankensteined seems to have held up so far:

  1. I moved the definition of the local piston variables being assigned to $args.whatever up to the beginning of the definition block and ordered them in the same order as the arguments are applied (alphabetically it would appear)
  2. I put a Do-With-Location block in, which sets the variables manually right at the top of the piston. This may be unnecessary as I understand variables can be initialized with default values at runtime by setting that up in the definitions workshop. However based on what I’ve seen, it would appear this isn’t always the case.

If you would be kind to help me understand what might be going on here besides the usual Ghost in the Samsung, I would very much appreciate it

Thanks,
/Max