SmartThings Community

CoRE - Get peer assistance here with setting up Pistons

corelogic
core
pistonmaster
makemypiston

#5772

I am new in Core.
I have a simple scenario, but i dont know to configure it.
When Routine … runs
then a switch turn on vor 1600ms and than turn off the switch.

Thats everything
Can anybody help me please with the correct piston?


(Jay) #5773

Use a basic Piston.
IF - Routine xxx was executed
THEN - Using xxx switch, turn on, wait 1600ms, turn off


#5774

I would like to have Alexa say something after a piston is fired, is it possible to use Simon Says in CoRE?

Thought I saw a way to do this while creating another piston but can’t seem to find it now.

Thanks you!


#5775

Hello everyone :slight_smile:
New to CoRE and digging it so far.
Can someone help with this basic piston that I cant wrap my head around?

I want to control (2) Phillips hue light bulbs at the same time, so when I change one, the other one changes to same hue, and level.

Thoughts?

:slight_smile:


(Ron Talley) #5776

I am new to using variables but I thought this would work. Instead of it giving me the name of the specific device name, it gives me the string name such as a bunch of letters and numbers…I’ve used this on other pistons and it works correctly.

What could be the problem?


#5777

Have you checked out the Trend Setter app? It might work better for your case. It can be done in CoRE but there will be a noticeable delay.


#5778

I’ve seen this mentioned before but not sure if it’s on same device type, I don’t remember if there was an exact solution. Just for testing/workaround, I would do a save matching device to variable and use the variable in the push notification.


(Bob) #5779

Yes I get this and queried it some time ago.
I believe the answer was that is a known issue where the GUID is being presented instead of the device name.
No solution though.
@ady624?


#5780

Thanks! I will check out Trend Setter.
I would like to know how to do this in CoRE as well :slight_smile:


(Ron Talley) #5781

So what about the { } thingies? Are they needed? I am assuming they are. What does the { } do exactly in regards to variables?

You are right. I would have to drive to Harris Teeter to see if it works! :grin:


#5782

Yes, just give it a variable name, Who would work. If you want the variable available to other pistons, then prefix it with @ to make it global.

In your Then action, instead of $currentEventDevice, use your new variable name, @Who or Who, whichever you used in the IF.

I’m curious to see the result as it’s hard to simulate.


(Craig) #5783

With first light bulb, save state to variable “FirstBulbState”
Then with second bulb, load state from variable “FirstBulbState”

Here is a motion piston I wrote that saves the states of two groups of lights when motion is detected, and then restores them after motion stops.


#5784

Yep, the {} curly brackets are needed in the notification Task. That tells CoRE that you’re sending a variable and will be filled with the current value on execution.


#5785

Cool! I will give this a try. Thank you. :slight_smile:


(rwcrowe) #5786

All and @ady624

Can I get a confirmation of my understanding of the below settings:

  1. Cancel on condition state change

This is only for the state of the trigger/condition that it is configured on correct ?

  1. Cancel on piston state change

This is the state (True/False) of the WHOLE (all triggers/conditions) piston ?


(Craig) #5787

That’s my understanding of it, and the behavior I’ve observed with my own pistons.


(Ron Talley) #5788

I also need confirmation.

I thought Cancel on condition state change meant that if any condition in that “argument” (i.e. “If blah blah blah”) changed then the action would cancel.

So if I have a group that says:

If motion 1 stays inactive for xxx
OR
If motion 2 stays inactive for xxx

Either 1 of those would make the group “argument” true so the “Cancel on piston state change” would not cancel whatever action is assigned unless both becomes active. However Cancel on condition state change would cancel the action because it would only take one condition to change in order to satisfy the cancel…

This is specific to each argument and not the entire Piston correct?


(Michael Hess) #5789

Correct if I read you right.

Think of it like this:

Latching Piston
If
Then
-----State Change----
Else
Then

If the If and Else flop, you have a STATE change.

If a condition within any of those changes, you have a CONDITION change.

If that helps…


(Craig) #5790

The easiest way to see it in action is to watch the dashboard. The vertical line at the far left will change from red to blue when the PISTON state changes…with blue being true and red being false. The inner lines span condition groups, and they will change when the CONDITION GROUPS change states. The small, right-most bars are for each condition, and will change when that single CONDITION changes.

If you have an action on a group or condition with “cancel on condition state change”, it will cancel if the bar spanning it’s parent group (or single condition) changes. But if it’s set to “cancel on piston state change”, it will only cancel when the left-most (piston) bar changes. I’ve found that closely watching those bars in the dashboard while testing and troubleshooting your pistons can provide some valuable insight.

At least that’s what I see when tracking mine. :slight_smile:


(rwcrowe) #5791

Good tip @calansvc