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:

In this step, we modify the previous project to publish the sensor data to the MQTT server instead of saving it into the log.

MQTT is a popular protocol for machine-to-machine communications. It is often used to transmit sensor data. This project publishes the seven data streams from four Bus Probe sensors to a test server located at 104.40.239.93.

MQTT is configured on the MQTT page of the Features tab. Here is this application's configuration:

Publishing of MQTT data is performed using the MQTT Publish block. This application has four such blocks, one for each data stream. Click on any block to inspect its properties:

Testing MQTT​

To see the application in action, you will need an MQTT client. We rely on the MQTT Explorer software -- it is free and simple to use. You can download it here:

http://mqtt-explorer.com/

Launch the MQTT Explorer and click + to create a new connection. Fill in the connection parameters as shown below:

Click CONNECT. The sensor data will be under demo > devices > bpmqtt:

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: