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:

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.

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.

Notice the two cases of parameter passing in this application. The first instance is passing the current date and time from the Get Current DateTime block to the Table Lookup block. The latter receives the date and time in the time_now parameter. The second instance is passing the watering duration from the Table Lookup block to the Variable Set/Math block. The latter receives the watering duration (from the fetched field) as the Duration parameter.

This, and many other projects, takes advantage of the LUIS interface. The application makes two settings -- Ethernet DHCP and Ethernet IP -- accessible from the LUIS smartphone app.

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.

The numbers 320 and 240 come from the TPS screen resolution, which is 320 x 240 pixels.

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

There is also the On Keypad Released event block.

Explore how this application implements overrides. This is done correctly: Once you have enabled the sprinklers manually, the end of scheduled watering will not turn the relay off. This logic is implemented through the manual_override variable.