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.

Wiring in a Wiegand Reader​

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.

If you do not have the Kit, 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.

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:

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:

In the second Access Control project step, we add the manual exit button. To simplify testing, a keypad key is used in lieu of an actual physical switch wired into your TPS' IO line.

The keypad and the corresponding On Keypad Pressed block have already been introduced in the Sprinkler Control 4 project. Pressing the F1 key (marked "EXIT" on the LCD) has the same effect as reading a valid ID card -- the door lock is activated for the lock_activation_duration number of seconds.

The third step in creating a full-featured access control application adds the door open sensor and an alarm relay. Again, a keypad key is used instead of an actual door sensor wired to your TPS' IO line to simplify testing. The F4 key (marked "DOOR SENSOR" on the LCD) stands for the actual door open sensor.

The door open sensor has two functions:

• When the door is unlocked by reading a valid ID card or pressing the exit button (F1), and then the door is "opened" (F4), the lock is deactivated immediately: Since the door opening has been detected, there is no reason to wait for the lock_activation_duration time to elapse.
• Opening the door without presenting a valid ID card or pressing the exit button is interpreted as a forced entry, and the alarm relay is activated. The alarm relay is the second relay of Tibbit #03-1.

In the AppBlocks Demo Kit (ADK), the door lock relay is connected to a green LED marked "RL1." The alarm relay is connected to a red LED marked "RL2."

Once the alarm relay is turned on, it can only be turned off through the web dashboard.

Web dashboards have already been discussed in the Sprinkler Control 5 project. The dashboard of the present project introduces a new type of dashboard widget -- the Button widget.

Dashboard buttons send commands, and commands are defined in the Command page of the Features tab. In this case, the disable_alarm command is sent.

When a command is sent, a corresponding On Command event block is triggered (each On Command block must have a command selected for it):

This project step adds the id_expiry DateTime field to the user_ids table. Once the current date and time are past the expiry date and time for an ID card, it stops working.

The project introduces an important AppBlocks concept -- the date and time arithmetic. The DateTime and Time data types of the AppBlocks system are serialized values. As such, they can be calculated upon and compared like regular numbers. In this application, the following block makes the DateTime comparison:

This step adds logging of everything that is going on in the access control system.

Logging has already been introduced in the BP Sensors to Log project.

Here is the sample log generated by this application:

This final step shows you how to work with real inputs. For simplicity, all previous project iterations implemented the exit button and the door open sensor as keypad buttons. This is convenient for testing, but real life requires wiring a real button and an actual sensor to your TPS. In this project's configuration, external inputs are wired in through Tibbit #00-1 (four direct IO lines).

Tibbit #00-1 is very convenient for testing: To switch its inputs from HIGH to LOW, you only need to short them to the ground. Real-life applications are unlikely to use this Tibbit as it offers no protection against noise or excessive voltages. Tibbits #04-X (optically isolated inputs) and #54 (four optically isolated dry contact inputs) are much better candidates for the job... but this is a demo, so #00-1 will do just fine.

Three Input Modes​

There are three input modes for a TPS IO line: a standard input mode, a button input mode, and an interrupt input mode. The following table details the differences between the three:

* The number drops to 4 if you enable the LCD and keypad of the TPS2L system.

Now that you know what choices are available, you can appreciate the ones we made for this application. Predictably, the exit button line is operated as a button. The door open sensor line is configured as an interrupt. This ensures a fast reaction to any changes in the sensor state. The corresponding event block is called On Interrupt. This is the first use of the block in these Tutorials.

Testing the Inputs​

In the AppBlocks Demo Kit (ADK), the four inputs of Tibbit #00-1 are connected to four pushbuttons marked "BTN1~BTN4." BTN1 functions as an exit button. BTN4 stands in for the door open sensor; pressing it is like opening the door.

In real life, door open sensors usually work in reverse -- the switch inside the sensor is closed when the door is closed (this is equivalent to holding the button pressed) and is opened when the door is opened (equivalent to releasing the button). We strayed from this convention to make the testing more convenient.

If you do not have the ADK, you can test the inputs using a piece of wire. First, connect one of its ends to the ground terminal, then touch the exit button and door open sensor inputs with this wire:

Have you noticed? Each IO line of Tibbit #00-1 can also function as an output. This is because this Tibbit's lines are bidirectional, and it is your job to configure them correctly: