This is another example of writing a piston, and not using trigger comparisons (only condition comparisons)
As mentioned previously, webCoRE for a piston that has no trigger comparisons, will subscribe events for the condition comparisons that use a device (physical or virtual).
This piston adjusts HE modes based on presence and time changes.
-
everyone has left - set mode to away
-
anyone home, set the mode to Day, Evening, Night based on time
This can make writing pistons very simple:
Few things to note on this:
-
notice all the comparisons are condition comparisons ( is )
-
webCoRE automatically subscribed to the presence devices and set all the time schedules (as seen with the lighting bolt)
-
This piston will always work whether run by presence event changing, time schedules occurring, or someone running the piston via test in the IDE, or 'execute piston' from another piston.
-
this piston could be made better by monitoring mode changes. By monitoring mode changes this piston could override any incorrect mode changes done elsewhere with the logic in the piston.
- this gets interesting, as the easy way to do this would be:
if location mode changes
-
but 'changes' is a trigger comparison
-
if you add a trigger comparison to this piston, then the [automatic] condition comparison event subscriptions would not occur, and the methods to address in the earlier trigger aggregation tip would apply
-
so your choice is add an
if location mode is Away
- to add another condition comparison or follow the other trigger aggregation tip suggestions
-
this piston still has yet another problem - what happens if the hub was down for some period of time, then came back online? Very likely the mode settings may be incorrect.
-
this can be resolved by checking for a systemStart. systemStart is an event the hub sends out each time it restarts.
-
systemStart is a trigger comparison, so now you are are into following the trigger aggregation tip suggestions
-
Resulting piston:
Some common questions
-
with all those event subscriptions, is this going to confuse the state?
- no for a couple of reasons:
-
The logic is consistent regardless of the reason the piston began execution
-
Events in HE occur serially
-
ie two events cannot happen at the same time. So even if a bunch of events fire, they actually are not at the same time (they may be close, but not the SAME time), and the piston will process them one after another in the order they occurred.
- This is why you NEVER : if a changes AND b changes -> it can never happen from the pistons view at the same time
-
-
- no for a couple of reasons:
-
if the events occur serially, could they still be processing in parallel?
-
HE allows this behavior. webCoRE by default for a single piston processes the events serially and processes the events in order of their occurance.
- there are ways for webCoRE to process in the same piston events in parallel. This is an advanced usage and typically incurs a lot more overhead on the HE hub.
-
Separate pistons can and do run in parallel. HE systems can currently run up to 4 pistons in parallel (4 cores in the cpu). HE has more threads available and webCoRE will use them as the HE OS allows.
-
-
does this have an efficiency problem?
- in this case no, the number of monitored events (subscriptions) matters less than the number of events generated in the system. In this case the actual event frequency is low.
References:
