dukedave
(Dave Tapley)
March 18, 2017, 8:20pm
1
What’s the significance of the color / filled (or not) state of the dot to the left of the comparisons?
wjarrettc
(Jarrett Campbell)
March 18, 2017, 8:23pm
2
I believe the unfilled dots are “state comparisons” whereas the filled dots are “triggers”, meaning the state has to change in order for these to be true.
For instance “If Light is Off” could be true any time the switch is in the off position but “If Light changes to Off” is only true once, when the light turns off.
I’m sure there are other experts here that can further detail why this is important in CoRE.
2 Likes
c1arkbar
(Dustin Clark)
March 18, 2017, 9:28pm
3
What @wjarrettc said is correct. The empty dots are conditions. The full dots are triggers.
Here is an excerpt from http://thingsthataresmart.wiki/index.php?title=CoRE#Conditions_.26_Triggers
Conditions & Triggers
There are two kind of conditional units in a Piston.
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.
Triggers:
Evaluate 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.
If you have any questions I would be happy to explain it further.
3 Likes