How can I alter this to not receive 3 notifications?

#1

1) Give a description of the problem
I realize that when the triggers in this piston evaluate TRUE, they run the rest of the procedure. I have 3 triggers that will all eventually evaluate TRUE, so I end up with 3 SMS notifications. I just want 1 notification whenever at least 1 of the triggers is TRUE.

2) What is the expected behavior?
I get 1 SMS whenever one of the three triggers is TRUE.

3) What is happening/not happening?
I get a notifications each time a trigger is TRUE, which means I’m getting 3 SMS notifications.

4) Post a Green Snapshot of the piston

Piston
xnuzdmD.png1178x646

**5) Attach any logs
8/28/2018, 4:38:25 PM +68ms
+1ms ╔Received event [Home].time = 1535499506689 with a delay of -1621ms
+109ms ║RunTime Analysis CS > 18ms > PS > 50ms > PE > 41ms > CE
+112ms ║Runtime (41312 bytes) successfully initialized in 50ms (v0.3.107.20180806) (111ms)
+113ms ║╔Execution stage started
+523ms ║║Executed virtual command executePiston (395ms)
+560ms ║║Comparison (time) 59905595 is_between (time) 1535507580000 … (time) 1535460960000 = false (10ms)
+562ms ║║Condition #19 evaluated false (36ms)
+563ms ║║Condition group #17 evaluated false (state did not change) (37ms)
+565ms ║╚Execution stage complete. (453ms)
+566ms ╚Event processed successfully (566ms)
8/28/2018, 4:38:16 PM +582ms
+0ms ╔Received event [Home].mode = Away with a delay of 46ms
+73ms ║RunTime Analysis CS > 13ms > PS > 29ms > PE > 32ms > CE
+75ms ║Runtime (41304 bytes) successfully initialized in 29ms (v0.3.107.20180806) (74ms)
+76ms ║╔Execution stage started
+85ms ║║Comparison (string) :d26846a306a14622a8213c996cb4c9ce: changes_to (string) :d26846a306a14622a8213c996cb4c9ce: = true (1ms)
+86ms ║║Cancelling condition #4’s schedules…
+87ms ║║Condition #4 evaluated true (5ms)
+88ms ║║Cancelling condition #1’s schedules…
+89ms ║║Condition group #1 evaluated true (state changed) (7ms)
+91ms ║║Cancelling statement #2’s schedules…
+102ms ║║Executed virtual command executePiston (6ms)
+106ms ║║Executed virtual command wait (1ms)
+107ms ║║Requesting a wake up for Tue, Aug 28 2018 @ 4:38:26 PM MST (in 10.0s)
+112ms ║╚Execution stage complete. (36ms)
+113ms ║Setting up scheduled job for Tue, Aug 28 2018 @ 4:38:26 PM MST (in 9.994s)
+122ms ╚Event processed successfully (122ms))

#2

This piston has no SMS commands whatsoever…

#3

Sorry - I’m using this to trigger another piston (see the green snapshot) that has SMS commands. I think the issue here is that this parent piston is evaluating TRUE 3 times, thus triggering the child piston 3 times.

#4

I understand your flow much better now. Thank you.

I do something kind of similar, but I use a Simulated Switch to funnel many triggers into one.

I first created a SimSwitch called, “SomeoneIsHome”, then I do this in one piston:

IF Presence 1 changes to present
Then turn on SomeoneIsHome
End if

IF Presence 2 changes to present
Then turn on SomeoneIsHome
End if

IF Presence 1 & 2 are both not present
Then turn off SomeoneIsHome
End if

and then another piston is subscribed to that SimSwitch:

IF SomeoneIsHome changes to on
Then do Welcome Home stuff
End if

IF SomeoneIsHome changes to off
Then do Goodbye stuff
End if

I realize there are many ways to accomplish what you want, but this is great way to have multiple things only trigger once. An added benefit is you can use this SimSwitch as a condition in any of your other pistons. Such as: Turn on Fan only when SomeoneIsHome is on

Alternative methods would likely be sending arguments along with your Execute piston command, as well as adding many new lines of code in your “Check door status” piston.

You could also work with variables in the same piston, but you would be forced to add a bunch of delays to account for the two phones not triggering at the exact same moment.

The SimSwitch is my preferred method

#5

Interesting; I didn’t even think of using a simulated switch like that. What kind of overhead or delay does it add into the system? I’m not familiar with using arguments so that would be something to learn. I just learned about setting piston status today.

I’m curious as to how you have your system set up, or how you group things? I’m currently just using some main pistons to trigger a series of actions based on location mode at the moment. Not sure if this is best practice or anything. Any input would be appreciated.

#6

Typically less than 0.1 seconds from the time the SimSwitch is toggled…
(although the Presence Sensors may cause a delay in the previous step)
In all honesty, this SimSwitch method uses much less overhead than your pistons above. Currently, when both Presence Sensors leave at the same time, you are effectively running:

  • "Lock front Door" three times
  • "Check door status" three times

Arguments are a great advance tool. Normally, I’d say wait until you have 20-30 pistons under your belt first, but don’t be afraid to test out a sample piston if you run across one. They aren’t really that tough to grasp, especially if you see a few good examples.

If you mean which groups on my dashboard, then I just group by whatever category suits me. I usually keep tiles at the top, then important ones, followed by weather, then my testing category… then maybe my ‘behind the scenes’ category… Sometimes, I will rename the piston so it falls into a particular order within a category, but not always.

This is an excellent starting point. Don’t worry, creativity and complexity will come with time.

#7

Thanks!

Currently, when both Presence Sensors leave at the same time, you are effectively running … three times:

I definitely noticed this when I got 3 SMS messages and why I posted here because it needed to be altered to run only once. After fooling around with it some, I finally figured on an easy solution: add a ‘when not away’ condition. Pretty simple; not sure why I didn’t think of that from the beginning.

Arguments are a great advance tool. Normally, I’d say wait until you have 20-30 pistons under your belt first,

What would you use arguments for? I’m not sure I understand the utility of them.

If you mean which groups on my dashboard, then I just group by whatever category suits me.

i was meaning from the standpoint of the architecture. When possible, I’ve been creating generic child pistons that can be referenced from more than one parent piston. Not sure if there’s a better way to structure things?

#8

Arguments are great when one piston is gathering data, and wants to send that data to another piston to be read and acted upon. (can also be used to send data to phone or PC with a 3rd party app)

Great strategy. I do this with many pistons.

#9

I should do some more research and fiddling with the arguments idea, since I seem to be running a lot of parent:child pistons. Seems like it could be a good strategy for handling more complex scenarios down the line.

Thanks for your time, i really appreciate your knowledge1