Seeing lots of "cancelAlerts" events

I'm seeing a ton of hsmSetArm logs with cancelAlerts as the value, roughly at the same times every day.
Is that normal or should I hut through my RMs and apps to find the culprit?

I'm worried that if my HSM does go off (e.g. water leak or intrusion), something is canceling them at specific times.

Thanks for any pointers.

Screenshot:

You definitely have something that is resetting HSM every 4 hours. First thing I would do is look at your rule list and see if you have any that list "repeating" in orange. That means that the rule is current in a repeat cycle. It would appear from this one snipped of logs, that is what is going on.

Looks more like a repeating action to me. I wouldn't imagine you'd set a time trigger to 12: 53, 4:53, 8:53:12:53, 4:53 and 8:53.

For the life of me I can't find what's causing this... hmmm...

I would go through each rule, one by one, until you find it. There's no "in-use-by" for HSM, unfortunately.

Huh. I think I found the culprit (not a rule).
My Ring app seems to be doing this when it's websocket reconnects.

@codahq - Any idea why this would be calling "cancelAlerts"?

Quickly looking through the Ring code, it appears that when it reconnects it re-parses all the device states. You have it set to cancel Alerts when ring disarms. Well, ring is parsing that the state of the system is disarmed, so it sends a cancel alert message.

This will only be a problem if ring disconnects while there is an alert happening. I assume that ring app has to reestablish connection every 4 hours? In that case, there really is no way of doing this other that the way it is being done. There is no way to check the alert status within Hubitat other than having already subscribed to the event and keeping track of it.

@codahq I am curious....if you are tying ring into HSM, why do you have to cancel alerts when ring disarms? Won't ring also disarm HSM therefore canceling the HSM alert as well? I think the action of canceling the alert might be superfluous.

So under the "alarm device" I did have "Cancel HSM Alerts on Alarm Disarm" enabled. So just disabled that for now to see if that is it as I already use Alexa Guard triggers to coordinate Ring Alarm and HSM to be mostly in sync.

Again: This isn't causing me any issues, we just curious as I tend to look at my logs once a month to make sure nothing has gone hay wire and this pattern showed up.

You don't use the Unofficial Ring Integration to do that already? The option is right there next to the one you just disabled.

Yeah, I know I could, but I have a bunch of other stuff already trigger by Alexa guard (which in turn sets Ring Alarm and HSM), so undoing all of that to trigger off of the Alarm only or HSM would take some time and is slightly different from my preference.

That's a long excuse to say I'm a bit lazy, although I do have scenarios where I want a specific HSM mode armed but not Ring and vice-versa.

Then you're not using the ring alarm panel to arm/disarm? That seems like a bit of a waste of the system. I thought Alexa Guard could sync with Ring? If so, could you just sync Ring with Guard and Ring with HSM? I dunno...just seems to me like it's becoming overly complicated.

All good points, in no way am I a good/model example of fully leveraging Ring Alarm (unlike my Ring Cameras)
We reserve Ring Alarm to only be used we we are in 'extended away'. Not at night, or when just 'away'. So it's really just a part of our vacation/extended away routines, so we never use the key pad, or anything else.

Yep, they disconnect us at the 4 hour mark.

Maybe I should subscribe to those events so that I can take care not to cancel them. I guess the other thing I can do is check to see if the status is actually not the previous status and only cancel if the status is changing. I will have to ponder on this.

I want to leave the flexibility for this type of use as well. I've tried to make anything that can be parameterized exactly that.

Off the top of my head I can't think of any reason that I can't check the previous alarm status and only cancel if the alarm status is changing. Thank you for noticing this.

1 Like

That's my point, you can't poll for the current Alert Status of HSM like you can for the current Arm state of HSM.

I can subscribe to changes though, right?

Yes....but do you really have to?

If HSM Is tied to Ring's alarm status, then disarming Ring will disarm HSM, clearing the alert. Similarly, if HSM is not tied to Ring, then HSM would not go into alert when Ring Alarm does, so there would be no need to clear an alert in HSM, since HSM won't be in alert. If someone were to use the sensors from Ring without using the Ring Alarm, they would be controlling HSM and would want that to be independent of the Ring alarm. Just an idea.

I guess that's true of the alarm alerts e.g. the delay entrance and exit alarms or full blown alarm alerts.

For smoke though, that probably won't be enough. I'm not sure how HSM works. If there is a smoke alert in HSM I would assume that changing the HSM mode does nothing. However, if the Ring websocket happened to reconnect it would probably cancel a smoke alert (or water alert). I don't remember how that part works. I'll look at the code later. Motivation is extremely low to be productive right now.

I think we all feel this right now. lol.
Stay safe my friend!

Just to confirm, turning this setting off (which is fine as I don't need Ring Disarm to cancel my alerts), does indeed prevent the every 4 hours cancelAlerts events according to my logs now. Just FYI to close the loop with my main OP observation.