Please help me avoid getting spammed by notifications! :)

#7

Maybe @WCmore can educate us here. My thought process is probably flawed. I realize that the blinking will “trigger” my piston at the blinking rate. But my piston SHOULD wait for 5 minutes before any more PUSH notifications. Then, after the WAIT of 5 minutes, the blinking will trigger the piston again. Then another PUSH and WAIT. If the blinking stops during the WAIT, then no more trigger or PUSH. I’m open to any and all critique here.

#8

I just set it to what I think you are saying, shown below. I pulled the bucket to simulate blinking, and actually set it to 15 minutes instead of 5. Thinking this is the way we’d likely use it, and see how it goes. Well, I pulled it at 4:30, but at 4:45 I didn’t see any alerts… and even waited a few extra minutes. No notifications. I realize I set it to the wrong type of notifications! UGH. Testing again. Anyway, please take a look at the code to ensure it matches what your suggestion is before I continue. Thanks again.

image
image.png1178×608 28.4 KB

#9

I don’t mind stepping in for @WCmore and explaining even though I’ve provided themost perfect solution imaginable and am expecting a solution check any moment. Your idea is a little one dimensional and treats the piston in it’s completeness as a single rule. By logic, every time the button gets pushed the piston will wake up multiple times and want to trigger it, starting each time from the top, and again it sounds logical your 6 minute wait, IF it would work it only be by confusion, whereas my tried and tested solution doesn’t give any other choice than to work correctly, if you get what I mean. It’s kind of where math crosses over with meta-physics.

#10

@vPeteWalker that’s correct. 2 things, make sure the variable is set to false initially, or it won’t run. Either manually set it to false.
Or the first time you run the piston change it to
If variable IS NOT false.
then it will run.
then go back and edit it back to IS false

and for testing purposes.
ALWAYS use If variable stays true for 1 minute
then set variable to false.

You’ll see it work quicker, then after set it to 15 minutes.

#11

Another pro tip, my you’re really getting your moneys worth here, is Log to console.
Under your push notification, add Log to console “Variable set to true and push notification sent.”

Again under the set variable to true
do a Log to console “Variable stayed true for X minutes so set Variable to false”.

@vPeteWalker what kind of variable are you using? I’ve just had a closer look at your piston and the stays true trigger doesn’t have a lightening bolt next to it! so it wont run! It’s a boolean right?

20200606_232308
20200606_232308.jpg2851×1603 2.8 MB

#12

@vPeteWalker, all of your goals can be accomplished in a single block, using no @global variables, and without having to initialize the local variable.

Here is the basic structure I would use,
(although your line 25 should point to your button presses)

pic

What you cannot see in the pic above is I have TCP set to Never…

Edit: This post may be helpful as well. (auto-reset at 4am)

#13

To see it in action, I used the same code above,with a few extra log commands:

pic
pic.jpg489×557 48.2 KB

To test, I pushed the button many times during the 1 minute period, but notice all the action takes place at the very beginning, and after the full timer expires:

pic
pic.jpg615×565 61.8 KB

#14

That’s a good way to pass a piston to a beginner. Personally, with my human brain, I’m not a fan of double negatives, using my method will help the more you get into WebCoRE, and allows for more creativity and testing more complex pistons in the future. For example, when you define the boolean initially, if you leave it blank, and save the piston.
Below the piston, there will be an “edit” mark next to the local variable, and you’ll be able to set the boolean there, on the fly, without opening up and editing the piston.

20200606_233600
20200606_233600.jpg2851×1603 2.99 MB

#15

Well, @vPeteWalker joined us three hours ago…
(but even experts appreciate variables that work right out of the box)

I hate to be the bearer of bad news, but unfortunately, your pistons above will not work unless you resort to using a global, or re-structuring the piston some other way.

#16

What do you mean it won’t work unless I resort to using a global variable? :joy: I have loads of pistons running like this with local variables for years! For example…

musicc
musicc.png1178×4577 488 KB

#17

Sorry, but that logic you are using to trigger off of a local stay will FAIL if any of the other triggers touch this piston during that time period.

