This project introduces a new storage type -- settings. Settings are kept in your device's EEPROM. They are referred to as "persistent storage" because they retain their values even when the device is powered off. Settings are incredibly important, as they provide a way to store your application's operating parameters.

This project builds on the Timers application. It uses a single setting to store the reload value for a (one-shot) timer.

Settings are defined on the Settings page of the Features tab:

Every time you add a setting, a corresponding variable of the same name is created. This is very similar to (one-shot) timers, which also have corresponding variables.

Settings have the same list of types available to them as variables. You can directly use settings in math expressions, just as you would use regular variables. You will notice that in addition to all the properties variables have, settings of certain types can also be limited in the value range:

Since the settings are stored in the EEPROM, and EEPROMs have the maximum number of write cycles they can endure, avoid designs that constantly rewrite the setting data. Depleting an EEPROM IC is not as impossible as one might think!

Settings as Links to the Outside World​

Since settings store your application's operating parameters, it is usually necessary to access them "from the outside." This project facilitates editing its setting through the device's web interface.

The web interface is enabled through the Web Dashboard page of the Features tab. Inside the Web Dashboard, there is a Settings sub-page. Every setting that needs to be exposed through the web interface must be manually added there. Since this application only has a single setting, it is this one setting that has been added to the Settings sub-page of the General group.

Once you add anything to the Web Dashboard, the Web (HTTP) Server is also automatically enabled.

Accessing the Web Interface​

To access the web pages of your TPS, you will need to assign a valid IP address to it first. This is where the Ethernet page of the Features tab comes into play. The DHCP property is set to Enabled by default. Your TPS device will get a valid IP address from the DHCP server, but how will you know what this IP address is?

The simplest way is to use the Device Explorer:

Open it after the application is uploaded onto the device and starts running. Click Refresh to make sure you are looking at the latest data. The Device Explorer can be accessed at any time by pressing this button in the bottom left corner of the page:

Note the IP of your device, and point your browser to this IP. Voila, you have access to your application's lone setting:

Responding to Setting Value Changes​

There is still one last trick to show you in this project: Responding to setting (variable) value changes. The On Variable Changed event block triggers every time the corresponding variable changes its value. In this application, changing the setting value will cause a debug message to be printed.

You can use the On Variable Changed block to report value changes for plain variables and settings but not for timers.

Now let us modify the BP Sensors to MQTT project to explore a different subject -- the use of network interfaces other than Ethernet.

Ethernet is not the only network interface TPS devices have. If your TPS is equipped with the WA2000 Wi-Fi/BLE add-on, you can also enable Wi-Fi communications:

Wi-Fi is configured on the Wi-Fi page of the Features Tab:

In this project, three Wi-Fi properties -- SSID, Security Type, and Password are linked to properties. You can edit these properties in the LUIS app.

AppBlocks treats Wi-Fi as a secondary interface that will only be used if Ethernet -- the system's preferred interface -- becomes unavailable. Therefore, you will need to unplug the Ethernet cable to see the application switch to the Wi-Fi interface. As soon as the cable is plugged back in, the application will resume using the Ethernet interface.

To prepare for the potential switchover, the application associates with the access point and attempts to maintain the association at all times. This way, the Wi-Fi is ready to roll as soon as the Ethernet connection fails.

AppBlocks defines the "Ethernet down" condition as the failure of the Ethernet link. This is when the yellow link LED of your TPS turns off. This happens if you unplug the Ethernet cable or power down the network switch your TPS is connected to. AppBlocks is not yet able to detect other problems with your LAN.

Unplugging the Ethernet cable while running in Debug mode poses a problem: All console messages are sent via the Ethernet interface. If any messages are sent to the debug console, the application will get stuck at the first such message -- the system will wait for the message to get through, and this won't happen until you plug the Ethernet cable back in.

This project switches the Logging output to LCD_logging to avoid this situation. This is selected on the General page of the Features tab:

Testing Wi-Fi Switchover​

Now you are all set to test the WI-Fi switchover:

• Run the application in debug mode
• Configure your Wi-Fi connection using the LUIS app
• Make sure the MQTT server is receiving the sensor data published by your TPS
• Unplug the Ethernet cable -- messages on the LCD will tell you that your TPS is now using the Wi-Fi interface
• Plug the Ethernet cable back in -- the system will switch to using the Ethernet connection

Wi-Fi LED Patterns​

Your TPS has five blue LEDs. When the Wi-Fi interface is active, these LEDs show the status of your Wi-Fi connection.

When the TPS' Wi-Fi interface is trying to associate with an access point, blue LEDs show this "running" pattern:

When the Wi-Fi interface is associated with an access point, the five blue LEDs display the signal strength. The stronger the signal, the taller the LED bar will be. For example, here is the pattern for the "four out of five" signal strength: