In the Notifications app: Repeat Notifications section: is an option:
"Stop repeating upon next event"
Documentation omits an explanation.
Does it stop repeating at ANY new event for the device, the SAME event, or the OPPOSITE event (wet vs dry, on vs off, etc) ??
(it appears to me this is meant to mean "stop repeating when trigger event clears". Can anyone confirm this is how it works, or explain it otherwise?)
I wasn't 100% sure about this, so I did a test. By the way, the reason I wasn't sure is that, as you imply above, lots of devices you'd use with this app have only two states, and you'd normally only get an event when the state changes (e.g., motion active to motion inactive). Thus, in a large number of cases, this question doesn't really come into play at all--any event is a different value (state--"active" or "inactive", in this example) for that attribute (event name, "motion" in this example).
To test this, I used a virtual lock driver where I could manipulate the "lock" attribute into one of three states: locked, unlocked, or unknown. Further, despite being different from how most real devices would work, I wrote this driver so that I could generate two subsequent events in a row even if the device was already in that state (e.g., a "unlocked" event even if the "lock" attribute was already "unlocked"), though again most devices don't do this. Here was my app setup:
My findings: any event for the attribute in question ("lock" in my example) will cause the repeat to stop, so the "stop repeating upon next event" option really does mean what it says (assuming you interpret it to mean the event in question and not any event for that device, like temperature on a motion sensor that also reports temperature if you're using motion here...it works as you'd reasonably expect). The app starts the timer when the "lock: unlocked" event is fired. It does cancel either this delay or the repeat on a "lock: locked" event (which I suppose you might call the "opposite," though for non-binary sensors there isn't always a clear winner on what this value would be), but "lock: unknown" does the same thing.
Really, even "lock: unlocked" cancels this, too (but again this is a special case in my driver because most real locks won't report two such events in a row, not that you could unlock one when it's already locked in the first place). But since this is what the app looks for to start this cycle over again, it still works as expected--cancels any "for how long" wait and any ongoing repeats, and starts the waiting over again, as you'd expect.
Hope this helps explain behavior you see!
If the above is tl;dr, then the answer is basically "any event" and certainly not just the "same event" (which most devices won't even generate: generally speaking, a sensor that's already reporting "wet" will not send a new event for this without a "dry" event in between). 
Thanks for responding bertabcd1234, and for your time testing.
Unfortunate in this case, because two different leak sensors I use both repeat the WET alert every 10-mins. I'll work with it. Thanks again.
Interesting. If you're interested in troubleshooting that: what sensor is this, and what driver are you using? Otherwise, you could do this with a rule instead; then, you have control over what happens when.
Download the Hubitat app
