Surpress temporarily actions showOnAlarmLayout and showNotification for a specific camera

Answered

Comments

5 comments

  • Avatar
    Miguel Câmara

    Is this still the only solution to "Arm" and "Disarm" notifications from the system?

    In a system I am setting up I have 5 VIVOTEK cameras, and I have one or two analytics per camera (SmartMotion and/or Perimeter).

    The user wants a way to Enable/Disable notifications to his phone (which we are setting up via PushOver service) and also email.

     

    The notifications he receives needs to specify if the alarm is Camera 1, 2 ... 5, so that he knows what to search for.

     

    This means I will have a minimum of 10 individual notification rules:
     Rule1_1: Send Push Notification SmartMotion/Perimeter Camera 1
     Rule1_2: Send Email of SmartMotion/Perimeter Camera 1
     Rule2_1:...Push Camera2
     Rule2_2:... Email Camera 2
     ....

    I want to create one single button to disarm all notifications, this I can do by sending a GenericEvent to NxWitness  with "Caption=Disarm" for example.

    Now I have to create 10 Rules with the Event of Generic Event and the Action of "Do HTTP Request", where each one will differ only the Event and Camera GUID's, right?

    After that I have to create another button and 10 additional rules just as before but to "Arm" the notifications.

     

    This seems like a hell of a lot of work for something that is supposed to be simple and useful. and very difficult to manage/maintain if we need to change something.

     

    My recommendation is to have one possible action of the rules to be "Rule Engine Management" where we could define a set of rules that could be "enabled", "disabled" or even "Toggled".

     

    2
    Comment actions Permalink
  • Avatar
    Sergey Yuldashev

    Hello Tomasz,

    My colleague Andrey will shortly post here a way you could use as an option right now available in the software.

    0
    Comment actions Permalink
  • Avatar
    Andrey Terentyev

    Hello Tomasz,

    The first option we would recommend is to review current set of Event Rules. All the suppressions and permissions of actions are performed on the basis of the Event Rules by turning off/on corresponding rule. As soon there is a rule for particular [Event, Source, Action, Target, Interval of Action] it could be turned off causing suppression of the action defined in it. The point is in identifying cameras which require such an option more often and separate them by defining two rules each for showOnAlarmLayout (seen as “Show on Alarm Layout” in GUI) and showPopupAction (seen as “Show notification” in GUI) respectively. Thus you will have the possibility to turn off these rules manually, meaning suppressing corresponding actions.

    In order to gain more granular control you possibly want to define a rule per each camera.

    The solution offered below implies Events Rules been configured granular enough to identify a camera and type of action. It is intended to demonstrate approaches to automation of the task.

    This method deals with Server API and with though undocumented in version 3.2 but available API call.

    There is  a procedure given below how to configure suppression of actions of both types have been mentioned for a one particular camera.

    The steps are following

    1. Finding out Camera ID.
    2. Getting all the Action Rules through Server API.
    3. Extracting  the rules relevant for your Camera ID and actions types.
    4. Configuring suppression of actions.

    1. Finding out Camera ID

    1.1. Log in to your System with Nx Witness Client.

    1.2. In the object three select the camera of your interest.

    1.3. Right click on the camera, select “Camera settings...”

    1.4. Copy camera ID from the “Camera ID” field into a text file.

    2. Getting all the Event Rules through Server API

    Log in with a web browser to your server which the camera is connected to. http://<your server address>:7001

    Select the “For developers” menu item. Then click the link “API Testing tool (new)

    In the search field type the name of the method “getEventRules”. Click the link appeared in the method tree below.

    In the page appeared click the “Test method” button.

    Then copy the contents of the “Response” field to the clipboard by clicking the “(copy)” link.

    Paste copied contents to the text editor. The contents is a JSON-formatted list of objects.

    3. Extracting the rules relevant for your Camera ID and action types.

    Now we’ll search for the relevant rules using the Camera ID saved in the step 1.4

    Using search dialog of your text editor find the entries of the Camera ID in the text.

    The structure will look similar to the shown on the screenshots below.

    The action type your are interested in are showOnAlarmLayout and showPopupAction (for showNotification)

    The objects you need have to contain

    1) your Camera ID in “eventResourceIds” field

    2) either showOnAlarmLayout or showPopupAction values in the “actionType” field

    Copy the objects found (i.e. the text from the opening curly bracket till the closing bracket including brackets) to the text file.

    4. Configuring suppression of actions.

    This approach is based on using undocumented in version 3.2 API method “saveEventRule”.

    saveEventRule (X)

    Create or update event rule in event/actions rule list.

    Parameters should be passed as a JSON object in POST message body with content type "application/json".

    This API method can change one rule per call. It means it’s not possible to pass a list of rules to this method .

    Now we’ll define a “Soft Trigger” rule which will turn OFF  the particular rule for the camera, i.e. suppress corresponding action.

    Switch to your Nx Witness Client.

    In the Resource tree select the camera identified on the step “1. Finding out Camera ID”.

    Right click on the camera and select “Camera rules...”

    In the “Event rule” windows click “Add” button in the right upper corner. (See the screenshot below).

    For the “When” field choose “Soft Trigger

    For the “At” field choose the camera identified on the step “1. Finding out Camera ID”.

    For “Name” type “TURN OFF” or any other text suitable for your.

    For “Available to” choose the role of the user.

    For “Action” choose “Do HTTP request

    In the “HTTP URL” field type http://localhost:7001/ec2/saveEventRule

    Insert the JSON code of the one rule of your choice got on the step “3. Extracting the rules relevant for your Camera ID and action types” into the “HTTP content” field.

    Make sure the code corresponds to the rule for the current camera, i.e. the value of “eventResourceIds” has to be the ID of the camera currently being configured (see the screenshot).

    The value of "disabled" field has to be true in order to make the rule disabled (see the screenshot).

    Type in Login and Password for your server.

    Make sure the “The request type” is set to POST.

    Click “OK” button.

    Now you’ll see an icon in the right bottom corner of the camera item window (see screenshot below).

    Clicking this icon will disable corresponding rule and suppress the related action.

    5. Configuring permission of actions.

    Now we’ll define a “Soft Trigger” rule which will turn ON the rule have been disabled on the step “4. Configuring suppression of actions”.

    In the Resource tree select the camera identified on the step “1. Finding out Camera ID”.

    Right click on the camera and select “Camera rules...

    In the “Event rule” windows click “Add” button in the right upper corner. (See the screenshot below).

    For the “When” field choose “Soft Trigger

    For the “At” field choose the camera identified on the step “1. Finding out Camera ID”.

    For “Name” type “TURN ON” or any other text suitable for your.

    For “Available to” choose the role of the user.

    For “Action” choose “Do HTTP request

    In the “HTTP URL” field type http://localhost:7001/ec2/saveEventRule

    Insert the same JSON code as on the step  “4. Configuring suppression of actions”  into the “HTTP content” field.

    Make sure the code corresponds to the rule for the current camera, i.e. the value of “eventResourceIds” has to be the ID of the camera currently being configured (see the screenshot).

    The value of "disabled" field has to be false in order to make the rule enabled  (see the screenshot).

    Type in Login and Password for your server.

    Make sure the “The request type” is set to POST.

    Click “OK” button.

     

    Now you’ll see two icon in the right bottom corner of the camera item window (see screenshot below). One for turning on, another for turning off the rule.

    In order to reduce the amount of work you probably want to proceed like this.

    1. Identify a set of cameras.
    2. Create an Event rule with showOnAlarmLayout action. For “At” field assign a set of your identified cameras.
    3. Get all the Event Rules through Server API.
    4. Extract the code for just created rule. It is that of which "eventResourceIds" field would contain IDs of all identified cameras.
    5. Create a pair of “Soft Trigger” event rules as it has been shown previously. For the “At” field assign a set of your identified cameras.  For the “HTTP content” field place a code got on the step 4.

    Repeat these steps for the action type showPopupAction

    0
    Comment actions Permalink
  • Avatar
    Nx Support

    One more note: if you are going to change anything in the basic rules later, you need to repeat those steps again, because every time you enable or disable the rule this way - its configuration will be restored to the original state.

    0
    Comment actions Permalink
  • Avatar
    Tagir Gadelshin

    Hi, Miguel
    I was exploring the feedback on our Rules engine and come across your reply here.

    I think that our new Push Notifications feature will partially solve your problem. It's going to be released in 4.1 and user will be able to suppress push notifications right in the app.

    We considered implementing "Rule Management" action, but there are concerns about unpredicted behavior. One rule will turn On another one, that will turn Off some other rule immediately and so on.. So troubleshooting can become much more complicated when those actions will be used.

    We understand that this can be made via Nx API (turn specified rules on&off, e.g. see THIS video) and we have plans to improve our API.
    But we are not sure if such complicated logic should be implemented in UI.

    I will also mention that we are going to introduce "multiple events" and "multiple actions" rules engine in 4.3 or later. This will help to reduce the amount of work for you (e.g., you will only need no call one API call to turn all notifications off)

    0
    Comment actions Permalink

Please sign in to leave a comment.