Push notifications, Delayed 2nd notification
Answered
I have recently set up push notifications on 2 separate systems, both are using Hik Accu-Sense cameras and have line crossing enabled.
Notifications are working and I receive a notification on an IOS phone with a preview which links to the a start position on the NX Footage, Very nice!
The issue I am encountering is to do with a 2nd notification that is received after the Interval of action timer has elapsed
IE:
On system 1, I get a 2nd push notification 10 minutes after the first notification ( as per settings)
On System 2, I get a 2nd push notification 1Hour after the first notification ( as per settings)
Initial tests seem to show that if I dont trigger a 2nd event, I wont get a 2nd delayed notification, but all/any additional triggers are cached and transmitted when the Interval Of Action timer elapses.
To my thinking, I shouldn't be getting a 2nd notification at all, rather only additional NEW notifications after the Interval of Action timer has elapsed ?
Interested in your thoughts on this one..
-
Hi David Kemp,
If the case of the issue is the same or similar to an issue for 2 and 4-line models, using the latest firmware of Hikvision should resolve it.
Otherwise, reproducing the scenario, while capturing the process with Wireshark should help us to investigate the issue.
0 -
Hi David Kemp,
Just checking in to make sure you received our response as it has been a while since we have heard from you. Please let us know if you still need help by responding to this message.
0 -
Hi Norman Graafsma
I don't believe this is an issue with the camera firmware (it's the latest), rather it's an issue with the way NX Witness processes the events and how it sends notifications.
The camera is only sending a notification event when the corresponding criteria are met, this may be only once or it could possibly be dozens of times during the period that elapsed defined by the Interval of Action timer, it is NX witness sending additional notifications once the Interval of Action timer has elapsed which is the problem I am referring to.
0 -
Hi David Kemp,
It is designed behavior. Whenever something happens it is very important to immediately register as an event. The event database transaction is generated at that point. The aggregation timer starts after that. Until the next interval time, all incoming events will be grouped.
Thus, when there are N events being triggered within the interval time then you'll get:
1) 1 alarm at the time of the very first event
2) N-1 alarms grouped during the next aggregation periodIf you want to have a single event, the Interval of Action could be Instant. Something I wouldn't recommend in case of a Line Crossing.
JIRA-VMS-23193
0 -
Hi Norman
Thanks for your reply.
The aggregation of events is certainly an annoying feature, the reason we set the interval of action timer is so we DONT get any notifications during that period.
Those I have spoken to agree that the logic behind this is flawed, what’s the point of getting a notification 1-2 hours after the event, especially if the 2nd event is straight after the first.
Hopefully the development team can add in an option so that events are not aggregated.
0 -
- Authorized Reseller
I agree with Dave Kemp. Aggregating the second and subsequent events, then actioning them as single event at then end of the timeout is not logical and undesired.
We simply want to action the first event then ignore subsequent events until the timeout expires.0 -
Regarding:
We simply want to action the first event then ignore subsequent events until the timeout expires.
That is exactly how it works right now. The only annoyance you'll have right now, is that in case of actual single events, like a soft trigger for example, is that you'll get the immediate action + 1 after the interval time.
As said, in such case, I would set the Interval or Action to Instant. For line crossing events, this often will be the right choice, but poses the risk of getting multiple events when people walk along the line. The best option should be determined per situation.
0 -
- Authorized Reseller
Yes...The +1 is the problem!
Interestingly - The rule desc says "No more than once per [interval]".
It does not say "No more than once per [interval] + 1 more if triggered again within the interval".
Not sure I see a valid use case for how it currently works.
As an example of a use case, I use a reed switch (input) to operate door chime (output) so someone may attend a reception area & I have set a "once per 10 min Interval". The problem is that when door is opened again during the 10 min interval (when a person exits for example), Nx will store/aggregate the event. The receptionist will leave the area, but is summoned back by the door chime at the end of the interval - even though the door has not been opened at the end of the interval!
I'd welcome some thoughts for a use case for the current logic, as I'm struggling to see one.0 -
Hi Andrew Sharrem,
A reed contact is a typical use case for Interval of Action: Instant since it is unlikely the event happens multiple times within X time, unless someone opens the reed contact and in such case you want the action for each event.
It could be that in case you also want to detect DTLO, door too long open, in that case you set the Interval of Action: X sec, so the receptionist is called back to close the door and preventing unauthorized entries as much as possible.
The Interval of Action: X seconds normally is used, for example, for motion detection or other events that can be repeated due to the nature of the event and since you want to reduce the situation of missing an event, it is designed as +1 event.
0 -
Hi Norman
I think we can attempt to justify the +1 setting all day long, the simple fact here is that some of us who use and also install the software for a client base ( whom incidentally also dislike the +1 feature) are asking for an option to turn the +1 setting off.
Could you instigate this for us on our behalf?
0 -
Hi David Kemp,
It has been discussed internally, and it is listed as feedback, but I do not expect any changes in the upcoming versions.
I hope you understand that for any feature or feature change we have to make choices to what we spend our resource on and at the moment, we do not see an urgent reason to change this feature, since for the use cases that were described, the alternative would be to use the 'instant' action.
We do understand it would be nice to have an algorithm that determines how often the action should be activated. Priorities might change if more use cases are shared in this topic by other users as well.
I hope you understand our current situation.
0 -
Hi David Kemp,
We just get the same situation here, I see no real case where +1 might be useful...
That one would be much more efficient :
We simply want to action the first event then ignore subsequent events until the timeout expires.
I hope we might get a wat to change it later.
James Cox for information
Rgds
2
Please sign in to leave a comment.
Comments
12 comments