Please help me avoid getting spammed by notifications! :)


#1

I have a Homeseer Flex sensor, along with SmartThings. I’m using it to detect when my dehumidifier is full, as the light sensor is aimed at the light of my dehumidifier. If it detects blinking, whether it is full (or when the bucket is removed) I want it to notify me. The way the Homeseer creates events is by button pushes. I am using the light sensor, so button 2 being pushed means it sees light, button 1 being pushed, means it does not.

What I’ve been struggling to do is to get notified only once maybe every 5+ minutes when this button gets pressed, but seemingly everything I try I get spammed with notifications constantly. I got an idea yesterday to create this using variables (and who knows if I did this right, but it does fire, it just spams me!). Please take a look at this, and kindly advise me where I went wrong.

Thank you so much!

6/6/2020, 3:28:22 PM +411ms
+2ms ╔Received event [Basement - HomeSeer Flex Sensor].button = pushed with a delay of 45ms
+82ms ║RunTime Analysis CS > 20ms > PS > 45ms > PE > 17ms > CE
+84ms ║Runtime (38395 bytes) successfully initialized in 45ms (v0.3.110.20191009) (81ms)
+85ms ║╔Execution stage started
+95ms ║║Comparison (enum) pushed gets (string) pushed = false (3ms)
+96ms ║║Condition #2 evaluated false (7ms)
+97ms ║║Condition group #1 evaluated false (state did not change) (8ms)
+102ms ║║Comparison (enum) pushed gets (string) pushed = true (1ms)
+103ms ║║Cancelling condition #4's schedules...
+104ms ║║Condition #4 evaluated true (5ms)
+105ms ║║Cancelling condition #3's schedules...
+106ms ║║Condition group #3 evaluated true (state changed) (7ms)
+108ms ║║Cancelling statement #5's schedules...
+113ms ║║Executed virtual command setVariable (3ms)
+119ms ║║Comparison (boolean) false is (boolean) true = false (2ms)
+120ms ║║Cancelling condition #10's schedules...
+121ms ║║Condition #10 evaluated false (5ms)
+122ms ║║Cancelling condition #9's schedules...
+123ms ║║Condition group #9 evaluated false (state changed) (7ms)
+125ms ║╚Execution stage complete. (40ms)
+126ms ╚Event processed successfully (126ms)
6/6/2020, 3:28:17 PM +869ms
+2ms ╔Received event [Basement - HomeSeer Flex Sensor].button = pushed with a delay of 129ms
+275ms ║RunTime Analysis CS > 17ms > PS > 242ms > PE > 16ms > CE
+277ms ║Runtime (38399 bytes) successfully initialized in 242ms (v0.3.110.20191009) (275ms)
+278ms ║╔Execution stage started
+285ms ║║Comparison (enum) pushed gets (string) pushed = false (1ms)
+287ms ║║Condition #2 evaluated false (4ms)
+288ms ║║Condition group #1 evaluated false (state did not change) (5ms)
+293ms ║║Comparison (enum) pushed gets (string) pushed = false (0ms)
+294ms ║║Condition #4 evaluated false (4ms)
+295ms ║║Condition group #3 evaluated false (state did not change) (6ms)
+301ms ║║Comparison (boolean) true is (boolean) true = true (2ms)
+302ms ║║Condition #10 evaluated true (4ms)
+303ms ║║Condition group #9 evaluated true (state did not change) (6ms)
+305ms ║║Cancelling statement #11's schedules...
+325ms ║║Executed virtual command sendPushNotification (17ms)
+328ms ║║Executed virtual command wait (1ms)
+329ms ║║Requesting a wake up for Sat, Jun 6 2020 @ 3:33:18 PM EDT (in 300.0s)
+333ms ║╚Execution stage complete. (55ms)
+334ms ║Setting up scheduled job for Sat, Jun 6 2020 @ 3:33:18 PM EDT (in 299.996s)
+345ms ╚Event processed successfully (345ms)
6/6/2020, 3:28:13 PM +394ms
+1ms ╔Received event [Basement - HomeSeer Flex Sensor].button = pushed with a delay of 44ms
+73ms ║RunTime Analysis CS > 18ms > PS > 40ms > PE > 15ms > CE
+75ms ║Runtime (38391 bytes) successfully initialized in 40ms (v0.3.110.20191009) (73ms)
+76ms ║╔Execution stage started
+83ms ║║Comparison (enum) pushed gets (string) pushed = false (1ms)
+85ms ║║Cancelling condition #2's schedules...
+86ms ║║Condition #2 evaluated false (5ms)
+87ms ║║Cancelling condition #1's schedules...
+87ms ║║Condition group #1 evaluated false (state changed) (7ms)
+93ms ║║Comparison (enum) pushed gets (string) pushed = false (0ms)
+94ms ║║Cancelling condition #4's schedules...
+95ms ║║Condition #4 evaluated false (6ms)
+96ms ║║Cancelling condition #3's schedules...
+97ms ║║Condition group #3 evaluated false (state changed) (8ms)
+102ms ║║Comparison (boolean) true is (boolean) true = true (1ms)
+104ms ║║Condition #10 evaluated true (4ms)
+105ms ║║Condition group #9 evaluated true (state did not change) (5ms)
+107ms ║║Cancelling statement #11's schedules...
+120ms ║║Executed virtual command sendPushNotification (10ms)
+123ms ║║Executed virtual command wait (1ms)
+124ms ║║Requesting a wake up for Sat, Jun 6 2020 @ 3:33:13 PM EDT (in 300.0s)
+128ms ║╚Execution stage complete. (52ms)
+130ms ║Setting up scheduled job for Sat, Jun 6 2020 @ 3:33:13 PM EDT (in 299.996s)
+140ms ╚Event processed successfully (140ms)
6/6/2020, 3:28:08 PM +429ms
+2ms ╔Received event [Basement - HomeSeer Flex Sensor].button = pushed with a delay of 48ms
+72ms ║RunTime Analysis CS > 17ms > PS > 42ms > PE > 13ms > CE
+75ms ║Runtime (38400 bytes) successfully initialized in 42ms (v0.3.110.20191009) (73ms)
+76ms ║╔Execution stage started
+83ms ║║Comparison (enum) pushed gets (string) pushed = true (1ms)
+84ms ║║Cancelling condition #2's schedules...
+85ms ║║Condition #2 evaluated true (5ms)
+86ms ║║Cancelling condition #1's schedules...
+87ms ║║Condition group #1 evaluated true (state changed) (8ms)
+89ms ║║Cancelling statement #7's schedules...
+94ms ║║Executed virtual command setVariable (2ms)
+100ms ║║Comparison (boolean) true is (boolean) true = true (1ms)
+101ms ║║Cancelling condition #10's schedules...
+102ms ║║Condition #10 evaluated true (5ms)
+103ms ║║Cancelling condition #9's schedules...
+104ms ║║Condition group #9 evaluated true (state changed) (7ms)
+106ms ║║Cancelling statement #11's schedules...
+126ms ║║Executed virtual command sendPushNotification (17ms)
+129ms ║║Executed virtual command wait (1ms)
+130ms ║║Requesting a wake up for Sat, Jun 6 2020 @ 3:33:08 PM EDT (in 300.0s)
+134ms ║╚Execution stage complete. (59ms)
+136ms ║Setting up scheduled job for Sat, Jun 6 2020 @ 3:33:08 PM EDT (in 299.996s)
+143ms ╚Event processed successfully (143ms)

#2

Do you need to monitor both button pushes?

What about…

IF button #1 gets pushed
Then
Send Push
Wait 5 minutes. <- set TCP to “never” here
END IF


#3

This is brilliant “outside-the-box” thinking!! :+1:


I suspect the challenge will be:
Each blink potentially re-triggers the piston again from the top…


#4

Please mark this post with the solution check mark :+1:

Here’s what you need to do.

If
variable is false
and
button gets pushed
Then
set variable to true
send notification.

Then in a second block

If
variable stays true for 5 minutes.
then
set variable to false.

I thank you.


#5

I’ve already done this, to no avail. Thank you.


#6

I suspect the same but don’t know how to fix this. Thank you.


#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.


#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?


#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:

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:


#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.


#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…


#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!