No, nothing major… A few glitches here and there, but nothing major.
I have a text to speech playing to a speech synthesizer speaker using the askAlexa/CoRE integration that is acting flakey. Only the one, everything else tts to that speaker is working.
I can’t get the capture/restore you work right.
And I have a bathroom fan that refuses (intermittently) to turn off after five minutes.
Oh, and I’m experiencing some long delays on my master bedroom piston.
When adding a task, when you choose “Control” from the “Entertainment” section, it displays an error.
With piston restrictions…
We have on / off switch but I’m looking for if contact is open…is that doable?
Maybe…
If you manually control the fan from the DTH, does it always work?!
It looks like $index still can’t be used for anything within the loop because nothing happens when the piston below is executed.
Can you set the wait to 1 minute and check the dashboard within cycles?
Thank you, fixed.
Okay. lots of people waiting for v0.1.090.20160613 - Beta M1 - First beta release
45 days in, moved on to first beta 
Yahoo! Great job! That’s amazingly short!
Wait. You cant do that! We need to have a management meeting, Look over your presentation, have a code review, assign action items. Then we will meet again in a week to review the status of the action items and then schedule another meeting to see how we are progressing and decide if we should schedule another meeting to see if we are Beta ready.
When I go to create the web request it ask for the following:
URL
Method (Get, Post, Put, Head, Delete, Patch or Options)
Content (json, x-www-form-urlencoded, plain)
Body
Hope this helps.
I get this every time I add a condition and I get around it by cycling the nagate the condition switch. I have everything filled out. It also works out ok if I back out using top left arrow. My condition will add ok. I just wonder why the red flag?
I added a 15 seconds wait within the if block after beep and changed the loop delay to 60 seconds.
The $index variable shows the correct value for each execution of the loop, but the beep and wait within the if block never get executed.
Somebody close this and open a [BETA] thread, please. In any case, everybody, please upgrade and let this thread rest in peace! It’s getting impossible to find anything…
Yes, it does
Let me get a powerpoint real quick and schedule a short meeting during which we decide when we schedule the meeting with the investors. Done, here is the first slide:
I think I killed it!
Known Android ST app issue. We are hoping ST will fix it soon.
I second this request, this is the feature I was asking about a few thousand posts back. I believe all you need to do is exposed an endpoint that will allow a piston to be triggered.
Forgot about it, but here’s some documentation I wrote last night, for whomever is taking care of the documentation. It needs to be translated to plain English, please:
CoRE is a rule engine that takes events and states as input and executes actions based on the relationships between these events and states. CoRE is the main application that hosts Pistons. The piston is a decisional unit in CoRE that does the heavy lifting of subscribing to events, performing conditional evaluation, and executing required actions. There can be as many pistons as you need inside CoRE.
#Piston state
Pistons have a boolean state that can be used to affect how actions are performed or cancelled. This state is decided during the EVALUATION cycle of the piston. For details on how the state is determined, please see Piston modes.
#Piston cycles
In CoRE, each piston has 4 cycles:
- IDLE - the piston is waiting for events that can put it in motion
- EVALUATION - the piston has received an event and is now looking at all the conditions the user has layed out, evaluating each as an individual and also all as a whole. The piston state is decided at this time.
- SCHEDULING - the piston has figured out which actions need to be executed as a result of the evaluation and is adding them all to an execution queue.
- EXECUTION - the piston is now done with evaluation and scheduling, so it now executes all queued actions that are due.
#Piston modes
- Basic Piston
This is the simplest piston in CoRE. It allows for one conditional set and one action set that is executed when the conditional set is evaluated as true:
Format:
IF (conditions) THEN (actions)
State:
The state of the basic piston is deemed TRUE if (conditions) evaluates as true, or FALSE otherwise
Actions:
The (actions) are executed if (conditions) is true
- Simple Piston
This is the very similar to the basic piston, but with a twist. It allows for one conditional set and two action sets, one that is executed when the conditional set is evaluated as true, and another that is executed when the conditional set is evaluated as false. Only one of the two is executed during any given run.
Format:
IF (conditions) THEN (actions1) ELSE (actions2)
State:
The state of the simple piston is deemed TRUE if (conditions) evaluates as true, or FALSE otherwise
Actions:
The (actions1) are executed if (conditions) is true, otherwise (actions2) are executed if (conditions) is false
- Then-If Piston
This is a dual piston, because it supports two conditional sets. It allows for one conditional set to allow a second conditional set to be evaluated only if the first one was true.
Format:
IF (conditions1) THEN (actions1) THEN IF (conditions2) THEN (actions2) ELSE (actions3)
State:
The state of the Then-If piston is deemed TRUE if both (conditions1) and (conditions2) evaluate as true, or FALSE otherwise
Actions:
The (actions1) are executed if (conditions1) is true, (actions2) are executed if both (conditions1) and (conditions2) are true, (actions3) are executed if either (conditions1) or (conditions2) is false
- Else-If Piston
This is a dual piston, because it supports two conditional sets. It allows for one conditional set to allow a second conditional set to be evaluated only if the first one was false.
Format:
IF (conditions1) THEN (actions1) ELSE IF (conditions2) THEN (actions2) ELSE (actions3)
State:
The state of the Else-If piston is deemed TRUE if either (conditions1) or (conditions2) evaluates as true, or FALSE otherwise
Actions:
The (actions1) are executed if (conditions1) is true, (actions2) are executed if (conditions1) is false and (conditions2) is true, (actions3) are executed if both (conditions1) and (conditions2) are false
- Or-If Piston
This is a dual piston, because it supports two conditional sets, with a logical OR between them
Format:
IF (conditions1) THEN (actions1) OR IF (conditions2) THEN (actions2) ELSE (actions3)
State:
The state of the Or-If piston is deemed TRUE if any of (conditions1) or (conditions2) evaluate as true, or FALSE otherwise
Actions:
The (actions1) are executed if (conditions1) is true, (actions2) are executed if (conditions2) is true, (actions3) are executed if both (conditions1) and (conditions2) are false
- And-If Piston
This is a dual piston, because it supports two conditional sets, with a logical AND between them
Format:
IF (conditions1) THEN (actions1) AND IF (conditions2) THEN (actions2) ELSE (actions3)
State:
The state of the And-If piston is deemed TRUE if both (conditions1) and (conditions2) evaluate as true, or FALSE otherwise
Actions:
The (actions1) are executed if (conditions1) is true, (actions2) are executed if (conditions2) is true, (actions3) are executed if either (conditions1) or (conditions2) is false
- Latching Piston
This is the most complex piston in CoRE. It acts as a bi-stable (or flip-flop), flipping it’s state based on two independent conditional sets.
Format:
IF (conditions1) THEN (actions1) BUT IF (conditions2) THEN (actions2)
State:
The state of the latching piston is a bit more complex. It only changes under certain circumstances. It will change to FALSE when and only if it is TRUE and (conditions2) is true. It will change to TRUE when and only if it is FALSE and (conditions1) is true. If both (conditions1) and (conditions2) are true, the state flips. If neither of (conditions1) nor (conditions2) is true, the state remains unchanged.
Actions:
The (actions1) are executed if (conditions1) is true, (actions2) are executed if (conditions2) is true
- Follow-Up Piston
This is a simple piston, with a catch. It never gets evaluated on its own, it can only run when requested to run by an external source, such as other pistons, an Ask Alexa CoRE Trigger Macro, or an IFTTT request.
Format:
IF (conditions) THEN (actions1) ELSE (actions2)
State:
The state of the Follow-Up piston is deemed TRUE if (conditions1) evaluates as true, or FALSE otherwise
Actions:
The (actions1) are executed if (conditions1) is true, (actions2) are executed if (conditions1) is false
#Conditions and Triggers
There are two kind of conditional units in a Piston. Plain conditions compare the current state of a device to a given value, using a selected comparison, and determines whether that comparison is true or false. By contrast, a trigger evaluates an event that has just occurred, so it has one big limitation: within one conditional set, only one device/attribute pair trigger can be true at any given time, because events are processed one by one, in the order they were received. This means you should never use (trigger) AND (trigger) as this construction will always evaluate as false, unless the two triggers involve the same device and attribute (i.e. (Light.level changes to greater than 50) AND (Light.level changes to odd) would work and return true only if level is an odd number above 50)
Using conditions only
When no trigger is used, all conditions are allowed to subscribe to events and act upon receiving such events. This is the typical use of a piston, where the user builds a conditional set and when anything used in that conditional set changes, the piston will fire. All time conditions will fire their own events twice a day, when the time passes the two time points used in the condition. For instance, time is after 5pm has two time points, 5pm and midnight, as it is the equivalent of time is between 5pm and midnight.
Mixing conditions with triggers
When mixing conditions with triggers, conditions will take a secondary role of filtering out triggered events. Triggers will subscribe to device events, while conditions will not. So the construction (Door contact changes to open) AND (Time is between 5pm and midnight) will only be evaluated when the door “contact” attribute changes. It is worth noting that this construction will listen to “contact” changes, regardless of whether the door opens or closes. This is to allow your piston to have an ELSE statement and fire it once in a while. A good example on when to mix conditions and triggers is the “if I come home after 5pm, do this”. The conditional set would be (presence changes to present) AND (time is after 5pm) and it would only be true the user arrived home after 5pm. If we were to use a condition only construction, say (presence is present) AND (time is after 5pm), then the piston would fire whenever the user arrives/leaves home, at 5pm and at midnight. If the user was home at 5pm, the actions would execute. If the user arrived between 5pm and midnight, the actions would execute. If the user was home at midnight, the actions would execute. That is where a trigger helps, because it allows the user to specify which events can trigger actions, while still using other conditions to achieve their goal.
#Grouping modes
Conditions and/or triggers can be “grouped” into condition groups. When a condition group contains two or more conditions/triggers, the condition group needs to know how to evaluate the bunch, so that’s where the grouping method comes in. There are currently six grouping methods in CoRE:
- OR - All conditions/triggers are evaluated and the result is true if any of the conditions in the group is true
- AND - All conditions/triggers are evaluated and the result is true only if all of the conditions in the group are true
- XOR - All conditions/triggers are evaluated and combined together using eXclusive OR
- THEN IF - All conditions/triggers are evaluated in a sequence. Each action is evaluated only if the previous one was true. The group is true when all conditions are true
- ELSE IF - All conditions/triggers are evaluated in a sequence. Each action is evaluated only if the previous one was false. The group is true when any one condition is true. The following conditions are ignored once a condition is found as true, providing an effective SWITCH-CASE logical block.
- FOLLOWED BY - This is a ladder type evaluation, where each piston evaulation may advance the ladder to the next step, if that step is true. If the current step the ladder is at evaluates as false, the whole ladder is reset and the result is false. The result will be true only when the last condition is reached and that evaluates true, at which point the ladder is again reset and ready for the next cycle.
