Difference between device integration and global integration, and how to get started developing a global integration
Answered
Hello,
I am starting to explore the different capabilites that exist for plugin development.
I need to integrate my Nx VMS bi-directionnaly with an external control panel.
I thought using the SDK since in the documentation it seems to be the most complete way of building plugins.
However, I'm quite confused at the moment because I can't find any information on the difference between the integrations panel and the integrations that you directly enable on a device (cf screenshot), except that the device integrations seems more fitted to video analytics.
Can both be developed using the Metadata SDK ?
Also, is there a “getting started” for global integrations and not device specifics integrations ?
Thank you very much !
-
Hi Julien Polycarpe,
Thank you for your question.
* About “integration”
An integration simply refers to the resulting program or solution that works with Nx Witness. It does not mean a single, global integration framework. ”, but device plugin, system plugin or web page integration.
In general, there are 2 major categories separated into:- System/ Device / Analytics plugins
- Web (web page) integrations
* Implementation clarity
- Meta SDK → how to build device / analytics plugins
- In-Client JavaScript API → how to build web page integrations
They are independent tools, each for a specific purpose.
* To directly answer your question
Can both be developed using the Metadata SDK?
No. They are fundamentally different.
- Device plugins (.dll / .so) must be developed using the Meta SDK
- Web integrations must be developed using the In-Client JavaScript API
“Getting started” for Global integrations
What you are referring to as “global integration” is likely web page integration.
You can find the resources here:
- In the User Manual
- On GitHub (sample code):
-
In the Knowledge Base article:
If you have chances, please follow the documentation for the correct tool, it introduce the concept well and straightforward.
Hope this helps.
Thanks.
0 -
Hello Ichiro,
Thank you very much for your answer, everything's more clear now.
What I don't seem to find are examples of what you called “system plugins”. From what I found, plugins developed using the Meta SDK must be linked to a device, right ?There isnt an integration I can develop using the Meta SDK and install globally at the VMS level, to manage things not directly linked to a device lifecycle ?
For example, here is my use case: I need to allow bi-directional communication between Nx and an alarm. This thing has nothing to do with a camera in particular. Unless I can create “fake” devices that aren't cameras ? But from what I read in the Meta plugin documentation, it doesn't seem possible either.
So for these kind of use cases not directly linked to a particular device, the only solution is to use web integration and a middleware I guess ?
0 -
Hi Julien Polycarpe,
Thanks for your response, you may check the comment below.
What I don't seem to find are examples of what you called “system plugins”.
This may not be correct. All provided examples, including both “sample” and “stub”, are system plugins.
If you try to install them before, you will see that these plugins are visible and available across all devices and cameras. This behavior is expected for system plugins.
I understand that this concept can be a bit confusing at first, but these examples are indeed demonstrations of system plugins, not device-specific ones.From what I found, plugins developed using the Meta SDK must be linked to a device, right ?
Depending on the context, this statement can be partially correct or incorrect.
- If you are referring to a device plugin:
Yes, a device plugin is required to be linked to a compatible camera, device, or specific equipment/model. - If you are referring to a system plugin:
No, a system plugin does not need to be linked to a specific device. A system plugin may simply consume frames or video streams from devices within the system. (If your system has multiple servers, the plugin must be installed either on all servers, or on the specific server that manages the target device)
If this is interpreted as “must be linked to a device” simply because it consumes data from one, then it could be seen as “yes” from a wide interpretation. However, architecturally, we do not treat this as device linkage.
- Device plugins → must be linked to a specific device or model
- System plugins → do not require device linkage
There isnt an integration I can develop using the Meta SDK and install globally at the VMS level, to manage things not directly linked to a device lifecycle ?
This is a system plugin, and it is fully supported and doable.
You can implement a system-level integration/plugin that operates at the system scope, allowing all devices within the system to use it. (In general, not being directly linked to a specific device is logically equivalent to being linked to every device within our integration subsystem architecture.)
I understand this may be a bit difficult to locate in the code.
For reference, in i_engine.h, you can find the relevant virtual method that enables this behavior:isCompatible(const IDeviceInfo* deviceInfo)
In short:
-
Device plugin
If you implement
isCompatible(for example, matching manufacturer = XYZ) and create a deviceAgent only for those compatible devices, this is a device plugin. -
System plugin
If you do not implement
isCompatible, the system will create a deviceAgent for every device in the system. This is a system plugin.
I need to allow bi-directional communication between Nx and an alarm.
This thing has nothing to do with a camera in particular
But from what I read in the Meta plugin documentation, it doesn't seem possible either.I’m afraid I’m not fully clear on this point, and the claim could benefit from further elaboration.
If no information or video is received from any devices, could you please explain how an alarm would be generated in your scenario? Generally, some form of input or data source is required to trigger an alarm.Regarding the statement about “bi-directional communication between Nx and an alarm,” this could indeed be a valid use case. However, the current description is quite limited. Clearer details around the data flow, trigger mechanism, and system interaction would be appreciated, as it is difficult to assess feasibility based on the information provided so far.
At this stage, it would be helpful to have more concrete details in order to make a proper judgment and evaluate the scenario accurately.
So for these kind of use cases not directly linked to a particular device, the only solution is to use web integration and a middleware I guess ?
This could be one possible solution, assuming it is feasible in your scenario.
What we provide is a set of toolkits, such as the Mediaserver API, Meta SDK, and In-Client JavaScript API. You may use any single tool or a combination of them to achieve your goal, depending on your design.
At the moment, we have limited information about your actual use case. The only requirement mentioned so far is “bi-directional communication between Nx and an alarm.” With this level of detail, unfortunately, there is not much we can confidently recommend.
If you are able to share a clearer and more detailed use case or user story—for example, how the alarm is triggered, what data is exchanged, and where Nx fits into the flow—we may be able to suggest more concrete and suitable approaches.
Thanks.
0 - If you are referring to a device plugin:
Please sign in to leave a comment.
Comments
3 comments