This topic opens a new series of projects that show you how to build an access control system. The first iteration is simple: Users present their ID cards, and the system unlocks the door for the users whose cards are in the data table.
Most card readers on the market have the so-called Wiegand interface, and Tibbo offers a special Tibbit -- #08 -- to interface with Weigand readers. Our AppBlocks Demo Kit (ADK) comes equipped with such a reader, as well as all other inputs and outputs required for testing of all projects in the Access Control chapter.
All projects in this series can also be tested on CloudADKs. Since it is not possible to bring ID cards to a reader on a Cloud Kit, the CloudADK panel provides a text field for entering reader data and a button to send this string into the Wiegand port of the TPS.
Wiring in a Wiegand Reader
Here is the connection diagram for wiring a typical reader to Tibbit #08. In this diagram, the +5V power comes from your TPS. This is possible only if your reader can run on 5V power:
The electric door lock is controlled using a mechanical relay. You already saw the use of such a relay in the Scheduler (Sunrise & Sunset) project, as well as the Sprinkler Control chapter. In the ADK, this relay is connected to a green LED marked "RL1." The LED is on when the relay is on.
This and other LEDs of the Kit are also visible on CloudADKs.
The key block for working with Wiegand readers is the On Wiegand event block. It outputs the card's ID code as a string consisting of zeroes and ones.
Wiegand cards have a pre-defined format. A standard 26-bit Wiegand card allocates 8 bits for the facility code, 16 bits for user IDs, and two bits for parity checks. There are other Wiegand data lengths in circulation. Unless your customer actually pays attention to these Wiegand "conventions," it is entirely up to you how to interpret the Wiegand data. The simplest way is to view the entire code as the ID code. This is what we did in this project series.
User IDs are stored in the user_id table containing a single field -- the card_id. When the user presents an ID card, the card code is compared against the user_id table records. This happens in the Table Lookup block. The door_lock variable is set to 0 if a matching record is found. This is an auto-generated variable linked to the IO line controlling the door lock relay:
If you are working with a physical Kit (TPS+reader), you'll need to know the ID codes of your cards before you can add them to the data table. For this reason, ID codes are choed in the console every time you read the cards. You will notice that all codes appear in binary form. It is possible to modify the project to show the codes in Hex.
There is no need to find out what the ID codes are when working with the CloudADK. This is because you can send arbitrary card codes into the system. Add desired codes to the data table first. Then send the same codes "from the reader." The card format for CloudADK
There are three settings in this project. Two of those are the customary Ethernet DHCP and Ethernet IP settings. The third one is the lock_activation_duration setting. Every time the door is unlocked, the _lock_activation_tmr timer is loaded with the value of this setting. Once the timer counts to zero, the relay is turned off.
Setting and data table editing is performed via your device's web interface:
Reading a valid card activates the door relay for the lock_activation_duration number of seconds. On the ADK, this relay is connected to a green LED marked "RL1."
This LED is visible in the virtual panel of CloudADK Kits as well.