The first piston pictured below is a typical announcements piston that I use. As you can see when a trigger is activated, instead of sending an announcement to a bunch of speakers, it just sets a single global variable to a unique message.
Update to 2nd Piston below
I have created a second global variable to trigger the piston. This is because if an action occurred multiple times WC would not see the updated variable as a change, since it was updated to the same data. Such as, The back door has opened. So, I would only receive the message once while there door could have open and closed multiple times. So, now the other pistons update the MSG variable as well as update the pistonTrigger variable with the variable $now.
The second piston pictured below is my speaker control piston. What this does is set up audio zones based around my echo devices. These zones have different conditions to determine if the zone is active or not. The piston is triggered by the change of the single global variable. When the variable changes a snapshot of the piston is taken and then executed. If a zone is active, then that zone receives the announcement. If it is inactive, then no announcement.
Due to the snapshot (this is a built in function of how WC works) I can a multiple actions occur at very close intervals, they never ever happen at the exact same time, and the unique message of the variable is preserved for the announcement.
Echo Speaks uses the built in que system to receive, store, and play the announcements in order.
This gives me a few benefits. If a single speaker is in 10 different announcement pistons and I want to change how that speaker announces, then I only update the control piston… not all 10 of the others, thus making maintenance very easy indeed.
