Proliferation of Email Notifications

#1

I have a manually triggered piston (from another piston) and it seems to trigger 20-30 times a day.

image
image.png1178Ă—575 35.6 KB

Specifically it shows this is the log:
image
image.png821Ă—253 15 KB

What does calledMyself: true mean?
There seem to be 5 of these for every time it is actually triggered from the other piston.

The flow is this:

  1. Arm if everyone leaves the house
  2. If anyone comes back to the house run Disarm to disarm the alarm and notify.

I think it is this Arm when away script that is triggering it so many times.

image
image.png1178Ă—813 50 KB

I am using 4 sensors for 2 phones. Life360 has been 99% accurate, but it still seems like whenever someone leaves the house it triggers the Alarm to set. It should be when ALL people leave. Any ideas?

#2

I couldn’t post more than 3 images. Here is the Disarm when home piston

image
image.png1178Ă—429 24.2 KB

#3

I have hot food in front of me, so I have only examined the top piston… but here is what stands out:

(1) This piston MAY be triggered from another piston, but it is also triggered by the lightning bolts in the left margin. So basically, whenever “Hubitat Safety Monitor status” changes to anything at all, the entire piston runs top to bottom.

(2) It is usually a bad idea to use this kind of looping logic:

IF DeviceA changes
    Then change DeviceA
END IF

One single event could (theoretically) trigger / loop hundred of times, back to back.
(with lots of semaphore delays and other issues arising)

(3) Sending opposite commands to the same device 10ms later is often asking for trouble…
(Lines 22 and 23) This fast spam may cause confusion, and sometimes 23 will arrive before 22 does. If you absolutely must have two contradictory commands back to back, I would insert a 2-3 second WAIT in between.

There may be more, but my food is getting cold here, LOL

#4

I agree with @WCmore

the call myself is that multiple events came in at the same time, and webcore queued them and ran them sequentially. In short it is a sign that many events occurred while running, and likely in the larger look at the logs you will see the additional events came in, were queued then executed. Likely all the HSM changes that the piston both made, and subscribed to.

#5

Thanks to both @WCmore and @E_Sch for the quick response. These are my first pistons, so bear with me.

So you are saying that even though DISarm is called from another piston, because it has those lines with the lightening, it will run whenever HSM change status?

Can I fix this by using a global variable to check if the alarm is set? Is that reliable enough? I assume it won’t subscribe the global variable being changed?

#6

You can force to not subscribe by clicking on the lines that have the bolt, and then under the gear there should be an option to always, never subscribe. (if you know you never want to subscribe).

#7

You’ll know you succeeded because the lightning bolts will vanish, and you’ll see something like this up top. (once saved)

pic
pic.png712Ă—58 2.97 KB

#8

Welp, that didn’t work. Armed and went off on the wife’s birthday. Also, I can’t view nor edit any of my pistons after changing them to a custom category. They have completely disappeared…

image
image.png626Ă—528 15.6 KB

I am likely going to give up. Webcore is a good idea, but I just can’t waste another 50 hours to learn every nook and cranny of the system.

#9

On Windows, Ctrl-F5 should redraw the web page…

#10

Nope. Already tried that several times.

#11

Is there more than one instance of webCoRE?
(in the top left drop down menu?)

#12

Also keep in mind that if you moved to a TILE category… and there are no Details showing… and the piston has not run yet to draw a tile… then the category will look blank.

You can add Details to that category to “bring them back”.