Welcome to the AppBlocks Tutorial -- a collection of projects that cover around 90% of the system's functionality. Go through these applications, and you will have a good idea of what can be done with AppBlocks.

To make your life easier, most projects in this Tutorial run on a single TPS2L(G2) configuration. The only exception is the 4G (Cellular) Switchover project; it will make you swap around some Tibbits.

Here is the configuration:

AppBlocks Demo Kit (ADK)​

To simplify your testing even further, we have created the AppBlocks Demo Kit (ADK). The ADK incorporates the TPS2L system of the abovementioned configuration, as well as all necessary peripherals. This Kit is the best vehicle for learning how to develop AppBlocks applications.

Note: The ADK does not include a 4G Tibbit (#45) needed for running the 4G (Cellular) Switchover project.

Testing Without the Kit​

To run the projects without the ADK, you will need the following:

• A card reader with a Wiegand interface.
• Bus Probe (BP) sensors #02 (temperature/humidity) and #03 (ambient light).
• A 12V/1A wall power adapter.
• A test LED with a current-limiting resistor and two wires. This LED is needed for the PWM Light Control - Ver. 1 and Ver. 2 projects. It's OK if you don't have this LED, or, for that matter, even the Tibbit #16 (PWM). You can evaluate these projects just by looking at their debug output.
• A piece of wire for testing TPS inputs. It is needed only for the Access Control 6: Real Inputs project. Skip it if you do not have the wire or do not feel comfortable poking around with it.
• A 4G Tibbit (#45) in the version suitable for your region. This Tibbit is only required for one project -- 4G (Cellular) Switchover. Naturally, you will need a working SIM card as well.

Happy testing, and please let us know if you have any problems, questions, or suggestions.

Here is a cool demonstration of the Scheduler's capabilities: This project takes advantage of the special Sunrise and Sunset features offered by the Scheduler."Sunrise" and "Sunset" refer to the "official" sunrise and sunset times for the specified geographical coordinates. Obviously, these times change throughout the year.

The project defines two schedules, one for sunrises, and one for sunsets. The corresponding On Scheduled Event blocks then turn a relay on or off. The relay is meant to control a street light.

For the application to work correctly for a given location, it must be preset with this location's coordinates. This is done through the Latitude and Longitude properties of the General page. The Time Zone must be set correctly as well. Linking these three properties to settings and exposing the settings through the web or LUIS interface will enable your users to deploy the devices anywhere in the world.

Controlling a Relay​

This is the first project that touches on controlling IO lines. The application drives a relay; this is done through the light_on_when_low variable.

TPS relays are activated by bringing their control lines LOW, which is what the light_on_when_low variable name means.

IO lines are named on the Hardware tab: Click on Tibbit #03_1 to see the names of its control lines:

As soon as a Tibbit like this one is added to the hardware configuration, several linked variables -- one for each IO line -- are created. You can see these "auto-generated variables" on the Variables page of the Features tab.

This is similar to how you get auto-generated variables when you add a timer or a setting to your project.

Auto-generated variables linked to IO lines are of the boolean type. As we explained in Variables and Arithmetic, in addition to the four main variable types available to AppBlocks users, a few additional types are lurking in the system. These types often exist for interfacing AppBlocks with the outside world. The boolean type is one such case.

You probably know that IO lines of digital devices can be configured as inputs or outputs. Driving a relay requires an output. Just having Tibbit #03-1 in the hardware configuration already defines all related IO lines as outputs, and this is why you don't have to deal with line configuration for this Tibbit. Other Tibbits, for example, #04-1, which has optically isolated inputs, require their IO lines to be inputs, so this is configured automatically as soon as you "insert" them. There is also the third category of Tibbits with bidirectional IO lines. For such Tibbits, you must manually define the line direction for each IO line. One example of such Tibbits is #00-1 (four direct IO lines). You will meet this Tibbit in the Access Control 6: Real Inputs project.

Monitoring the Relay State​

On the AppBlocks Demo Kit (ADK), the relay used in this project is connected to a green LED marked "RL1." The LED is on when the relay is on.

In the previous topic, we explored the Wi-Fi interface and how your device can be configured to automatically switch over to Wi-Fi if the Ethernet link is unavailable. In addition to Ethernet and Wi-Fi, TPS devices support 4G communications. This project uses the LTE Tibbit (#45) as a backup way to send data to the MQTT server when the Ethernet connection goes down.

Note: The AppBlocks Demo Kit (ADK) does not contain Tibbit #45. You'll need to obtain this Tibbit separately if you wish to test this project.

4G is enabled on the Cellular page of the Features tab:

As with Wi-Fi, AppBlocks treats cellular as an alternative interface that will only be used if Ethernet -- the system's preferred interface -- becomes unavailable. Therefore, you must unplug the Ethernet cable to see the application switch to the 4G connection. As soon as the cable is plugged back in, the application will resume using the Ethernet interface.

Unlike with Wi-Fi, the system does not enable the 4G connection until it is actually needed. This is because sending and receiving data over 4G costs money, and there is always some traffic over 4G links, even when your system is not sending anything meaningful. To avoid wasting your funds, 4G only gets going after the Ethernet link fails and is shut down as soon as the Ethernet link is restored.

This project runs with Wi-Fi disabled, but you can enable it by yourself to see the switchover between all three interfaces:

• The Ethernet is the preferred interface. The Wi-Fi interface will be unused (but associated with the access point) whenever there is an Ethernet link. 4G will be disabled.
• If the Ethernet link goes down, the application will attempt to use Wi-Fi.
• If it is impossible to associate with an access point, 4G communications will be attempted.

4G LED Patterns​

As with Wi-Fi, TPS uses the five blue LEDs to tell you about the status of your 4G connection.

When the 4G interface is in the process of linking up to the cellular network, the following dynamic pattern plays on the LEDs:

When the link is established, you will see this static pattern:

This project makes the device act as a Modbus master to poll 4 BP sensors and display the values of the sensors on the console. The BP sensors are configured in the Modbus Master feature of the Features tab, where the device id and polled register are set for each probe.

This project adds line chart widgets to the dashboard to display the values of the BP sensors as a supplement to the console output.

This project adds logging to the BP Sensors project. This is done by enabling the LOG table in the Log feature of the Features tab, and then by adding an Add to Log to the diagram.

Logging the BP sensor values is useful in this project to store the data, for instance for later analysis.

This project adds MQTT publishing to the BP Sensors project. A MQTT broker is already configured in the MQTT feature of the Features tab for testing purposes. We can verify that the MQTT messages sent by the device are correctly published using MQTT Explorer.

Here is another Modbus project. This one polls two BP sensors -- BP#02 and BP#03 -- and prints the data into the debug console. These two sensors provide three data streams, and the application prints all three values at a time.

Our AppBlocks Demo Kit (ADK) is equipped with the BP#02 and BP#03 sensors, so the Kit owners will be able to run the application immediately.

As with the previous project, the IDs and registers of the BP sensors are configured on the Modbus Master page of the Features Tab. For example, here is the configuration for the temperature and humidity sensor (BP#02):

Here is what the application's output looks like:

This project iteration expands on the previous one and adds a dashboard with seven line charts representing the seven data streams the application receives from the two connected Bus Probes (BP Sensors).

Dashboards were first introduced in the Sprinkler Control 5: Web Dashboard project.

Three Line (chart) widgets are added to the dashboard to achieve this. Each widget selects one of the three variables to visualize.

Since some of the data received from BP sensors requires conversion to standard measurement units, a second set of variables was created to hold the final values. For example, there is the output_bp02_temperature variable containing the converted temperature received from the BP#02 sensor. It is this variable that is selected in one of the dashboard widgets.

Here is what the dashboard looks like when the application is running:

This project version modifies the previous one in the following way: Instead of charting the sensor data on the screen, the application records the sensor data in a Log.

Logs are special data tables that can only be appended to. There may only be one log table per device. Log table structure needs not to be defined in advance -- your application may add log columns on the fly. There is no way for the application to clear the log. This can only be done by the user through the web interface.

Logging is enabled on the Log page of the Features tab. Records are added using the Add to Log block. Click on this block in the current application to examine its properties:

As you can see, log records consist of key-value pairs. The key is the name of the field (column) the data will go into. The value is the data itself. Log fields are stored in the string format, so there is no division into data types here.

If an invocation of the Add to Log block defines a key (column) that doesn't yet exist, this column is added before appending a new record. Add to Log blocks do not have to fill out every existing field -- supplying partial data leaves the remaining fields blank.

Calling the Add to Log block with key1-value and then calling this block again with key2-value is different than calling the block once with both key1 and key2 present. The first sequence will result in adding two records. Both records will have one of the fields filled in and one of the fields empty. Only one record will be added in the second case, and it will have data in both fields.

This application supplies all the key-value pairs every time. Here is how the log looks in the web interface: