ISAPI documentation

So you will wake up and manually log a plate everytime a vehicle goes by?

Why not let it go to an SD card and a couple times a day pull the plates and put them in your database?

Or maybe go to a 3rd party reader like OpenALPR and use one of the tools created here to log them all into a database?
 
  • Like
Reactions: black1906
So you will wake up and manually log a plate everytime a vehicle goes by?

Why not let it go to an SD card and a couple times a day pull the plates and put them in your database?

Or maybe go to a 3rd party reader like OpenALPR and use one of the tools created here to log them all into a database?

Because im creating a software that will open a barrier everytime a specific plate goes by.
I have and database that updates at random all day with the plates that are allowed to go in (which i have no control of). So i need to get the plate the camera gets,check if it is in this database,and if so,open the barrier.
As the database updates randomly all day long,there is no way or a specific time which that i could get all the plates in the sd card and check them. I need to do it 24/7,because i don't know when the database will be updated.

Looks crazy but i have already done it and it is working fine. But i used another camera (Dahua) and didn't liked it very much,so i got this Hikvision one,and im trying to do the same thing.
 
The fact you pointed out you already had this done with another camera, is precisely one of the reasons why I would strongly advise you go down the FTP route, since most (if not all) cameras will support that kind of functionality, so whenever the camera eventually needs changing, it is going to be a whole lot easier to change something as simple as checking the name of a file in an FTP server (which can be the computer doing the database logging and checking), than it is to change lower level camera-specific functionality, had the software been done this way the first go around, this time all you would have had to do was change one or two lines of code.

