Troubleshooting Guide

Introduction

The key to debugging connectivity issues in a connected product system is to systematically isolate each component of the system. This guide teaches you how to analyze and test each component of your connected product system.

Wi-Fi Access Point

Scenario: The device cannot connect to the Wi-Fi Access Point (AP). Test: Use a smartphone or personal computer to connect to the Wi-Fi AP, and then attempt to access a web page. ../../_images/device.png

Test 1

  1. Use the personal computer to connect to the Wi-Fi Access Point (AP). Make sure that the computer does not have any other Internet connections that it can fall back on.Remove any Ethernet connections from the personal computer. If there are multiple Wi-Fi APs in the area, make sure that the computer cannot connect to these other Wi-Fi APs.
  2. Open a web browser.
  3. Use the web browser to access a highly-availabe page, such as www.google.com.

Test 2

If Test 1 failed, then there is either a problem with the Wi-Fi Access Point (AP) itself, or the Wi-Fi AP’s connection to the Internet. You can isolate the problem by performing the following tests:

  1. Replace the Wi-Fi AP with a different model of Wi-Fi Access Point.If the device can now connect to the Internet using the new Wi-Fi AP, then the original Wi-Fi AP is the problem.
  2. Take the Wi-Fi AP to a different environment. Ideally this second location is geographically removed from the first environment.If the device can successfully connect to the original Wi-Fi AP now, then the Internet connection in the target environment is the problem.

LAN Firewall

Scenario: The Local Area Network firewall is blocking the device’s traffic to the Internet. This is a common problem in corporate environments. It is rare in residential environments. Test: There is no easy way to test this scenario. The simplest method is to contact your IT department and ask them if they have any network security policies which might be interfering with your device’s Internet connection. ../../_images/ap.png

Test

  1. Contact your corporate IT department. Tell them that you are testing out an Internet-connected device which requires a direct UDP or TCP connection to the Internet. Ask them if they are enforcing any network security or firewall policies that restrict UDP or TCP traffic.

Web Application

Scenario: The device has actually connected to the Arrayent Cloud successfully, but the device is inaccessible from the web application. Test: Use the Arrayent Utility web application to monitor and control the device. Description: If you can monitor and control your device from the Arrayent Utility web application but not the web application then the problem has nothing to do with the device or your local environment. The web application is the problem. ../../_images/web-app.png

Test 1

  1. Open a web browser.
  2. Go to the Arrayent Utility web application.
  3. Log in as the Customer Account which owns the device.
  4. Use the Utility application to monitor and control the device.

See the Utility App Guide for more information on using the Arrayent Utility web application to monitor and control devices.

Device

There are two potential ways that the device can be the point of failure: Wi-Fi setup and ACA configuration.

Wi-Fi Configuration Errors

Scenario: An error occurs during the device’s Wi-Fi setup process. Analysis: Check the run-time return codes that the platform API generates and sends to the host application after it has unsuccessfully attempted to connect to the Wi-Fi Access Point.

Overview

The host application of the device is running on top of a software platform. This platform contains a high-level, abstract API for performing common Wi-Fi tasks, such as connecting to a Wi-Fi Access Point (AP) for the first time. ../../_images/wifi-workflow.png The host application calls the platform’s API to connect to the Wi-Fi AP. The platform draws on the networking resources of the device to actually communicate with the Wi-Fi Access Point. Note that the Wi-Fi setup procedure is completely external to Arrayent. The Arrayent Connect Agent is not involved in Wi-Fi setup. The host application, the platform API, and the Access Point are the only three components involved in Wi-Fi setup.

Analysis

Analyze the run-time return codes that the platform generates when attempting to connect to the Wi-Fi Access Point.

Invalid Arrayent Configuration

Scenario: The host application has configured the Arrayent Connect Agent (ACA) incorrectly. Analysis: Check the return codes that the ACA sent to the host application after failing to connect to the Arrayent Cloud. Check each of the configuration attributes for corruption or invalid information.

Overview

The host application configures the Arrayent Connect Agent with unique credentials and cloud environment information (e.g. DNS of the cloud, what TCP and UDP port to use, etc.). The ACA attempts to connect to the cloud using the configuration information provided by the host application. ../../_images/tx-workflow.png If the host application provides invalid credentials to the ACA, the ACA will not be able to successfully connect to the Arrayent Cloud. Note that unless the configuration data is extremely corrupted or invalid, the ACA will not return an error code to the host application. The ACA will just attempt to connect to the Arrayent Cloud using the invalid data.

Analysis

The host application configures the following fields of the ACA. All of these fields are members of the configuration struct arrayent_config_t. If any of these fields is corrupted or invalid, the ACA will not be able to log in to the Arrayent Cloud. Read back each of the fields at run time and check that each one is correct.

  • Device Name – the first part of Arrayent’s “serial number” for this device. Unique to this individual device.
  • Device Password – the second part of Arrayent’s “serial number” for this device. Unique to this individual device.

The combination of Device Name and Device Password is called a Device Code. If the Code does not match the Arrayent Cloud’s database record, the cloud will reject the device when it attempts to log in to the cloud. The cloud will also reject the device’s login request if the Device Code has not been registered in the cloud (this is internally implemented by Arrayent). You can check if a Device Code has been registered by attempting to add it to a Customer Account. If you can add the device to your account then the Device Code is already registered.

  • TCP Port – the TCP port which the ACA uses to connect to the Arrayent Cloud. Defaults to 80.
  • UDP Port – the UDP port which the ACA uses to connect to the Arrayent Cloud. Defaults to 80.

If the TCP or UDP ports that the ACA uses are blocked in your Local Area Network, the device will never be able to access the Internet. This is a common problem in corporate environments.

  • Domain Names – The DNS names of the Arrayent Cloud.

If the domain names to the cloud are wrong, the device will never be able to access the cloud. This is similar to entering a typo in a URL when trying to access a webpage (e..g. if you want to access www.google.com but instead type www.googl.co you will obviously fail).

  • Product ID
  • Device Key (AES) – One of two AES security keys which the device uses to secure communications between itself and the cloud.
  • Product Key (AES) – The second AES key.

Monitoring Connection Status

There is a special Device Attribute called “online” which may help in your troubleshooting.

The “online” attribute is set to “1” by the Arrayent Cloud whenever a device logs in to the cloud. When a device is inactive for three minutes the Arrayent Cloud sets the value of “online” to “0”. Web apps and host applications must never set the value of online. Only the Arrayent Cloud should set the value of online.

To use the “online” attribute, use the Arrayent Configurator web application to define the following Device Attribute in your device data model (“Device Type”).

../../_images/online-system-attribute-definition.png