Anyone else getting double notifications?

#1

I don’t see anything in here which should cause a double notification…

54%20PM
Screen Shot 2020-11-26 at 4.18.54 PM.png1451×542 116 KB

#2

That code looks alright…

Are you using both the ST Classic plus the new app?

#3

No, I got rid of the classic.

#4

I have occasionally received double PUSH notifications…
… but never double SMS notifications.

Is there any chance of another piston sending one of them?

#5

Just 1 piston. Maybe it will go away.

#6

If I were debugging this, I would turn Logging to “Full” on the real piston.
(this will catch the next event, to see if it triggers or loops twice)

#7

Only tripping once…It might have something to do with the AWS, but who knows…I’ll see down the road what happens.

#8

I was getting double SMS messages once but that was on a timer that was getting double triggered. Somehow this piston is getting double triggered. As @WCmore suggested, set logging to full. You could try logging $currentEventAttribute to verify what is triggering the piston but you will seee that in the full log anyway.

#9

Looking at the logs, it appears ST’s is issuing the command twice because I see received events for the same action milliseconds apart (but it actually isn’t - please see below.) I’m only touching the button once on the app (or giving an Alexa command once.) Looking at the ST’s IDE log on the device, only one command is being issued. I am getting numerous “Piston waited at a semaphore for 10020ms” so maybe that’s the issue.

#10

I would try a different brand bulb in this location…
I have worked with cheap bulbs in the past, where a “Turn on” command actually goes “on-off-on” in a few milliseconds. (thereby triggering the piston twice)

As you noted, when the second ones comes in back to back, there is a 10 sec delay before that one is processed.

Of course, webCoRE is smart enough to allow coding to prevent the second trigger from doing anything, but honestly, I would focus on different hardware (or handler).

#11

I’ve had the bulb (Sengled) for a couple of years and it never did this before with this piston. Considering it’s almost never on, I’ll just leave it :slight_smile: What would I have to do to change the piston to get it to fire only once? I tried that parallelism thing, but that didn’t work. I also tried to put a wait command before the notification - didn’t work. Considering ST’s is not seeing the “on” or “off” twice, I wonder why webCoRE does (it never used to.)

#12

As a test, try pausing the piston and turn on the light and see if there are any sms messages sent :slight_smile:

#13

Well, webCoRE only sees what ST sees… so I suspect ST just hides the spam event.

Technically, it will fire each time the switch turns on or off, but we can prevent the commands from being sent twice by using local variables. IE:

define
   boolean recent (no value set)
end define

execute
   IF Bulb1 changes to on
      and
      {recent} is not true
   Then
      With Location  (TCP set to Never)
         Set variable {recent} = true
         Send SMS notification
         WAIT 15 seconds
         Set variable {recent} = false
   END IF
end execute

Note: Do not use parallelism with this method.

#14

I tried this :slight_smile:

#15

Thank you. Let me see if I can figure out how to add this :slight_smile:

Worked great, thanks!

#16

The double notifications are back, no idea why :frowning:

33%20AM
Screen Shot 2020-11-29 at 10.31.33 AM.png1047×389 56.9 KB

When I take a green snapshot, it doesn’t show the false in boolean, but it is false when I look at it from the regular view.

29%20AM

It was working great before, not sure what the deal is.

#17

Isn’t line 24 using the literal string ‘recent’ instead of the variable and so always true?

#18

What should I change to fix this?

#19

Line 24 should compare the variable.

pic

#20

Ok, I fixed that part. I think I know what the issue is. I have a separate piston to monitor the light going off (exactly the same piston as on, except looking for the off command.) When I paused that piston, I am only getting one notification on the “on” piston. When it’s un-paused, it goes back to 2 notifications. I guess I should incorporate the off piston within the on piston? I didn’t do that because I figured I would not do it correctly. By the way, you did ask if you thought another piston was sending the notification, but I didn’t think a separate piston looking for the device to go off would count - clearly it does and you’re right on that…