Trigger Piston When Device Is Target of Command

#15

Thanks lflorack, but command optimization being set to disabled does not make a difference.

#16

Making this change doesn’t work as you expected for your piston? I’m confused. I must be missing what your issue in this instance is then.

#17

Here is my TEST piston and my Virtual Switch is “Dimmer 8”. If “Dimmer 8” is already on and I tell my Amazon Echo to turn on “Dimmer 8”, nothing happens. I can repeat the command multiple times and it does nothing. But then when I tell my Amazon Echo to turn the switch off, the piston works and when I tell it to turn it back on, it works. It just doesn’t work if the virtual switch is already in the state you’re telling the Amazon Echo to change it to.

I have the same piston setup in the old CoRE system and it works perfectly, even if the virtual switch is already in that state.

Virtual%20Switch%20Issue
Virtual Switch Issue.png1178×692 60.9 KB

#18

If the virtual switch is on and you send it another on command, I would expect nothing to happen since it’s already on. Why would you expect it to do something else (i.e., turn off) if it’s already in the on state and that’s what your telling it to do (i.e., turn on)?

#19

As I mentioned earlier, in CoRE, if the switch was already on and I told the Amazon Echo to turn the virtual switch on, it would still see this as “Changes to on”. But when I started switching pistons to webCoRE, it didn’t work the same way. So if we can’t change it to the way it was before with CoRE, it would be nice if we could at least add an option to the condition. Here’s what I suggested earlier:

PROPOSED CHANGE (to webCoRE): When adding a condition to a piston for a virtual switch, add a checkbox for “change attempted”. That way, if you try to change a virtual switch to ON and it was already ON, or try to change a virtual switch to OFF and it was already OFF, it would still trigger the condition (just like it used to in CoRE, but doesn’t currently do in webCoRE).

#20

…in the meantime…

What I do for Simulated Switches is let the piston return the switch to the previous state. IE:

IF Dimmer 8's switch changes to on
Then 
    Change color etc
    Turn off Dimmer 8
END IF

This resets the SimSwitch for the next use.

Unfortunately, this only lets Alexa trigger one direction per SimSwitch.

Another advance trick that I sometimes use is with a “Simulated Dimmer Switch”.

IF SimDimSwitch's level changes
Then
    IF SimDimSwitch level is greater than 50%
    Then
        Set color to Red
    ELSE
        Set color to Blue
    END IF
END IF

This way, you can say:
“Alexa, set switch to 80%” to turn the light red, and
“Alexa, set switch to 20%” to turn the light blue.
Of course, you can build upon this with more colors, if you can remember which numbers equals which colors.

Two caveats with this method:

  • Avoid using zero
  • You can not ask for the same number twice in a row.
#21

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?

#22

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?

#23

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:

#24

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

#25

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)

#26

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.

#27

Now I get it. Thanks.

#28

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.

#29

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.

#30

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

temp

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.

#31

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.

#32

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.

#33

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”.

#34

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.