Presence and not presence triggers?


1) Give a description of the problem
Status change to “NOT PRESENT” triggers “PRESENT” trigger

2) What is the expected behaviour?
Piston should only trigger when presence sensor arrives at location.

3) What is happening/not happening?
Piston triggers when leaving and arriving. Am I missing something? Am I not understanding the presence triggers correctly?

4) Post a Green Snapshot of the pistonimage

5) Attach logs after turning logging level to Full

8/6/2019, 6:39:22 AM +227ms
+1ms ╔Received event [360 David].presence = not present with a delay of 112ms
+80ms ║RunTime Analysis CS > 17ms > PS > 46ms > PE > 16ms > CE
+82ms ║Runtime (41083 bytes) successfully initialized in 46ms (v0.3.10e.20190628) (80ms)
+83ms ║╔Execution stage started
+89ms ║║Comparison (string) :8976d4192664b102e8a7b44e18f56ca8: is_not (string) :d98a1f9ba306055ef1981913525b1827: = true (2ms)
+90ms ║║Condition #8 evaluated true (4ms)
+91ms ║║Condition group #null evaluated true (state did not change) (5ms)
+103ms ║║Comparison (enum) not present changes_to (string) present = false (1ms)
+105ms ║║Cancelling condition #4’s schedules…
+106ms ║║Condition #4 evaluated false (13ms)
+107ms ║║Cancelling condition #1’s schedules…
+107ms ║║Condition group #1 evaluated false (state changed) (14ms)
+109ms ║║Cancelling statement #16’s schedules…
+113ms ║║Executed virtual command setVariable (1ms)
+117ms ║║Calculating (string) 360 David + (string) has Arrived Home! >> (string) 360 David has Arrived Home!
+122ms ║║Executed virtual command sendNotification (2ms)
+124ms ║║Executed virtual command wait (0ms)
+126ms ║║Requesting a wake up for Tue, Aug 6 2019 @ 6:43:22 AM CDT (in 240.0s)
+129ms ║╚Execution stage complete. (46ms)
+131ms ║Setting up scheduled job for Tue, Aug 6 2019 @ 6:43:22 AM CDT (in 239.996s)
+137ms ╚Event processed successfully (137ms)


Most triggers will execute the piston on both the trigger, and the opposite of the trigger. It is the conditions below that dictates what commands to execute.

Another way to say this:
If you are subscribed (lightning bolt) to Hall switch, then when the Hall switch turns on or off, the piston will execute.


Ok well that makes sense. Ill have to keep that in mind.


From an old post of mine:

What often confuses is, most triggers will execute a piston, even when it is the opposite of the trigger.

For example, if you have a simple piston:

    IF Bulb-A's switch changes to on
        Then do "Something"
    END IF
    Send SMS notification "Test"
end execute

The “Something” will only happen when the bulb turns on, but the SMS will send even when the bulb turns off. This is because when a piston is subscribed to a device’s attributes (such as Bulb-A’s switch above), then whenever that attribute changes (in either direction), the entire piston will run top to bottom, and execute any code that the conditions allow.


Here it is in action.