As for needing to check it every second or even multiple times a second, that is not a real constraint for not using a medium storage solution (FTP server, NAS, or microsd card), an FTP or NAS use either HDDs or SSDs, which can handle simple file name queries for breakfast, and microsd cards it is also a complete non issue, I would say it is a non issue for every single one of them, they are used as the OS storage mediums for computers like Raspberry Pis, but in this specific case if you end up using a microsd card (which is only needed if you aren't using an FTP service), you are going to want to invest in something like a WD Purple microsd card or one of its equivalents from another brand, since you want bombproof reliability on it.

So yeah, given the requirements you are mentioning now, and the fact you already had to change the camera once, I would say having the information saved to an FTP server which can be simply a service running on the computer doing the checking and the logging (assuming it is a computer and not a microcontroller), is not just a solution that works and is easy to implement, but it is actually the better solution IMO since you get ease of implementation, ease of future camera changes, and you get storage of images of the license plates and vehicles for future auditing in case anything goes wrong.
Going down the microsd card route instead of a ftp service is only advisable IMO if you have some very specific requirements where adding an FTP service would be less reliable, like say if you didn't already have a computer on site capable of running a simple FTP Service, which was my case (cameras are positioned on a battery-powered site and the only internet is 4G), I say this because the microsd card implementation is going to be more camera specific, and reliant on future cameras having similar ways of accessing them via web calls.
 
  • Like
Reactions: black1906
I will tr
The fact you pointed out you already had this done with another camera, is precisely one of the reasons why I would strongly advise you go down the FTP route, since most (if not all) cameras will support that kind of functionality, so whenever the camera eventually needs changing, it is going to be a whole lot easier to change something as simple as checking the name of a file in an FTP server (which can be the computer doing the database logging and checking), than it is to change lower level camera-specific functionality, had the software been done this way the first go around, this time all you would have had to do was change one or two lines of code.

As for needing to check it every second or even multiple times a second, that is not a real constraint for not using a medium storage solution (FTP server, NAS, or microsd card), an FTP or NAS use either HDDs or SSDs, which can handle simple file name queries for breakfast, and microsd cards it is also a complete non issue, I would say it is a non issue for every single one of them, they are used as the OS storage mediums for computers like Raspberry Pis, but in this specific case if you end up using a microsd card (which is only needed if you aren't using an FTP service), you are going to want to invest in something like a WD Purple microsd card or one of its equivalents from another brand, since you want bombproof reliability on it.

So yeah, given the requirements you are mentioning now, and the fact you already had to change the camera once, I would say having the information saved to an FTP server which can be simply a service running on the computer doing the checking and the logging (assuming it is a computer and not a microcontroller), is not just a solution that works and is easy to implement, but it is actually the better solution IMO since you get ease of implementation, ease of future camera changes, and you get storage of images of the license plates and vehicles for future auditing in case anything goes wrong.
Going down the microsd card route instead of a ftp service is only advisable IMO if you have some very specific requirements where adding an FTP service would be less reliable, like say if you didn't already have a computer on site capable of running a simple FTP Service, which was my case (cameras are positioned on a battery-powered site and the only internet is 4G), I say this because the microsd card implementation is going to be more camera specific, and reliant on future cameras having similar ways of accessing them via web calls.
I'm trying to go the FTP route,but i still have no success no matter what. it still gives me


<?xml version="1.0" encoding="UTF-8"?>
<VehicleInfoResult version="2.0" xmlns="">
<downloadID>WhatEverHereDoesntMatter</downloadID>
<responseStatus>true</responseStatus>
<responseStatusStrg>NO MATCHES</responseStatusStrg>
<numOfMatches>0</numOfMatches>
<totalMatches>0</totalMatches>
<deviceID>Camera 01</deviceID>
<MonitoringSiteID></MonitoringSiteID>
<VehicleInfoList>
</VehicleInfoList>
</VehicleInfoResult>

Even tho are plates,and the images are actually being saved in my FTP server correctly. My camera will have constant connection,so the FTP is okay to me. Do you know if it may be a firmware problem? mine is V5.5.130 build 200927 from camera model iDS-2CD7A26G0/P-IZHS.
Is there a way for me to update it?? Im starting to think this is the problem. I have been talk to other people and every single one of them told me mine should be working...
 
No update to the camera needed, you just didn't understand the FTP solution, or I poorly explained it, when you go the FTP route you no longer need to interact with the camera at all, you instead either interact directly with the FTP server, or if the machine that needs to access this information is also the FTP server you directly interact with the files. This is why the FTP solution to the problem is more versatile for future camera changes, since you are no longer tied to the camera API, and instead are merely relying on any future camera having the ability to send these things to an FTP (which they all should have).

Given you have confirmed that images are, in fact, being stored to the FTP server, all you have to do now is access the FTP server with your software, read the name of the files, and the name of the files should contain the information you need, which is licence plate and date, you can even specify the format of this information and additional information in the camera settings, on my camera in Configuration -> Road Traffic -> Picture, I get this:

hlYaIdi.png




Basically, the workflow is something like this:

Camera Captures licence plate
-> Camera sends licence plate to FTP Server
-> Software checks FTP Server for unprocessed image files every X seconds/milliseconds
-> Software reads the names of those files
-> Software splits the name into its components (date, licence plate and whatever else you need)
-> Software checks that information with the database
-> Software determines if it should open the barrier or not
 
Hi all,

I am a developer trying to get acquainted with IP cameras especially ANPR/LPR (license plate recognition) cameras, my goal is to retrieve the data about the plates via some APi and integrate them in my own app.

While browsing, I came across ISAPI that sort of does the job but I couldn't find any documentation about it,

I would like to know where I can possibly download the ISAPI documentation, if am I in the right direction

Thank you all.
I have to go back and search for the last 24 hours and so on. So is there someway we can download all the plates stored in the SD card?
Nox Vidmate VLC
 
Last edited:
I have to go back and search for the last 24 hours and so on. So is there someway we can download all the plates stored in the SD card?
Nox Vidmate VLC
I'd suggest using hikvision SDK with SQL database rather than relying on SD CARD, internal buffer and safety of your camera. Real time monitoring and storing to sql database where u can link them to user names or companies.
 
Excuse me, this software is written by yourself or there is one that is alredy done?
And if it's written by yourself, which programming language do you suggest? I searched for PHP and it seems "easy". Thank you.

In that particular case, I was telling a user what the software he was writing would have to do, to accomplish what he wanted, so it would have to be written by him.
To the best of my knowledge, there is no pre-made software for this specific application mentioned by the user.

As for it being easy, I do think it is easy yes, but then again I am a programmer so not really the best judge of what is easy in that regard.
If you don't have any programming experience, would personally suggest the python programming language, since there are just a wide variety of resources online to learn that specific language on the internet, and while I don't personally program with it, having used it a couple of times in the past it seemed like a fairly well-designed one.
 
In that particular case, I was telling a user what the software he was writing would have to do, to accomplish what he wanted, so it would have to be written by him.
To the best of my knowledge, there is no pre-made software for this specific application mentioned by the user.

As for it being easy, I do think it is easy yes, but then again I am a programmer so not really the best judge of what is easy in that regard.
If you don't have any programming experience, would personally suggest the python programming language, since there are just a wide variety of resources online to learn that specific language on the internet, and while I don't personally program with it, having used it a couple of times in the past it seemed like a fairly well-designed one.
Ok, I studied at school so I know a little of the programming world. Thank you!