Scenario 1.3: Non-smart device + smart data acquisition device = smart device, direct connection


For this scenario, let us take the household photovoltaic inverter as an example.


Household photovoltaic inverters do not support the burning of firmware. In this case, an acquisition rod is needed to collect and forward data to the cloud. Because the acquisition rod collects only the data of one inverter, we can consider the inverter and the acquisition rod as one smart device; and since the acquisition rod supports the burning of firmware, the inverter and the acquisition rod as a whole can be regarded as a smart device that supports the burning of firmware.

Procedure

  1. Create an inverter product in the cloud (under the customer’s OU, instead of the developer’s OU).
  2. The acquisition rod developer creates an acquisition rod app under the developer’s OU and obtains the service account (SA) of the application: the accessKey and accessSecret.
  3. The acquisition rod developer configures the manufacturer settings of the rod and burns the following information into the rod:
    • The SA of the acquisition rod app.
    • The productKey of the inverter.
    • The orgId of the organization that the productKey belongs to.
  4. The IoT engineer performs on-site construction and installation, installing the acquisition rod for the inverter, powering on the device, and connecting it to the network. Once the device is connected, the following will occur:
    • The acquisition rod collects the serial number of the inverter, and uses it as the deviceKey. It then calls the REST API using the SA, dynamically creates the device using the productKey, deviceKey (serial number), and orgId, and obtains the device’s deviceSecret.
    • The acquisition rod records the deviceSecret, which will be automatically burned into the firmware of the device.
    • The acquisition rod collects data from the inverter, and uses the productKey, deviceKey, and deviceSecret to connect to the cloud. Once authenticated, the device goes online and starts to send telemetry.


The following figure illustrates the message flow of connection scenario 1.3.

../../_images/connection_scenario_1.3.png