The global variable is only there for me because I send messages from other pistons to that piston. If your piston and message are within the same piston, (like your example), then no global is needed.
1 Like
Instead of having that code duplicated so many times (once for every custom msg piston I want to create), I think I might have the updating happen in a separate piston, and just call it from each msg piston.
Is that a viable option for something like this?
If it works the way you want, then itâs viable. 
1 Like
Thanks for this thread. Took me a couple days of playing around but I finally got this working. I also learned some new techniques in Webcore.
2 Likes
lol haha, right?
@mebejedi
Hey, one more questionâŚ
What is this other local variable actually for?
device Echos =
I donât see it referenced anywhere else (haha, unless I missed it).
Same here.
I always love these kinds of active learning sessions.
There is so much up in here that I wasnât able to even take it all in on this go-around. So, I will be coming back at some point to go through it all again, and learn how to do some of the other stuff eventually.
OK, now thereâs another quirky thing lol
When I split it into two pistons (one with the updating mechanism, and one with the speak command, etc), it acts really odd-like, in two very specific waysâŚ
-
The update is so delayed that itâs never ready in time for the speak command, even though I have a WAIT in the speak piston. However, the longest WAIT Iâm able to have (because of #2 below) is 5 seconds, and thatâs not long enough for the update to happen, and it never works right; it just speaks out of the one that was the current one at the time the piston fired. After it fires, if I run it again, then it works out of the correct one.
-
If I make the WAIT longer than 5 seconds, the speaking part never happens at all. lol
So, unless somebody has any wisdom on why these things are happening, and how to mitigate, I will probably just have to have all of the code duplicated in every speak piston.
Oh well. Itâs not ideal, but even with that goofiness (and the fact that it seems to only work on native Alexa devices, and not the Windows 10 Alexa app), this is still a really dang cool automation.
I was probably going to have WC search the string for devices, but I ended up not doing that. Itâs unnecessary in the piston. Go ahead and delete it.
Also, if you changed your pistons, it would help to see the new pistons.
And Iâm still running Win7, so I canât help with the Alexa app. 
1 Like
Right-on. Thank you.
Itâs gone. 
Aha. Well, I tested just the section that pays attention to the Alexa device, and did it on multiple different kinds of Windows 10 computers, and on all of them, that trigger never happens. So, I assume that edition of the Alexa app is just not equipped to set that particular flag like the native ones are. No big deal.
Variable Updating Piston
Speaking Piston
Me-to-Alexa: âThank youâ
Alexa: turns on SmartThings switch (108 here)
webCoRE: runs Speaking Piston
Speaking Piston: calls Variable Updating Piston
Variable Updating Piston: updates global variable
Speaking Piston: waits 5 seconds (longest period possible without totally disabling the whole thing; when 5 seconds is already way too long to wait to get âYouâre welcomeâ lol)
Speaking Piston: speaks a customized version (British voice, Emma) of âYouâre welcomeâ to the last spoken to native Alexa device
My guess is that itâs not updating the global. When you setup an execute piston the text that appears mentions that globals in the calling piston donât get updated until the piston is complete.
In my piston a Alexa routine sets a simulated switch. The switch triggers the piston and the first thing I do is call the piston to set the current Alexa device, mine is virtually identical to yours. It sets a global that contains the last echo spoken to.
Then I call a another piston that sends out the message to the echo I spoke to. Initially I was writing my message into a global variable that would be used in the speaking piston, but that did not work. This is not quite what you are doing but I think it failed for the same reason. The global variable that had the message did not get updated until the piston ended. So the message that got sent was the last value set in the global prior to running this piston. So I then changed the piston so that I passed the message to the speaking piston via an argument.
It then started working. So I think you will need to rearrange things. Your speaking piston calls the routine that sets the global CurrentAlexadevice, but it wonât get updated with the new device until the piston stops. So it may work sometimes if the global happens to contain the correct Alexa device when the piston starts.
This of coarse may be completely wrong but that is how I have interpreted what was happening to me.
3 Likes
I tend to agree. Globals are an odd beast, so I wouldnât set up those pistons as @sgnihttrams did.
Try putting lines 25-32 of the Variable Update into the Speaking piston and remove the âExecute Pistonâ and see if that works.
If you really want a separate speaking piston, then you might be better off with my version.
First Piston:
If switch 108 changes to on, then @Message = âYouâre Welcomeâ
Set variable @PistonTrigger = $Now
This puts the message in a global, and the change in pistontrigger activates the Speaking Piston
Speaking Piston:
If @PistonTrigger changes, then with Music Player 3 and Music Player 4 getDeviceActivity.
If Any of Music Player 3 and Music Player 4 wasLastSpokenTo is âtrueâ, then save matching devices to (LastEcho)
With (LastEcho), speak (@Message)
Then, any other piston that you create can end with
@Message = âWhatever the message isâ
Set variable @PistonTrigger = $Now
And will activate the Speaking Piston and send the @message to the appropriate device.
For example, while this piston designates the echos differently, it still sets up the message to be sent to the Speaking Piston:
1 Like
@Terminal is exactly correct in his analysis of global variables and why the pistons are behaving why they are. Itâs documented behavior on the webcore wiki
1 Like
Thanks, everybody.
Due to my particular neuroatypicality, sometimes I need to take things in tiny bites. So, Iâm going to pick one or two small areas to focus on here first, and see how that goes.
TBH, once in a while, I really wish I were able to have discussions like this in verbal form, because sometimes, trying to follow written comments like these (not that the difficulty is in the comments, but in me) is reminiscent of those âword pictureâ math problems as a kid. I was like, OK, I already get the math itself, but then they put it in a context that has other levels of complexity for me (reading), and I stumble. lol
AnywayâŚ
One point I think Iâm hearing is that, even though I am calling another piston to update the global variable completely outside of my speaking piston, the variable isnât getting updated before the speaking part, because (with the way I have it above) it canât actually happen until the speaking piston is finished firing.
Regardless of whether I have that understood correctly (or whether I understand how to work around it correctly even if I do understand the problem correctly), I have another idea Iâm going to try next to see how it helps (or doesnât), and learn and go on from there.
Iâm thinking something like thisâŚ
Me-to-Alexa: âThank youâ
Alexa: Routine turns on msg-specific-switch1
webCoRE: runs msg-specific-piston to put relevant msg into @MSG global variable
webCoRE: notices that msg global variable has changed and runs lastSpokenTo Variable Updating Piston (So, I guess @MSG changing is the trigger that causes the lastSpokenTo updater to run)
lastSpokenTo Variable Updating Piston: updates lastSpokenTo global variable
webCoRE: Variable UPDATED Piston notices the change in the global variable, and turns on switch2
webCoRE: notices switch2 turn on, and runs universal-Speaking Piston
Speaking Piston: (no delay needed, because the automation already has confirmation that there has been a change in the global variable) speaks @MSG to @lastSpokenTo device
I donât know how much, if any, delays I may need in there, but I will try this as-is first and go from there.
I think Iâm actually starting to see what is meant by some of the suggestions, and why some elements I wasnât understanding before are in there.
So, at this point, either I have something that will work, or at least Iâm a little further along in my learning process, and will be better able to build on this.
I will give this a try, and report back (Then, only after doing that, I will go through your suggestions again, and see if I can get more of my mind around more of those details)âŚ
UPDATE:
Haha, OK, this clearly wonât work. lol
When I got around to building it out, I realized that, with the way I have it here, the automation will fire every time the lastSpokenTo global variable changes (which is obviously not desired).
@mebejedi
Iâm thinking your use of $Now may be related to mitigating for this issue, but Iâm just not totally clear yet on how that all works.
Iâm going to try a different approach next, and maybe get back to this part later.
I have settled on using the combined version.
It works.
When I have more time and brain energy at some point, I will pick this back up, and work on it more to try to fully understand and then build my own version of this system that has a separate, centralized lastSpokenTo global variable updater piston and smaller speaking pistons, but for now, I will just have fat speaking pistons that have all of the necessary code right in them.
Thanks a lot to everybody for working with me on this.
How I have it for myself now is not perfect, but it does the trick, and thatâs pretty freakin cool!
p.s. Even though the thing that did it for me was seeing it in @mebejedi 's piston screenshot (and actually importing it), I gave the âSolutionâ to @nathancu , because, if Iâm understanding it correctly, even though I didnât understand it at the time, that is who first stated the concept in this thread. If thatâs not right, please let me know.
Oh ya, here is a green screenshot of my final (for now) pistonâŚ
p.s. I modified the title of this thread to more accurately reflect what I actually wanted (AND what this thread is actually all about).
2 Likes
@mebejedi
Iâm looking through this again, and I think Iâm getting it.
Building test pistons while watching the game.
1 Like
So I am taking the easy road here and asking this question before I dig into the forumsâŚ
Will I be able to use the Echo Speaks functionality to do the following :
Walk into a room and say âAlexa, play my eighties playlistâ, and using webcore, be able to turn on speakers in that room? As opposed to âAlexa, play my eighties playlist in the kitchenâ. In essence, can webcore know which Alexa received the command to play music?
I would say yes.
If echo_1: wasLastSpokenTo=true, then with speaker A, turn on.
If echo_2: wasLastSpokenTo=true, then with speaker B, turn on.
This is probably how Alexa links lights to Echos. Now with ST/WC, you can do it with anything. In my house, I have Fan, Master Fan, {Kid 1} Fan, and {Kid 2} fan. Now, each person could just say, âTurn on Fanâ in whichever room theyâre in. Iâd have to rename Fan to Living Room Fan, and then have an Alexa routine for âTurn on Fanâ that throws a switch in ST to launch the WC piston.
1 Like
You can definitely do this. That is why I searched for this, because I had a piston that I wanted to be able to activate in any room and respond in the room I ran it. It was a response and not music but that could work just as well. .
1 Like
OK, I mapped it all out so I knew what I was going for, disabled all other related pistons, created my desired global variables, and built the two pistons, but itâs not working.
Here they areâŚ
Message-specific piston:
Speaking piston:
I could post logs as well, but first, can you see anything in these that seems like itâs misconfigured?
I would not make the Alexa_AllNativeDevices a global variable. Globals should be used with caution. Besides, you donât even use the variable on line 34 anyways (which wouldnât work anyways, because the properties for a group are generic, rather than device-specific), so itâs unnecessary.
Try this:
Line 29
With Music Player 1, Music Player 2, Music Player 3, Music Player 4, Music Player 5, Music Player 9, Music Player 10, getDeviceActivity
[EDIT] I just realizedâŚhow the heck did you get getDeviceActivity with the global? Could you post a green piston snapshot so I can look at that line? It shouldnât be possible.
[EDIT] Oh, I see. you set it for a single Echo, then go back and edit it with the variable. I wonder if thatâll work.
[EDIT] NopeâŚdoesnât work. Line 29 needs to list all the Echos.
Line 29
With Music Player 1, Music Player 2, Music Player 3, Music Player 4, Music Player 5, Music Player 9, Music Player 10, getDeviceActivity
1 Like
I changed that one line over to using a global variable, simply becauseâŚI donât know. lol
Iâm always trying to make pistons smaller (even if only visually), and I thought using a variable there might be cool.
I confirmed, by trying it with the still working âcombinedâ version piston, that it in fact does NOT work with that in there like that (so I changed it back).
However, apparently, that issue was not the only thing keeping it from working, because itâs still not working after changing it back to the list format.
Anything else seem wrong?