Using your example,

pic

Even if {Volume_change} stays false for 5 minutes, both of those commands will be aborted if any of the following happens within those 5 minutes:

  • Switch 52 changes to off
  • Switch 52 changes to on
  • Sensor 7’s contact changes to closed
  • Sensor 7’s contact changes to open

Which is why I would never recommend coding that way.

To summarize, OP’s sensor will spam the piston… and the extra triggers would break your idea here, @Alwas…

My suggestion would be to try the piston in this post.

#18

Ok, I understand that the OP’s sensor will spam the piston. But why doesn’t my piston work? Won’t those “triggers” be ignored until the wait is over?

#19

Triggers are never really ignored. They are either subscribed to, or not.
(although I guess a device will be ignored if it is not being “subscribed” to, LOL)

Perhaps this breakdown will help…

  • IF we are subscribed to a device’s attributes (IE: trigger Device’s switch), then
  • ALL switch changes from that device (in either direction) will trigger that piston
    (*cough* … as well as all other pistons with that same trigger)
  • Each of those pistons will execute (nearly) simultaneously
    (with each running thru the entire code top to bottom)

If we use the above as a foundation, we can write code to have different things happen on subsequent runs… but each event will still trigger that piston again at the top.

If you want one event to have multiple outcomes, it is up to us (the programmers) to make this happen.
(IE: using variables or other tricks)

… but it’s important to remember:

If we are still subscribed to a device’s attributes,
(IE: trigger Device’s switch)
then changing the wording of a piston will have ZERO impact on the number of times the piston will execute.

In other words, the number of times a piston will execute is entirely based on what device(s) and attribute(s) are subscribed to.

Any changes to the wording will only impact the flow or direction after the trigger comes in.
(not the trigger count)

TL;DR

No amount of coding in webCoRE will stop a trigger from coming in.
(other than perhaps Pause piston)

#20

Take this silly example:

IF GrandfatherClock's tick changes to tock
Then
     Take a shot of espresso 
     Wait 5 hours
END IF

I would be bouncing off the walls 6 seconds
(or :coffee: :coffee: :coffee: :coffee: :coffee: :coffee: shots)
after this piston started!

#21

As you know, I struggle with WAITS. SO, during a WAIT, I presumed that any events that act on a subscribed trigger would be ignored during that piston’s WAIT. So in the OP situation, the blinking light would be “ignored” during the WAIT. Then, once the WAIT was finished, if the trigger fired again (the light was still blinking), a PUSH and another WAIT would occur, and the process repeats until the light stops blinking.

#22

OK, I see how you are…

You like my silly example, but had no interest in my insightful and in-depth post above it.

LOL

All jokes aside, if a blink from his light triggers the piston once…
then every blink will trigger that piston
(no matter how the piston is worded)

This concept has nothing to do with waits really. Each time the “Device’s attribute changes”, the piston starts over at the top, and I drink another :coffee:.

Just to clarify… This does not happen!
Each event will fire again from the top regardless.
(even the opposite of the event will trigger at the top)

#23

Ok, yes, I did favor the espresso code…:grin: So what happens to the piston that has the wait when a new trigger comes in? It’s cancelled and the new execution takes its place?

Ie, the piston that is waiting is not placed into a queue and finish later. That execution is cancelled, and the “new” one (from the most recent trigger) takes its place. Of course unless the programmer codes for such an event.

#24

The same trigger always starts over at the top…

If you are asking what happens to the previous instance that was WAITING?

Well, that answer depends entirely on the wording of the code… and can easily be an hour long conversation, with exceptions to nearly every statement, LOL

But the quick & dirty answer usually lies with TCP settings.

#25

Even though it feels like exactly what I was using in a previous iteration, but I’m happy to try! Also testing out @Alwas 's solution at the same time. I thank you both very much.

#26

Sorry to get a bit off topic on your thread…

Please only test out one piston at a time.
All other related pistons should be paused when testing a new piston.
(so they don’t unintentionally step on each others toes)