The other day I created a custom alert to notify me with a pushover notification when certain contact sensors are opened or closed at night while I was away but my family is home. I received the pushover notifications as expected.
Then after I came home, I disarmed the custom alert. But the Pushover notifications keep coming even though the custom alert is disarmed. Rearming and disarming the custom alert doesn't help.
It's definitely this alert that is causing the notifications to be sent. If I change the notification text in the alert settings, the updated text is sent in the pushover alert. And the HSM alert settings page will update to show that the alert was sent in red text, hitting the cancel button will revert to the custom alert's status of disarmed.
As far as I can tell nothing shows up in the logs specific to this custom HSM alert, whether or not the alert is armed or disarmed (but that seems to be the case for all HSM custom alerts).
Any thoughts as to why this is happening?
Edit: I haven't yet updated to firmware 1.1.7, I'm still on the last hotfix for 1.1.6. But I just noticed this is in the release notes for 1.1.7
Is this the issue I'm seeing? I couldn't find this mentioned in another thread, so my apologies if this one is redundant.
I don't have the repeat pushover notification like you but my mode is pretty simple. When mode = away and contact sensor=open, send push notification. Been using this for a while without issue. How do you set your mode with your family?
I have an away mode for when everyone is gone, but not one for when I’m away and the rest of the family is home.
I realize there are many ways I could setup notifications that would be restricted to when I’m away only. It would be easy in RM with a triggered rule, for example (contact opens, Mark is away—>send pushover notification, restrict to certain hours).
But the problem here is that an HSM custom alert continues to send me notifications even when it is disarmed.
@bravenel will upgrading to 1.1.7 address this? Thanks.
@bobbyD replied to my support inquiry and said he couldn't reproduce. Ive been pretty busy with work this week and haven't been able to reply to him with the requested info. It's on my to-do list for today. If anything comes of that I'll post an update.
I can reproduce this with any new custom HSM alert that I create. Here is one I just created, which is triggered by a virtual contact sensor. I did not arm it after I created it but I received the notification for the alert when I set the sensor to open. Sorry for the delay, hope an additional data point helps. Thanks for looking into it!
So this seems to be happening to me again. I recently created a new custom HSM rule, disarmed it, and it rearmed itself. It's happening with another similar rule that was created at the same time. I'm running hub firmware 2.0.5.
Sorry, to clarify, the hsm custom rule re-arms itself after I disarm it. Same behavior as I previously reported above, but this started recently with two new custom alerts I created. Here is the app event log since my last post on 3/10. The only thing I did to this custom rule is disarm it once in the app settings page. I'm not sure what all the "armedrule" activity is before and after.
I use a couple of rules, I think I created them in RM, that arm and disarm HSM alarm state on a recurring basis. Once in the morning when we first wake up, and once in the evening at 11:30pm. But AFAIK there is nothing that should be automatically arming or disarming any of my custom HSM rules. I will manually disarm another custom rule that has been around for a while and see if it re-arms itself, or if this is limited to the rules I recently created.
I can't tell with the information you've provided what is going on. Suffice it to say, you have something that is driving HSM to do these things. Why don't you pause every rule that controls HSM, and work your way element by element until you find what's going on. HSM doesn't do things on its own, and custom rules don't just arm themselves on their own either. Something in your system is causing this.
