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¶
- Create an inverter product in the cloud (under the customer’s OU, instead of the developer’s OU). 
- The acquisition rod developer creates an acquisition rod app under the developer’s OU and obtains the service account (SA) of the application: the - accessKeyand- accessSecret.
- 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 - productKeyof the inverter.
- The - orgIdof the organization that the- productKeybelongs to.
 
- 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- deviceSecretto 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.
