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 all projects in the Access Control chapter.

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.

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 (two hexadecimal characters) for the facility code, 16 bits (four hex characters) 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 echoed in the console every time you read the cards. You will notice that all codes appear in hexadecimal form.

Cloud ADKs allow you to emulate the reader output. To do so, enter a string of up to six hexadecimal characters into the Card Reader Output textbox and press Send Card ID. Since the codes are under your control, you can enter them directly into the data table.

The project has three settings. 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."

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. Also, the TPS' buzzer generates an audible tone during the alarm activation.

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).

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.

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:

Having worked through The Basics section of the Tutorial, you now know enough to take on a "real project." We start with a multi-step implementation of a device that is common in agriculture -- the Sprinkler (Watering) Controller. Such controllers turn the plant watering on and off according to a pre-defined schedule.

You already saw two simple applications of the Scheduler: The Scheduler project triggers the time printing every minute on the minute, while the Scheduler (Sunrise and Sunset) application synchronizes the street lights to the sunrises and sunsets. We open this chapter with a more generic example of Scheduler usage.

Let's say you want to automatically water your plants twice daily at 8 am and 4:45 pm. Each cycle should continue for five minutes.

Here is a sprinkler control application that hardcodes this logic. As you can see, the implementation comprises two schedules of the "every day at hh : mm" type and a timer.

Monitoring the Sprinkler Relay State​

The same relay used in the Sunrise and Sunset project controls the sprinkler in this one. On the AppBlocks Demo Kit (ADK), this relay is connected to a green LED marked "RL1." The LED is on when the relay is on.

The RL1 LED is visible in the CloudADK's virtual panel as well:

Hardcoding the watering start times and duration -- as we did in the first version of the application -- is a "quick and dirty" way of creating a Sprinkler Controller for personal use. If you are designing for your customers, a bit more "finesse" will be required to satisfy the general public. Obviously, the proper way is to have an editable schedule table. Each entry in this table would consist of the watering start time and the watering duration.

This is where the data tables come in. These are defined on the Data Tables page of the Features tab. Here is the structure of this project's sprinkler_schedule table:

As soon as a single data table is defined in your application, the Web Dashboard is enabled automatically. This differs from the settings, which must be exposed to the web or LUIS interface individually.

The corresponding AppBlocks block is called Table Lookup. It is the centerpiece of this application. Here is how the application works:

A Scheduler triggers the execution every minute, on the minute. The application then fetches the current date and time. The Table Lookup block compares the present time with the Time field of all table records. If there is a match, the sprinkler relay is activated, and the tmr_sprinkler timer is loaded with the value from the Duration field of the fetched data table record (the record that matched the current time).

The Get Current DateTime block fetches the current date and time. The Table Lookup block compares this with the Time field of the data table records. This works because the system understands that the Date component must be disregarded in the DateTime-to-Time comparison.

This project expands on the previous application by adding status messages displayed on the LCD. For this to work, you must have the TPS2L(G2) device -- only this model has the LCD (and keypad).

LCD messages are printed using the LCD Print block. The application prints two messages: "WATERING (SPRINKLERS ON)" and "IDLE". Click on either block to see the list of available properties:

LCD messages are printed within the bounds of a rectangle formed by the X Position, Y Position, Width, and Height parameters. The Text Alignment property defines the text alignment within this rectangle, while Text Orientation allows you to print the text normally, upside down, or vertically.

For example, to print the "IDLE" message in the middle of the screen, use X Position = 0, Y Position = 0, Width = 320, Height = 240, and Text Alignment = Middle Center.

It is great to have the watering happen on schedule, but sometimes you will want to manually operate the sprinklers, even if to test that the hardware works properly.

This Sprinkler Control project step adds a manual override: The TPS2L(G2) has a four-key capacitive keypad. The application displays "ON" over the first key (F2) and "OFF" over the fourth key (F4). Pressing the "ON" key turns the relay on, and the "WATERING (MANUAL)" message is shown on the screen. Pressing the "OFF" key turns the relay off.

The response to key presses is implemented through the On Keypad Pressed event block (the corresponding key is selected in the block's properties).