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:

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.

In this next iteration of the Sprinkler Control project, the ability to monitor the state of and control the sprinkler relay remotely is added. This is done through the dashboard, a page of your device's web interface that can host widgets. The dashboard is configured on the General subpage of the Web Dashboard page of the Features tab. Open this page to see the widget this project uses:

The widget is of the Switch type. The switch is "connected" to the manual_override variable:

This "connection" is bi-directional:

• If you push the "ON" or "OFF" button on the TPS, the dashboard switch will reflect the current manual_override state.
• If you flip the switch on the dashboard, the manual_override variable will be updated.

To react to the dashboard switch flips, an On Variable Changed event block has been added to the application. This event triggers when the corresponding variable value changes.

The On Variable Changed block was first introduced in the Settings project.

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.

In the final version of the Sprinkler Control project, we go multi-zone. The application only controls two relays (to save the slot space inside your TPS), but you can easily extend it to individually control many more watering zones.

The first step in adding the multi-zone support was to add the sprinkler_num field to the sprinkler_schedule table. Notice how the field's Minimum and Maximum properties come in handy here: the minimum sprinkler number is 1, and the maximum is 2:

The second step was adding the For-Next Loop block to the diagram. This is the first project where we do "loops." Click on the For-Next Loop block to open its properties. As you can see, the block iterates from 0 to 1 (inclusive). The block runs twice, first, with the value of 0, and second, with the value of 1.

When a block chain is connected to the Iterate output of the For-Next Loop block, this entire chain runs once for each for-next loop. This means the application will perform the Table Lookup and everything behind it twice.

Record Offsets​

Now it is time to look inside the Table Lookup block. The element interesting to us right now is the Record Offset property. The current_iteration parameter of the For-Next Block is there. The Table Lookup will first run with the Record Offset of zero and then with the Record Offset of one.

When at zero, the Record Offset instructs the Table Lookup block to search from the beginning of the table and find the first data table record matching the search criteria. Setting the Record Offset to one will make the Table Lookup block search for the second record matching the search criteria.

If you fix the record offset at zero, this application won't work correctly when both sprinkler relays are to be activated simultaneously. The following example illustrates why. Let's say that you have this watering schedule:

At 08:00 AM, the first record will be fetched. At 08:30 AM, the second record will be fetched. Now, what will happen at 06:00 PM? At the first for-next loop iteration, the third record will be fetched. When the loop runs for the second time, the same third record will be fetched again -- that is, if the Record Offset parameter is always at 0. If this parameter is set to match current_iteration, then the first matching record (the third record) will be ignored, and the second matching record (the fourth record) will be found!

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.

Monitoring the Sprinkler Relay State​

On the AppBlocks Demo Kit (ADK), the first "sprinkler" relay is connected to the green LED marked "RL1." The second "sprinkler" relay is connected to the red LED "RL2." Either LED is on when the corresponding relay is on.