Avoid repeating same command


#1

1) Give a description of the problem
I have been trying to deduplicate my code by putting a single “Execute Piston” at the end of this piston. The variable gets set but nothing plays and it appears that the piston I attempt to execute gets ignored. The piston I am sharing here works, but I want to modify it to simplify the code. Also, as I enhance my “Alert Player” piston (I will likely add an attribute to turn on/off logging of the message played in Message Store), I do not want to modify all the instances I call it in this piston.

2) What is the expected behavior?
Assign appropriate value to textMessage at a certain time/date and fire another piston to play that message on a Sonos speaker.

3) What is happening/not happening?
The piston shown below works. All other permutations I have tried, such as evaluating whether there were contents in textMessage or using local variables to tell this piston when to fire the Alert Player piston have failed with the piston never firing. It always seemed like the portion of code that follows the “every” statements was being skipped.

4) Post a Green Snapshot of the pistonimage

5) Attach any logs (From ST IDE and by turning logging level to Full)
No logs as the piston works. I am trying to optimize it.

I am also adding the other piston in case it might help this topic or others trying to do something similar.


#2

I do not have a Sonos to test, but your logic looks sound.

I admit though that I take a different approach when sending arguments to another piston.
I use the External URL in a GET web request to pass the data.


Piston 1

Set variable {textMessage} = {"Don't forget to take your medicine."};
Make a GET request to https://api.smartthings.com/api/token/abc123/smartapps/installations/def456/execute/:ghi789:?textMessage={textMessage};

This link points to the External URL of Piston #2, but I added to the end of the URL:
?textMessage={textMessage}


Piston 2

Set variable {latestMessage} = {$args.textMessage}

This stores the current argument into a local variable, ready for use.


The 2nd piston can then send the speech text using the string found in latestMessage

Here is the 2nd piston and log:

temp

Easy peasy.


#3

@WCmore - Is there a technical advantage to doing it the way you would do it? I am a novice at this so I see the value of the simpler method I used but if there is a technical advantage I can definitely learn :wink:


#4

I don’t know enough about the inner workings of webCoRE to say for sure, but I can say this method is rock solid for me.

You could even store most of the External URL in a variable to keep the code uncluttered.
(I would likely use a global variable, and store the URL up to the question mark. This will let ALL pistons call your ‘Alert Player’ piston with only a few extra characters added to the end.)


#5

I use something very similar, a ‘Speak and Resume’ piston, for all audio messages posted to my Sonos speakers. It has a couple of a additional options, including speaker selection and volume, but essentially serves the same purpose.

The way you are executing this is fine and there is little benefit in trying to simplify it further, especially if it is working for you. One option, if you were really determined would be to set a global variable @textmessage in the first piston and have the second piston trigger ‘On Event @textmessage’ but that would add some small delay to execution and complicate sending additonal arguments.

As for $args vs the GET request, both are legitimate methods and only a matter of preference. There is no real technical advantage to one over the other.


#6

Thank you for the feedback and different options. The issue I was having was that adding an IF at the end of the piston to execute the alert player piston was being ignored. I tried looking at the contents of textMessage or even a simple boolean variable but it did not appear to update in time to get caught later in the piston. The approach I took works fine but I do not like repeating the same code whenever possible.


#7

Well, for what it’s worth, your very top picture in this thread could be condensed a bit:

As long as you are not subscribed to any devices in this piston, shifting the “Execute piston” command to the bottom (in it’s own block) will work as expected.


#8

I had tried that but had issues so I tried to test for a condition before executing the piston and that did not work either. As soon as I get a chance I will try your suggestion. Thanks!