This is the 4th post in a series chronicling a small church’s experience with the Grandstream GDS3710 Door System. We like the product but the deployment has been like solving Rubik’s Cube. We found we had to do a lot of tinkering to get things working, something that shouldn’t happen with such a sophisticated product.
This article summarizes some of our lessons learned, particularly with regard to use of the keypad to enter PINS, the interpretation of the virtual number field and the various way the doors can be opened using the GDS3710.
References
- https://youtu.be/K7I4KJW0gD0 YouTube video introducing the product
- Release 1.0.3.32 firmware
The YouTube video is produced by a VoIP equipment distributer in association with Grandstream USA. It is deadly dull. Once you are familiar with the product (bloody knuckles are a sure sign), you can skip the boring marketing floss. Most of the good bits are between time 20 and time 30 or so. Highly recommended that you watch this 10 minutes that explains the tables and keypad techniques.
Our Use Cases
The door entry control system is a safety and convenience feature for our employees. It allows them to admit visitors while the door is locked without having to trot to the door from the far reaches to the building. We don’t rely on it for physical security of the empty building. There are regular locks for that. We have the following use cases.
- Members and tenants arrive after the building has been opened.
- Delivery people show up from time to time for a brief visit.
- Trades or parishioners visit for an extended stay making multiple entries and exits
Deliveries, etc.
The conceptual design is to use the door phone to view and chat with the visitor to determine the need for entry and if entry should be granted. The visitor rings the bell button. The door phone calls the staff. Staff interviews the visitor and grants admittance or releases the hounds. This was the first case we commissioned.
Extended stays with repeated entries
Staff arrivals, visiting parishioners, and visiting tradesmen are all similar. The GDS3710 provides the following mechanisms that support these use cases.
- Open door when an RFID token is presented
- Open door when an RFID and PIN are presented
- Open door when a PIN is presented
Setting up PINS
The door system has the following PINS
- Remote opening PIN
- Local PIN presented at the keypad
- Guest PIN presented at the keypad
The GDS3710 web GUI is used to set up the 3 PINS. Each is a number of 8 or less digits. These may be entered using Firefox or Chrome browsers. Safari PINS were not taking. Edge was not considered.
Presenting a PIN
A PIN starts with an asterisk (*) and and ends with a sharp (#) as in *1245#. This is not in the manual and Grandstream support won’t think to tell you this. Reference 1 came to our rescue. Once we knew this essential fact, PINS work without incident. They’re not very secure so they should be considered only for guest situations with short time to lives.
Setting up RFID Credentials
The Grandstream GDS3710 supports something you have or something you have plus something you know authentication. An RFID card or RFID FOB is the something you have. The PIN is something you know.
A GDS3710 can scan cards and put them in the card table. The web GUI lets you add identifying information and assign a PIN to support the have and know authentication model. RFID with PIN is the preferred way to use the RFID tokens. If a token assigned a PIN is dropped on site, it will not grant entry without PIN presentation.
The technique to scan cards is to sign in to the door’s web GUI, put the phone in card scan mode, and present the cards one at a time. Card scan mode is timed with the default being 5 minutes but longer time can be set in the web GUI.
Once the cards are scanned, each card can be associate with the following.
- A person by name
- A “virtual” or notional number commonly used to identify a tenancy
- A SIP number
- A POTS number
- An allowed hours schedule and a holiday schedule
When setting up RFID tokens, take care that the token is enabled. This is typically off display on a 1920×1080 display.
Door bell or call a tenant?
With the dial pad enabled, door phone can call a local SIP number or a tenant. When calling a tenant, the caller dials the virtual number. The phone looks up the SIP or POTS number and calls it. The the tenant answers, chats with the caller to identify and perhaps admit the caller. If the caller is to be admitted, the tenant dials the remote door open PIN. We don’t know if the *# syntax is required from a remote phone.
The other mode is to push the door bell button to call the receptionist. Once the call is initiated, the encounter proceeds as above.
If using a Grandstream GXV3275, a video call may be made. The GXV3275 can be configured with up to 10 door PINS. It will use the caller ID info to determine the PIN to use and send the DTMF signal to the GDS3710.
The caller id string is installation dependent. GDS3710 settings and PBX user settings influence the string presented. The GXV will display a caller ID on screen while the call is ringing. This string goes in the GXV table entry for the door.
Virtual Number and PIN
Tenants at the keypad can use their virtual number and PIN to open the door. When dialing this code and asterisk starts each component and a pound sign ends the text. For example, unlocking the door for tenant 1301 with PIN 4266 requires dialing *1301*4266#
Door Signals and Opening the Door
- 3 dash beeps — keyed input is not recognized
- 3 dash beeps — presented RFID credential is not recognized
- 1 dot beep — PIN or RFID credential accepted
- 1 dot beep — door release code accepted from the receptionist
Our doors are pretty quiet. It is not obvious that the door is released. There is a short but random time delay between the keying of the open code to the GDS3710 and the time the relay actually energizes the strike release. This happens almost silently. If a guest is pulling on the door handle before it is released, the door will not open. Don’t rush it. Say a couple of Mississippis.
Synchronizing Doors
Appoint one controller as the master and enter all of you credentials there. Send the data from the master to each of the secondary doors. If you are using Grandstream Door Manager, you can suck in the credentials from the door, edit schedules and holidays and set up the credentials a bit more conveniently.
Central Mode
In central mode, all data entry occurs at GDS Manager and is pushed to the doors. Local entry of cards or editing of cards in the door’s web GUI is disabled.
Door Controller Backup
The door controller has an option to back up its configuration and credentials database. Do this for at least one of your doors
Static IP addresses
The GDS Server should have a well known address. The GDS Manager host does not include MDNS or PNP support to track down its persistent helper. The helper logs door events and management events.
The door controllers can chat with a SYSLOG server. Again, no facilities to track this puppy down by MDNS or PNP.
The door controller can save snapshots of each entry granted to an FTP server. This beast needs to be in local DNS or have a static address. It can also PUT the images to an HTTP server. This is probably the easiest to do. NGINX runs nicely on a Raspberry PI, the same one we use to update firmware.
The door controllers can be configured to send Email when abnormal occurrences are detected. Since these are also logged to GDS Manager, we recommend forgoing setup of this feature.
The best way to manage static addresses is to set them up in your DHCP server.
Dismal Manor Dispatches 