This topic describes how to troubleshoot and resolve issues where a sub-device fails to be connected to a gateway or IoT Platform. In this example, a Link IoT Edge Pro Edition edge instance or a Link IoT Edge Standard Edition edge instance is used.

Devices that are connected to a gateway are called sub-devices. If a sub-device is in the inactive, offline, or disabled state, perform the following steps to troubleshoot and resolve the issue:

Step 1: Make sure that you use the commands generated in the IoT Platform console to install and start Link IoT Edge

The commands generated by the IoT Platform console free you from manual installation operations, thereby eliminating errors caused by manual operations.

For more information, see Install and start Link IoT Edge in Build an environment.

Step 2: Make sure that all services are in the Active state

Run the following command in a shell multiple times to check whether all services are in the active state:

Note
  • If you use a Pro Edition edge instance, go to the directory where your container is installed and run the following command.
  • If you use a Standard Edition edge instance, run the following command in the shell: 
/linkedge/gateway/build/script/iot_gateway_status.sh
  • If all services are in the active state, the following output is displayed. Sample code
  • If some services are in the inactive state, run the following command as the root user to restart the Link IoT Edge instance: 
    sudo /linkedge/gateway/build/script/iot_gateway_start.sh

    Run the /linkedge/gateway/build/script/iot_gateway_status.sh command to check whether all services are in the active state. If a service remains in the inactive state, perform the following steps to restart the service:

    1. View logs in the userlog directory and logs of the service.
      • The path of the userlog directory is /linkedge/run/logger/userlog.
      • Logs of the service are stored in /linkedge/run/logger/<service_name>, where <service_name> indicates the name of the service.
    2. Start the service and view logs of the service.
If the logger service fails to start, run the ifconfig command to check whether the loopback interface is in the up state. 
ifconfig lo
If the loopback interface is not in the up state, run the following command to change its status to up: 
sudo ifconfig lo up

If the issue persists after you complete the preceding operations, identify the cause based on the logs of the service.

Step 3: Make sure that the gateway is online

Log on to the IoT Platform console and check whether the gateway is online. If the gateway is offline, run the following command to identify the cause: 

cd /linkedge/gateway/build/bin/ && ./lectl diagnose

In normal cases, OK is displayed next to each operation in the command output, as shown in the following figure.

Normal gateway

If the gateway is offline, the following causes may exist:

  • The certificate of the gateway device failed to be obtained.

    Solution: Run the cd /linkedge/gateway/build/bin/ && ./lectl config set -g $your_productkey $your_devicename $your_devicesecret command to import the certificate of the gateway device.

  • The network is abnormal.

    Solution: Stop the firewall from blocking the connection and disable the HTTP proxy and iptables on the gateway device.

  • The certificate of the gateway device is invalid.

    Solution: Run the ./lectl config set -g command to import a valid certificate for the gateway device.

Step 4: Make sure that the driver runs as expected after the edge instance is deployed

Run the following command multiple times to view the driver status: 
cd /linkedge/gateway/build/bin && ./lectl fc show

The following output indicates that the driver runs as expected.

Code snippets

In the output, FunctionName indicates the driver name and StartTime indicates the time when the driver started.

  • If the value of StartTime in the output keeps changing, the driver keeps exiting and starting. In this case, identify the cause based on the logs of the driver.
  • If the value of the State parameter in the output is not Success, make sure that the following requirements are met:
    • The driver is packed into a .zip file.
      Note The binary or index file of the driver resides in the top-level directory of the .zip package.
    • The main file of the driver is executable if the driver is programmed in C.
    • The unzip tool is installed in the runtime environment of Link IoT Edge.

Step 5: Make sure that the driver can communicate with the sub-device as expected

View logs about communication between the driver and sub-device.

If the gateway is offline, the following causes may exist:

  • The driver assigned to the edge instance for managing the sub-device is incorrectly configured in the IoT Platform console.

    Solution: Log on to the IoT Platform console, go to the Instance Details page, and then click the Devices & Drivers tab. Modify the driver configuration, and then redeploy the edge instance.

  • The communication link between the driver and the sub-device is abnormal.

    Solution: Check the physical connection and cancel network blocking on the firewall.

Step 6: Make sure that you specify invalid certificate information when you register each sub-device

Run the following command to obtain the certificate information, including the ProductKeys and DeviceNames, about all sub-devices in your Alibaba Cloud account: 
cd /linkedge/gateway/build/bin && ./lectl config get -d
The following output is displayed. Sample code

In the output, if the value of the State parameter is Used, the certificate of the sub-device was used for registration. If the value of the State parameter is Unused, the certificate was not used for registration. Check the certificate of the sub-device whose value of State is Unused and make sure that the sub-device uses the correct certificate.

Appendix

  • Log file directories
    Log files of each module of Link IoT Edge are stored in /linkedge/run/logger, as shown in the following figure. Sample code
    Note
    • Log files of each driver are stored in a separate directory named after the driver name in the fc-base/ directory. For example, log files of the Light driver are stored in the fc-base/Light directory.
    • Error log files in the userlog directory record errors, such as operation process errors and configuration errors. In most cases, these errors cannot be automatically fixed.
  • Log files in the userlog directory
    • Logs of the device info manager unit (dimu) module 
      [CloudOffline][Succeeded]: Device cloud ID: [%s]
A sub-device was disconnected from IoT Platform. The cloud ID of a sub-device is in the productkey_devicenname format.

[CloudOffline][Failed]: Device cloud ID: [%s]
A sub-device failed to be disconnected from IoT Platform.

[LocalOffline][Failed]: Device local ID: [], Cloud ID is illegal: %s
A sub-device failed to be disconnected from a gateway because the cloud ID was invalid.

[LocalOffline][Failed]: Device local ID: [], can not find specified Cloud ID: %s
A sub-device failed to be disconnected from a gateway because no cloud ID was specified.

[LocalOffline][Succeeded]: Device cloud ID: [%s]
A sub-device was disconnected from a gateway.

[Authorization][Failed]: Unable to authorize device %s with Product Key %s : error code: %d.
A sub-device failed to be registered. %d specifies the error code.

[LocalOnline][Succeeded]: Device cloud ID: [%s]
A sub-device was connected to the gateway.

[CloudOnline][Failed]: Device cloud ID: [%s], is a local device
A sub-device failed to be connected to IoT Platform because the sub-device was not connected to a gateway.

[CloudOnline][Succeeded]: Device cloud ID: [%s]
A sub-device was connected to IoT Platform.

[CloudOnline][Failed]: Device cloud ID: [%s]
A sub-device failed to be connected to IoT Platform.
    • Logs of the cloud-proxy module 
      [gateway_connect_cloud]gateway online! productkey=%s, devicename=%s
A gateway went online.

[gateway_connect_cloud]gateway offline! productkey=%s, devicename=%s
A gateway went offline because the network connection was closed.