I live in a condo complex of 160 units where I and a business partner have helped design and install a system with 2 drive gates and 2 ped gates. Not knowing a lot to start, and not having access to the horror stories that should about out there, a local fence company was hired to install things. And they screwed things up from the get-go. This company had a lot of experience (?) and no organization or engineering abilities, plus a desire for constant $$$ from call backs!
So now, 2 years later, we are stuck with equipment that was 10+ year old designs when installed (and still being produced by Doorking [avoid them!]), and all access is by their Windows only software (looks and installs like it was designed for Win 3.1). Communication is only by phone line or 2400 baud RS-232.
We intend to develop Linux software to talk to it, but short of replacing their boards with more modern ones - at $5K or more each - which the complex cannot afford - we have to make due with crap.
What's really needed is a Linux PC that is the fully programmable controller with wi-fi links to weigand rf, keypad, and prox detectors, and a small relay output board to handle the gate controller. And upgrading an older system to wi-fi may cost more than the origional installation.
There is a lot of additional control if you can get a signal when each loop detector triggers and their sequence, if the gate is really closed, off track, etc. Also, if the police or FD opens the gate, it needs to trigger an alarm - they have left with the emergency over and the gate open all night.
What ever is designed, it needs the support of people with hands on experience.
Physical Access Control - New Feature or Seperate Project?
Access control is definately something i would be interesting in progressing.. but I am not sure it should be a seperate project. If it is, it should be closely linked in to zoneminder. This would allow logging and provisioning to be done through zoneminder which would be beneficial.
An example of this would be taking a screenshot from a specific camera when access is granted or refused etc. This could be stored in the db and used to provide email notification etc. Many pro access control systems already do this.
As for the access control device itself, heres a few points...
IP vs RS485. I have seen a couple of posts saying ethernet should be the standard way of communicating with the access control device. I would disagree. Although many chips now incorporate ethernet and ethernet is fairly widespread in buildings it still has limitations. E.g. 100mtrs cable limit wheras 485 works well over distances in excess of 1km. TCP IP requires much more processing power and memory than basic RS485 comms and is more complex to implement. Where it is required a protocol converter could be used to interface an RS485 segment to an ethernet network.
Also the system should be able to work disconnected from a control PC so although the PC adds extra functionality it is not essential in the day to day workings etc.
An example of this would be taking a screenshot from a specific camera when access is granted or refused etc. This could be stored in the db and used to provide email notification etc. Many pro access control systems already do this.
As for the access control device itself, heres a few points...
IP vs RS485. I have seen a couple of posts saying ethernet should be the standard way of communicating with the access control device. I would disagree. Although many chips now incorporate ethernet and ethernet is fairly widespread in buildings it still has limitations. E.g. 100mtrs cable limit wheras 485 works well over distances in excess of 1km. TCP IP requires much more processing power and memory than basic RS485 comms and is more complex to implement. Where it is required a protocol converter could be used to interface an RS485 segment to an ethernet network.
Also the system should be able to work disconnected from a control PC so although the PC adds extra functionality it is not essential in the day to day workings etc.
Reesmarine - Free photo classifieds for boats for sale. www.reesmarine.com
WiFi and redundancy
I would do it with WiFI for all communications - digging trenches or adding wires to existing conduits is often impractical and costs big money vs WiFi.
I would prefer a dual PC system with fail over or voting to a dedicated server. The data base of authorized users has to be kept somewhere and a dedicated server needs to be updated often - and the dedicated server has to store information about the gate actions until it can be transferred back. Also, battery backup, failure mode functionallity, capable of full operation from -75 to +175 degrees F, etc. That isn't a simple controller. Nor is it cheap!
The PCs connected by WiFi can be in a climate controlled location except for keypads and prox detectors, and the gate actuator.
We put fans on our gate actuators - they were exceeding +150 in July (Phoenix, AZ) and now stay less than 15 degrees above the ambient. No bad boards this year, with 5 replaced last summer just because of heat. And the company that designed and built that unit is in Tucson, AZ so they should have known better! Or they love to sell replacements.
I would prefer a dual PC system with fail over or voting to a dedicated server. The data base of authorized users has to be kept somewhere and a dedicated server needs to be updated often - and the dedicated server has to store information about the gate actions until it can be transferred back. Also, battery backup, failure mode functionallity, capable of full operation from -75 to +175 degrees F, etc. That isn't a simple controller. Nor is it cheap!
The PCs connected by WiFi can be in a climate controlled location except for keypads and prox detectors, and the gate actuator.
We put fans on our gate actuators - they were exceeding +150 in July (Phoenix, AZ) and now stay less than 15 degrees above the ambient. No bad boards this year, with 5 replaced last summer just because of heat. And the company that designed and built that unit is in Tucson, AZ so they should have known better! Or they love to sell replacements.
John,
How many users are you planning on coping for? A microcontroller with some flash memory attached is more than capable of dealing with even the largest user list.
I agree with you on the digging trenches but I still dont agree that Wifi is the way to go. Ok its well established but I think a slow speed and much more reliable wireless data link would prove more reliable. If the micro is making the decisions then the only time data would need to be sent is either for logging or changing the access lists. Wifi is cheap when it comes to home computer parts but still very expensive for embedded systems. Bluetooth would be far more usable and can be easily encrypted also.
On the temp thing thats just bad design. Another reason microcontrollers would be beneficial is that they dont generate much heat so dont have the problem of heat dissapation in a high temp environment.
I am currently working on an general IO board that will use an open protocol over RS485. I am planning on using this with ZM when i get round to getting my ZM system up and running. I am also working on some RFID access control options to bolt on to the IO board. I guess by the end of it I plan to make a device that would be capable of gate control with all the extra ins and outs that they require. I am trying to keep all the protocols and details open but without compromising the security of the system
If anyone has any ideas then please let me know.
How many users are you planning on coping for? A microcontroller with some flash memory attached is more than capable of dealing with even the largest user list.
I agree with you on the digging trenches but I still dont agree that Wifi is the way to go. Ok its well established but I think a slow speed and much more reliable wireless data link would prove more reliable. If the micro is making the decisions then the only time data would need to be sent is either for logging or changing the access lists. Wifi is cheap when it comes to home computer parts but still very expensive for embedded systems. Bluetooth would be far more usable and can be easily encrypted also.
On the temp thing thats just bad design. Another reason microcontrollers would be beneficial is that they dont generate much heat so dont have the problem of heat dissapation in a high temp environment.
I am currently working on an general IO board that will use an open protocol over RS485. I am planning on using this with ZM when i get round to getting my ZM system up and running. I am also working on some RFID access control options to bolt on to the IO board. I guess by the end of it I plan to make a device that would be capable of gate control with all the extra ins and outs that they require. I am trying to keep all the protocols and details open but without compromising the security of the system
If anyone has any ideas then please let me know.
Reesmarine - Free photo classifieds for boats for sale. www.reesmarine.com
We currently support a 170 unit condo complex, with an average of 2 remotes each. There are 2 drive gates and 2 pedestrian gates, with 8+ cameras existing or planned near each gate as well as cameras to monitor the coin-op laundry room and pools.
We are setting up WiFi & wired LAN to place control and video monitoring computers where it's practical, not where restricted by distance.. RS-232 communication works well over LAN with Lantronics nodes. Bluetooth would work well also, but primarily between the PC and the gate control boards. Some of our signal nodes are close to 1200 feet apart with 5 story buildings and big trees in the way. So our plans call for WiFi switches on the tops of the buildings wired down to relevant places in the buildings.
Another area we are setting up is a database that will contain all relevant info about each owner, tenant, vendor, etc. with a history, and will be able to actively update the remote gate control boards when new data is entered.
Make sure you have Weigand protocols in your box unless you build the sensors yourself. Also, battery backup is required for the whole system. In the US, we have to have key switches and strobe readers for police and fire to get through the gates.
We are setting up WiFi & wired LAN to place control and video monitoring computers where it's practical, not where restricted by distance.. RS-232 communication works well over LAN with Lantronics nodes. Bluetooth would work well also, but primarily between the PC and the gate control boards. Some of our signal nodes are close to 1200 feet apart with 5 story buildings and big trees in the way. So our plans call for WiFi switches on the tops of the buildings wired down to relevant places in the buildings.
Another area we are setting up is a database that will contain all relevant info about each owner, tenant, vendor, etc. with a history, and will be able to actively update the remote gate control boards when new data is entered.
Make sure you have Weigand protocols in your box unless you build the sensors yourself. Also, battery backup is required for the whole system. In the US, we have to have key switches and strobe readers for police and fire to get through the gates.
Hi, new here. Found this when looking for solutions for this problem...
found this:
http://www.pro-active.fr/solutions/acce ... ntegrators
and this where you can buy it. Unfortunately it's french...
http://www.noralsy.com/souscategorie.as ... tegorie=10
But, the control unit runs linux and seems developer friendly, so maybe it would work?
found this:
http://www.pro-active.fr/solutions/acce ... ntegrators
and this where you can buy it. Unfortunately it's french...
http://www.noralsy.com/souscategorie.as ... tegorie=10
But, the control unit runs linux and seems developer friendly, so maybe it would work?
I cant find any prices for this on the web site. Do you have any idea what the control units would cost.
For me a system needs to run on its own without the need for a computer connected. The computer (ZM etc) would then provide enhanced functionality such as provisioning and logging and would allow us to tie the event logs to a capture from a specific camera.
I think we need to find or develop some hardware that is has open communications between ZM and the devices so that it is possible to make it work for many different scenarios. We need something that is versatile yet cost effective to do this.
For me a system needs to run on its own without the need for a computer connected. The computer (ZM etc) would then provide enhanced functionality such as provisioning and logging and would allow us to tie the event logs to a capture from a specific camera.
I think we need to find or develop some hardware that is has open communications between ZM and the devices so that it is possible to make it work for many different scenarios. We need something that is versatile yet cost effective to do this.
Reesmarine - Free photo classifieds for boats for sale. www.reesmarine.com
I apologize for the thread reawakening...
I really would like to see a Linux Physical Access Controls sister project. The projects would be designed to interact together well.
It would be pretty simple to design, really. You would have all nodes attached to the network, with GumStix-style embedded computers at the doors. A central PAC server would handle all the decisions.
I really would like to see a Linux Physical Access Controls sister project. The projects would be designed to interact together well.
It would be pretty simple to design, really. You would have all nodes attached to the network, with GumStix-style embedded computers at the doors. A central PAC server would handle all the decisions.