Trigger Piston When Device Is Target of Command


First, I’d like to thank everyone for their workaround and suggestions. I really do appreciate it! But all of the workarounds I’ve used in the past and the ones suggested here for Virtual Switches either don’t work exactly as I’d like them to or really complicate my pistons.

Does anyone know how to submit an enhancement request to the developers of webCoRE?


Before you post here, I have to ask…

Are you creating Simulated Switches by going to IDE > My Devices > New Device
- or -
Are you creating Virtual Switches thru some app?


My virtual switch was an Alexa switch that I created a long time ago. So, just to be sure that wasn’t the problem, I logged into the IDE and created a new “Simulated Switch”. I then updated my test piston to use the “Simulated Switch”. I tested the new switch using my Amazon Echo and I still had the same issue. If the switch is already on and I tell my Amazon Echo to turn it on, the piston does nothing. But if the switch is off and I tell my Amazon Echo to turn it on, it works perfectly. In CoRE, it worked either way. :frowning:


@SrLANGuy, Hmmm, that is what I thought command optimization was for. I will be interested in your solution. :slight_smile:


This is interesting… I did not realize that CoRE actually could see a change when there was none. (My time with CoRE was short-lived, because I upgraded to webCoRE shortly thereafter)

Here in webCoRE, the logic makes sense to me. When your trigger is “IF device changes to on”, it can only fire a piston if it changes from something else to on. Thankfully, there are many ways around that in webCoRE.

Pro Tip:
It is actually possible to have CoRE and webCoRE installed at the same time… and as long as you don’t program conflicts, they can work together.

That being said, I would encourage you to use one of the tried and true methods here in webCoRE… (even if it means slightly different coding logic than you are used to)


Command optimization forces webCoRE to send a command regardless of the current state of the device. The trick with @SrLANGuy’s piston is he wants a piston to see ‘on’ changing to ‘on’ as a change in the switch… Yet there is no change.


Now I get it. Thanks.


I’m glad you figured it out because I was confused on this (easily done I think). CoRE was a great tool but, I, like you moved quickly to webCoRE since it is definitely more powerful. In this case at least, I also think it’s more logical too.


That’s incorrect!

I have some virtual switches in SmartThings which are made visible to my Amazon Echo using the “Amazon Echo” SmartApp. This allows me to tell Alexa to turn these virtual switches on or off. In CoRE, I could have a piston that says “If the switch turns on, perform these actions”, but “If the switch turns off, perform these other actions”. Regardless of the current on/off state of the virtual switch, the piston would take action based on what I told the switch to change to. So if I said “Alexa, turn on VirtualSwitch1” and that switch was already on, it would still perform the actions. And if I said “Alexa, turn off VirtualSwitch1” and the switch was already off, it would still perform the other actions. But in WebCoRE, if the switch is already in the state I tell Alexa to change it to, the WebCoRE piston does nothing.


I apologize that you do not like what I have to say, but I can assure you that your piston with this trigger:


will only trigger when that device CHANGES TO on…
Meaning it has to be something else to begin with…
When it changes to on, the piston will execute.

To me, this is logical, and makes total sense.

Perhaps the code in CoRE works differently… I don’t know.
I stopped using CoRE once I discovered the power in webCoRE.

For what it’s worth, I would love for your idea to be implemented here in webCoRE.
IE: IF SimSwitch receives an on command, Then do stuff

It would simplify many of my pistons.


My apologies @WCmore! I should have been clearer with what I was trying to say. In one of your posts you wrote “The trick with @SrLANGuy’s piston is he wants another piston to see ‘on’ changing to ‘on’ as a change in the switch… Yet there is no change.”. The part that I was saying was “incorrect” was that I don’t have two pistons involved here. The Amazon Echo tries to flip the virtual switch and I’d like my WebCoRE piston to act on that like my old CoRE piston used to. Again, I apologize for not making that clearer and I truly appreciate all of the help and feedback everyone has provided.


No problem at all. That was a typo on my part. I meant to say:
“he wants a piston to see ‘on’ changing to ‘on’ as a change in the switch… Yet there is no change”

I will correct that old post now.


I submitted the following Feature Request:

I requested that when adding a condition to a WebCoRE piston, it would give a new selection under “What kind of comparison?” so I could select “attempted change to” instead of “changes to”.


I did something similar, but I created two virtual switches, one to represent the “ON” state, and one to represent “OFF”. I then used code like yours to reset the switches after use, essentially making them momentary switches. This allows for the repeated reuse of the same switch, at the cost of losing state - I can turn the room “ON” again and again, triggering associated actions, but I cannot programmatically tell if the room is “ON” or “OFF”… though I suppose I could track that with a persistent global variable, if I felt the need to.


Maybe I am missing something. But wouldn’t that be the same thing as just resetting the switch to off within the piston as @WCmore suggested and just re-using that switch?


I am having a similar dilema. I have configured a simulated switch in smart things when it is turned on smart things tells harmony to turn on the TV and vice versa to turn it off. But if you tell google to turn on the tv the switch is turn on if you use the remote to turn off the TV the switch remains on. the next time you tell google to turn on the TV the the command doesnt trigger the piston becaue the switch is already on.
One solution is to get a plug with a voltage draw reading and plug the TV into it. If the voltage drops below X then set the TV simulated switch to off, thus resetting the switch. Thought I would post this as a possible solution to your problem.

Another posible solution is using a button instead of a switch. Their is not state read you would simple tell alexa or google to trigger the button name for example “Hey Google, Trigger TV”. The problem with this is that you wont have a state reading. This becomes a problem in a case like mine where if I tell google to turn on the Theater I want to turn off the TV if it is on.

This last solution is a maybe
Create two switchs with the same name and give your alexa or google home access to both swtches.

Switch A initial status = on
Switch B initial status = off

Call both switches the same name lets say TV

Command to google

Hey Google turn on TV

Switch A (named ‘TV’) stays on

Switch B (named ‘TV’) changes to on


If TV (switch a) or TV (switch b) ANY OF changes


Set switch a = on

Set switch b = off

The only concern here is how will google react to having two devices with the same name?


just tested with google, it looks like it will work. Google responds by saying okay turning two things on. going to draw up the test piston now

Created Piston, It works see attached screen cap of piston. Its a little complicated and required quite a bit of debugging so be ready, of course that was primarily becaue I was configuring it for a TV.

Added Variable to prevent re-trigger when piston sets value. This will be needed.


I have the same problem with a group of 3 bulb. Did you find a solution?


Also looking for the solution to this problem. Does anyone have a solution?


For this issue I just use Alexa groups for each area I wish to control… no need to mess about with pistons or virtual switches.

For manual control via a dashboard, I just have two simulated buttons for each area , all on and all off, thus no need to worry about states.

I found that trying to sync a simulated switch with multiple lights, whilst possible, was clunky and prone to feedback loops if the switch was toggled too quickly.