1) Give a description of the problem
Says piston won’t ever fire in its own.
2) What is the expected behavior?
Trying to store devices in device list variable and have them trigger the piston when actions take place
3) What is happening/not happening?
No triggers - lightning bolts
4) Post a Green Snapshot of the piston
Can I ask why you are storing your devices into a variable?
Why not just define the devices in place of your variables and use ‘any’.
In your ‘If’ statement you selected variable instead of device for both {motionList} and {contactList}. You need to change those both to device so instead of:
you should have
This should be apparent in the snapshot, but unfortunately webCore does not yet display the “Any of” or “All of” information in the snapshot view when device variables are used.
@bobbles It doesn’t really apply to this piston, but for larger or more complex pistons, I nearly always store my device lists in variables as it vastly simplifies adding, removing, or changing those lists. I’ve done the same thing where I use presence sensors, as I’ve gone back and forth a few times between using ST, webCore, and simulated presence (Tasker/AutoLocation ) sensors. By using variable references, I don’t have to search the whole piston to find and edit every instance where the device is referenced. I tend to agree that in this particular instance, a direct reference would be cleaner.
Still having trouble with this piston - for some reason the only that happened was my lights turned red. White bulbs never came on (first set of lights), RGB bulbs never flashed and went right to red plus never got the sms notifications. Any advice?
In this instance, it shouldn’t make a difference. I’d probably leave it the way it is to avoid having to use a container group for the existing triggers.
Yes I agree and I put them in global variables. As these are local variables you have to go in the piston anyway to change them. For me, and perhaps it’s just me, why over complicate things.
@GRClark are you waiting 750 seconds for the lights to change?
Try changing your with TCP to never.
Of course, if you change global variables and those variables are used as triggers in any pistons, you have to open and re-save the pistons to update the subscriptions.
Not sure I was waiting that long because that was supposed to be 750 milliseconds and didn’t even notice.
What’s “with tcp”?
Ah OK. You’ve defined 750 seconds.
To be honest. I’ve never had much success with lights changing that quickly.
I have a Christmas piston that I change the lights every 10 seconds. I’ve found less than 5 seconds unreliable.
TCP is Task Cancellation Policy.
Click on the ‘WITH’ then the settings cog at the bottom.
Basically with it set to default if the piston changes back to false from true, the tasks will cancel.
So in your case as you have used ‘changes’ (which is a trigger) it will change back to false after around 10 seconds after it has changed to active and become true.
Therefore the light will turn on red, the 750 second wait will start but will cancel after around 10 seconds as the piston has become false again. If you set TCP to never, then the tasks will not cancel, your 750 second timer will mature as will all subsequent tasks.
I hope that all makes sense. 
PS. A red ‘N’ will appear next to the ‘with’ if set to never.
I would. It won’t hurt to do it.
BTW, if you have TCP set to NEVER, and a wait set in a task that is counting down and the piston has turned false, if the piston should become true again, the tasks reset.
So in the piston below,
When motion becomes active and lux is below 7, the tasks will start (piston is true) and continue when the piston becomes false because of TCP being set to never. If it was set to default the wait would stop when motion became inactive and the light would never turn off, until the motion sensor was inactive for 90 seconds or illuminance goes greater the 7.
If set to never and motion should be detected again after, say, 60 seconds, the piston would become true again and the tasks would start afresh from the top.
So in this case if motion was continually being detected for 30 minutes, the light would never turn off.
Hope this example explains it a bit more on how TCP works.
You were right. That fixed it! Only thing is not all the lights came back on after the flashing - maybe a wait command would fix that? Thanks for your help as I’ve never even touched that setting and hope I never have to again.
