When a Generic Event is triggered, the system requires specific metadata to link that event to a physical device. If the Device ID is missing from the API request, the server cannot identify which camera should generate the thumbnail or record the bookmark.
Solution 1: Including Device IDs in the API Request
If you have control over the JSON body of the API request, the most direct solution is to include the deviceIds field.
API Endpoint
POST http://<serverIp>:7001/rest/v4/events/generic
Request Body Examples
For a single camera, use the following structure:
{
"deviceIds": [
"<deviceId1>"
]
}For multiple cameras, list all applicable IDs:
{
"deviceIds": [
"<deviceId1>",
"<deviceId2>"
]
}| NOTE: You can find the unique Device IDs via the Desktop Client or REST API. Detailed instructions can be found HERE |
Solution 2: Workaround for Limited Third-Party Devices
Some third-party devices or applications have "hardcoded" fields (e.g., only Source, and/or Caption, and/or Description) and do not allow you to modify the JSON body or add custom metadata.
In this scenario, you can use the Internal HTTPS Request action within the Rules Engine to "proxy" the metadata.
How to Configure the Workaround
You must create two separate rules triggered by the same Generic Event:
Rule 1: Identification & Bookmarking
Event: Generic Event (matching your source/caption)
Action: Internal HTTPS Request
Configuration: Use the
POSTmethod described in Solution 1. This rule sends the necessarydeviceIdsback to the server, ensuring the event is tied to the correct devices.
Rule 2: User Notification
Event: Generic Event
Action: Show Desktop Notification
Options: Enable Force Acknowledgment if required.
By splitting the logic, Rule 1 handles the "data" (linking the event to cameras), while Rule 2 handles the "alert" (notifying the operator with the correct thumbnail). Because Rule 1 successfully identifies the cameras, the notification in Rule 2 will now correctly display the associated thumbnails.
Comments
2 comments
Are you going to make the "Force Acknowledge" notification stick even if the NX Client is closed?
Right now I got issues with this feature in the following scenarios:
1. NX Client is not open at the time of the event. But the operator open NX Client after they get for example an email warning. In this case, the notification do not appair in NX and it looks like there is no bookmar. The bookmark seams to be created after someone click the "Acknowledge" button.
2. The NX Client is open at the time of the event, but the user close the client before he "Acknowledge" the alarms. Next time the client is opened, all events will be gone, and there are no bookmarks.
Hi Fredrik,
My apologies for the huge delay in our response. Unfortunately, such features are not being worked on at the moment. We understand your request to have this feature improved in this way, so we will take your feedback into account for future feature discussions.
Please feel free to send us any other comments or questions through the New Features Ideas section of our community or via your Network Optix sales contact
Article is closed for comments.