I have a question and/or suggestion for using CoRE with askAlexa. I can set askAlexa up to trigger a CoRE piston, but the CoRE piston is conditional on some other events in the If section. Is there a way to run a piston on demand without any types of conditions being met other than askAlexa saying “run this piston”? Sort of like the DO button on IFTTT. If not, can this be added?
So I’m getting back to you on the Capture/Restore state to/from local. I’ve been having problems getting it to work. I know this piston doesn’t make sense linking my thermostat to the coffee switch but I just did it for testing 
Here are the logs. I’m not sure if this is what you need so let me know if you need something else. Thanks!
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: debug ╔═══ Done in 314ms
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: trace ║║░░ Removing any existing ST safety nets
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: trace ║╔══ Task processing took 182ms
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: debug ║║░░ Found 1 task due at this time
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: debug ║║░░ Processing command task [taskId:1, time:1466273017345, idx:1, marker:1466273017368, created:1466273017367, ownerId:2, data:[p:[[d:[heatingSetpoint], t:attributes, i:0]]], type:cmd, deviceId:cba75082-3228-4b8c-a2e8-fdf002e99433]
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: debug ║║░░ Scheduling actions for condition #-1. State did change.
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: trace ║╚══ Processing tasks (v0.1.09e.20160617)
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: debug ║║░░ Load from state: attributes are [heatingSetpoint], values are [heatingSetpoint:54]
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: info ║║░░ Executing virtual command loadStateLocally (37ms)
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: debug ║║░░ Primary IF block evaluation result is false
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: debug ║║░░ Scheduling actions for condition #1. State did change.
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: debug ║║░░ Setting non-matching device list to
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: debug ║║░░ Setting matching device list to
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: debug ║║░░ 
Function eval_cond_is for Outlet|Coffee’s switch [off] is ‘on’ returned false
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: info ║║░░ 
Simple Piston changed state to false
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: debug ║║░░ Event eligibility for the primary IF block is 1 - ELIGIBLE (triggers not required, event is a condition)
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: trace ║╚══ Processing event switch for device Outlet|Coffee with id a6062c4c-9a9e-496f-be8c-41ba3f4a152a, value off, generated on Sat Jun 18 18:03:36 UTC 2016, about 717ms ago (v0.1.09e.20160617)
adeb41d9-8429-49e4-a781-196088d08e60 2:03:37 PM: debug ╚═══ Received a primary block device event
adeb41d9-8429-49e4-a781-196088d08e60 2:03:24 PM: debug ╔═══ Done in 1518ms
adeb41d9-8429-49e4-a781-196088d08e60 2:03:24 PM: trace ║╔══ Task processing took 1509ms
adeb41d9-8429-49e4-a781-196088d08e60 2:03:24 PM: trace ║║░░ Removing any existing ST safety nets
adeb41d9-8429-49e4-a781-196088d08e60 2:03:24 PM: info ║║░░ Executing command: [Nest|Downstairs].setHeatingSetpoint([55]) (1137ms)
adeb41d9-8429-49e4-a781-196088d08e60 2:03:22 PM: debug ║║░░ Processing command task [taskId:3, time:1466272999900, idx:2, created:1466272994948, ownerId:1, data:[p:[[d:55, t:decimal, i:0]]], type:cmd, deviceId:cba75082-3228-4b8c-a2e8-fdf002e99433]
adeb41d9-8429-49e4-a781-196088d08e60 2:03:22 PM: debug ║║░░ Found 1 task due at this time
adeb41d9-8429-49e4-a781-196088d08e60 2:03:22 PM: trace ║║░░ Installing ST safety net
adeb41d9-8429-49e4-a781-196088d08e60 2:03:22 PM: trace ║║░░ Rescheduling time triggers
adeb41d9-8429-49e4-a781-196088d08e60 2:03:22 PM: trace ║╚══ Processing tasks (v0.1.09e.20160617)
adeb41d9-8429-49e4-a781-196088d08e60 2:03:22 PM: debug ╚═══ Received a time event
adeb41d9-8429-49e4-a781-196088d08e60 2:03:15 PM: debug ╔═══ Done in 343ms
adeb41d9-8429-49e4-a781-196088d08e60 2:03:15 PM: trace ║║░░ Installing ST safety net
adeb41d9-8429-49e4-a781-196088d08e60 2:03:15 PM: info ║║░░ Scheduling ST job to run in 5.0s, at Sat, Jun 18 2016 @ 2:03 PM EDT
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: trace ║╔══ Event processing took 147ms
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: trace ║║░░ Rescheduling time triggers
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: debug ║║░░ Scheduling actions for condition #0. State did change.
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: trace ║╚══ Processing tasks (v0.1.09e.20160617)
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: info ║║░░ Simple Piston changed state to true
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: debug ║║░░ Scheduling actions for condition #1. State did change.
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: debug ║║░░ Setting non-matching device list to
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: debug ║║░░ Setting matching device list to
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: debug ║║░░ Primary IF block evaluation result is true
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: debug ║║░░ 
Function eval_cond_is for Outlet|Coffee’s switch [on] is ‘on’ returned true
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: debug ║║░░ Event eligibility for the primary IF block is 1 - ELIGIBLE (triggers not required, event is a condition)
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: trace ║╚══ Processing event switch for device Outlet|Coffee with id a6062c4c-9a9e-496f-be8c-41ba3f4a152a, value on, generated on Sat Jun 18 18:03:14 UTC 2016, about 718ms ago (v0.1.09e.20160617)
adeb41d9-8429-49e4-a781-196088d08e60 2:03:14 PM: debug ╚═══ Received a primary block device event
Request: List global and local variables on top in the dashboard view so its easier to watch for changes when debugging.
Happy Father’s Day 
buy some more devices…
Ha! I did! I got two Phillips blooms today!
Can you guys please open issues in github for everything that seems to not work? It is much easier for me to track issues that way and I won’t be missing anyone. I mean, bring them here but don’t forget to open issues in github too. The post thread is much harder to keep up with…
Thank you
@ady624 Adrian - everything’s going well. Only a couple of RM rules to go.
I have a question about using different devices for alarm state in pistons. I’m not using SHM, but an Arduino-based interface (by @d8adrvn) from my Honeywell Vista panel to ST. I’d like to use that instead of SHM for alarm-based execution.
It exposes the following attributes:
I can load the custom attribute in CoRE and save it to a variable, but it would be easier if it was possible to reconfigure CoRE to recognize an alternate alarm (perhaps in main settings in CoRE?). I’ve learned that “Load State to Variable” does not work; it uses “Load Attribute to Variable”. Attributes of ∆system are one of disarmed, armedStay, or armedAway.
Thank you!
Is there a How To on that somewhere? Somebody got a link?
Think you have to register. Then you can select the ‘issues’ tab and put new issues in that section
I have a simple auto-lock that worked the first time but stopped working after… I updated to latest code today and but failed test.
In the countdown you’ll notice it say 02:36 when the stays only calls for 1 minute. The timer stopped after 1 minute though.
The Wait 15 seconds did not kick in.
You are right, @eibyer mistakenly AND’d two triggers. That will never evaluate true…
The 2:36 is because his computer’s time was almost 2 minutes off from internet time…
Ah, good info! Have to keep that in mind next time and now I will have to look at other pistons I’ve constructed!
Is there ever a time when ANDing two triggers would be valid? If not, then it would probably make sense to prevent this scenario in the UI, or at the very least displaying a warning to the user.
Yes, if both triggers hook on the same device/attribute pair, albeit not sure how “useful” that would be. The example below is pretty silly and any of the two triggers can be converted to a condition without changing the logical outcome…
Temperature raises above 75 and temperature changes to odd…
But a warning would definitely be welcome.
I’m not sure if this has been reported, or whether this is just user error, but I think I’m seeing some odd behavior. I have set up a global variable called @isDarkNow as a boolean. I created a Simple piston that switches this to true or false based on the sunset (offset -60) and sunrise time frame (between comparison). Then, I drive a number of other pistons off this variable.
For example, a hall light has two conditions: Did door open (motion) and isDarkNow. Pistons like this seem to work well. However, the one piston that solely depends on isDarkNow is a basic lighting piston that turns on some outdoor lights. When this piston’s only condition is on @isDarkNow, it seems that this piston never actually ‘triggers’ or something because none of my outdoor lights will be on, despite other pistons working (like the hall light I mentioned above).
However, replacing that sole condition with a datetime condition matching that of the variable’s piston’s condition (between sunset and sunrise), this does indeed work.
Is there some nuance I’m not understanding? It seems that maybe the piston depending solely on a variable’s value changing isn’t triggering or reacting correctly. I’m happy to post any debug info here if needed.
What version are you on and is that piston using a condition on @isDarkNow or a trigger (@isDarkNow changes)?
I’m on version v0.1.109.20160620
I’m not sure how to set up the trigger for a variable. It looks like I’m using a basic condition of “is true”. I don’t see the option to use a “changes” for a variable. I do use changes elsewhere, such as on motion sensors, but I’m not seeing it for variables.
Would CoRE be able to do this simple action that used to be part of motion controls?
I have a fan that I want to turn on from a motion sensor between 11:30PM - 3:00 PM, but I only want it to turn on once during that time (the first time it detects motion), so if I turn it off between 11:30PM-3:00PM that it will not turn on again until 11:30PM that night.
There used to be a motion control to “Do only once” as part of native ST, but I can’t find it in the new smart Light App.
Or if this is still part of ST, that would be even better. I want to try to stay away from CoRE until it is more flushed, WAF takes a hit when stuff stops working or breaks.
Latching piston.
IF
motion changes to active
and
time is between 11:30pm and 3pm
THEN
Using fan, turn on, only on piston state change
BUT IF
Time trigger happens at midnight
THEN (do nothing) <<< this resets the piston for next cycle ;)