In the Settings project, you learned how to edit your application's settings through the web interface. The caveat is that, in order to access the web interface, you must know your device's IP address first. Sure, you could use Device Explorer to discover the current IP, but you wouldn't expect "regular" users to do it whenever they need to access your device, right?

This is where the Loadable User Interface System (LUIS for short) comes in. The name is a mouthful, but the concept is simple: LUIS allows editing your device's settings over the BLE (Bluetooth Low Energy) connection. You view and edit the settings using the LUIS smartphone app. In a nutshell, this is "HTML over Bluetooth." The LUIS app is a simple "browser" that receives HTML pages from your device and presents them on the screen.

Since the LUIS interface works over BLE connections, your TPS must be fitted with the WA2000 Wi-Fi/BLE add-on module.

Linked Settings​

This project is based on the Settings project. The stg_timer_reload_value setting is still present, but you will notice that two new ones have been added: The NETCP (Ethernet DHCP) and NETIP (Ethernet IP) settings. These look like regular settings, but there is something interesting about them: they are linked to the DHCP and IP Address properties of the Ethernet interface.

Many properties of many pages of the Features tab can be linked to settings. To do so, press any of the Link to setting buttons. This will immediately create a linked setting.

Linking a property to a setting allows you to expose it to the outside world, for example, via the web or LUIS interface. No longer hardcoded in your project, it will now be user-editable. To enable the editing of all three settings both via the web and LUIS interfaces, they have been added to the General group of each:

• Web Dashboard page (Settings sub-page)
• LUIS page

Testing the LUIS Interface​

Open the LUIS app once the application has been uploaded onto your TPS and is running. The app should show your device's name as Here I am! This is defined on the Bluetooth (BLE) page of the Features tab.

Click on this name, and the settings page will load. You can now check the current device IP and even edit your settings from your smartphone!

When your application is simple, you can have the same list of settings exposed through the LUIS and web interfaces. If the application is rather complex, keep the LUIS list to a minimum while providing full editing features in the web interface. There are certain capabilities -- such as working with data tables or viewing event logs -- that only the web interface can handle anyway. The rule of thumb for large projects should be that LUIS shall help users find the device and perform other essential functions. The rest of it should be relegated to the web interface.

Timers do not have to count down constantly; they can be started and stopped.

Assigning a non-zero value to a timer (i.e., in the Variable Set/Math block) variable always enables the countdown. There is also a somewhat redundant Timer Start block, which does the same job. To pause the timer without resetting its value, use the Timer Stop block.

In this project, pressing the MD button starts the timer. If you keep the button pressed, the timer will count to zero. If you release the button while the timer is still counting, the timer will be stopped, and its current value will be printed to the console.

Because timers exist both as a feature and as an automatically generated variable, it is possible to use a Variable/Set block to behave the same way as a Timer Start block in order to start a timer.

Up to this point, all blocks of every project were connected sequentially, like beads on a string. This means that an output of one block only connected to a single input of the next block. This doesn't have to be the case. It is possible to connect one block's output to several downstream blocks in a fashion called block stacking.

This project demonstrates how the stacking order of the blocks on the flowchart defines the order of execution. The rule is simple: Out of N stacked blocks, the topmost block executes first, and the lowest block executes last.

Two of the three stacked blocks in this application perform calculations, while the third one prints the result. If the stacking order is left unchanged, the result will be 30. Swap around the topmost and middle stacked blocks, and the result will be 20! Move the Debug Print block to a new position, and you will print the var_x value before all the calculations are performed!

This is the first project in the Tutorial where we use the On Boot event block. Use this block when you need to perform some actions right after the device (re)boots.

This project adds a bit of complexity to the Variables and Arithmetic application of the previous topic. Pressing the MD button will keep incrementing the Counter variable, but the value of this variable will be reset to 1 once it exceeds 10.

Your TPS' MD button was introduced in the Hello, World project.

The value of the Counter variable is limited to 10 using a Condition block. It introduces the flow forking: Comparing the Counter value to 10 results in the execution taking the True or False path in the application's logic.

The project also demonstrates that two execution paths may converge on a single point. This is known as a join.

Eagle-eyed readers will also notice another difference from the Variables and Arithmetic application: Rather than relying on the Arithmetic block to perform calculations, this application takes advantage of the more versatile Variable Set/Math block:

The Variable Set/Math block allows entering math formulas, and these can go way beyond simple addition, subtraction, multiplication, and division offered by the Arithmetic block. The formulas must comply with the syntax of the Tibbo BASIC language. Luckily for AppBlocks' users, this syntax largely follows the "natural" way of writing formulas.

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: