This is a known issue with the current version of the Notifications app (see here: Notifications App Error), and I'd assume the same might apply to HSM. A screenshot of your setup might help staff determine that it's the same thing, but I'll tag @bravenel let him know the same issue as I linked to above might also be present in other apps.
In the meantime, you can work around this by using 59 minutes or below for the "minutes" field.
Notification works,
and the feature now invokes a 59 min delay as intended.
So it seems related to previously idenentified bug.
This one could cause a lot of head scratching as waiting a 60 min hour would be a common duration setpoint for some uses. 59 min works, but clearly it should be on the To Be Fixed List.
It looks like it really is a bug. I would tag Bruce (@ bravenel -without the space after the @) in that thread and ask if this might be fixed in a future update.
Are you talking about Notifier app? If so, that bug is now fixed but not yet released. For periods longer than 59 minutes you use the other repeat mechanism. The new version makes it clear that the option in question is only for 1 to 59 minutes, and disallows any other value.
It's no show stopper, fix when/as it makes sense to other things you are doing.
I'm more concerned about the time new folks might spend when encountering stuff like this thinking it's their mis-step in configuration, or a mis-understanding of how features work.
I dared to ask the question and that allowed others more knowledgeable to follow up with a likelihood of this being real.
I know stuff is going to break when doing software development. I had another old HSM Custom failing notifications and didn't notice the problem until I was building this new one. That's a little discomforting to me.
I don't know your guy's process but maybe there should be a group of dedicated fully versed types that take all releases onto their platforms for a period before general release. In exchange you give them a new HE box every time you design a new one?
We have a beta program that new releases go to first, with many experienced users. However, not every issue or problem is going to be uncovered even through that process. It is inevitable that despite all best efforts there are going to be bugs in platform and apps. We endeavor to fix these promptly when they are reported, as this is an example of.
Had my garage door set to notify after being open for five minutes and set to once in 60 minutes. Forgot to close door today and did not get notification. Removing the 60 minutes and it worked. Started searching and found this post. Worked fine in all previous versions. Guess the saying is true, if it ain't broke don't fix it - I should be careful in updating to new versions and test features critical to me after the update. But good job on finding and fixing quickly.
Oh how true this is.
In a previous life I worked for a telecoms company on digital telephone exchanges.
When the vendor brought out new software we would test it for months before releasing it nationally.
We always had something crawl out that would bite our backside.
You just cannot test everything unless you are prepared to spend months and months testing it. (Which we did). And then a few more.
The great thing is if you can react to the issues that appear quickly and HE do do that.
Did see that as well Bruce....but was a bit confused by:
... to only allow 59 minutes
As in anything from: a) no response in field, and b) 1 minute - all the way up to 59 minutes.
or
As in a) no response in field, and b) ONLY 59 minutes?
Pardon me if I am taking this too literately. I'm hoping you don't mean the latter.
I've set a 20 min pause on a vibration sensor alert that averts constant notification during a gusty frontal passage shaking a parked RV. Otherwise I wanna know if the RV is climbed on or messed with ....and waiting a whole hour isn't optimal.
I know...this isn't a security system. But...still.