Note: 2/22/2021

This blog has been updated to reference a new GitHub repo and the most recent SDK changes.  We also included details to use a predefined IoT Central Template for users that don't want to build a custom IoT Central application from scratch.

Note: 2/14/20

This blog has been updated for the recent SDK changes.  The sample project and these instructions have been updated to utilize the CMAKE build process and the repository has been updated to support connecting to the Azure IoT Hub/IoT Central using a Device Provisioning Service (DPS).

Note: 6/9/2020

The GitHub projects have been updated to support the VS Code development environment.  Note that when you first open the project in VS Code the CMake file generation will fail.  If you open the CMakeLists.txt file, add a space and save the file, then CMake will regenerate the build files and the process will succeed.  If anyone knows how to fix this issue, please add a comment and I'll get it corrected.

Introduction

Welcome to part 3 of the Avnet Azure Sphere Starter-Kit (Out of Box Demo).  In this follow-up blog, we'll walk through connecting the example Azure Sphere application to an IoT Central Application.

The Starter Kit is available for order here.

We've put together three different blogs to showcase the Avnet Azure Sphere Starter Kit and how it can be used for your next IoT project . . .

• Blog #1: Simple non-connected demo
  • Reads on-board sensors every 5 seconds
  • Reports sensor readings to the Visual Studio debug console
  • http://avnet.me/mt3620-kit-OOB-ref-design-blog
• Blog #2: Hands-on connected demo using a generic IoT Hub, DPS and Time Series Insights
  • Must complete blog 1 demo before moving on to blog 2
  • Configures IoT Hub, DPS and Time Series Insights Azure resources
  • Manipulate the device twin
  • Visualize data using Time Series Insights

• • http://avnet.me/mt3620-kit-OOB-ref-design-blog-p2

• Blog #3: Hands-on, connected demo using IoT Central (this blog)
  • Must complete blog 1 before moving on to part 3
  • Walks the user though configuring a IoT Central Application to create a custom visualization and device control application

• Advanced Blog: Hands-on, connected demo using IoT Central

• • Must complete blog 1 before moving on to the Advanced Blog
  • Adds OLED functionality to the Starter Kit
  • Walks through using a real-time Bare-Metal M4 application to read the on-board light sensor
  • Uses a IoT Central Template to quickly stand up a new IoT Central Application
  • http://avnet.me/azsphere-tutorial

Azure IoT Central

IoT Central is a Software-as-a-Service (SaaS) offering from Microsoft.  Microsoft has made it easy to connect IoT devices and display telemetry data from connected devices.  Additionally, there are cloud to device (C2D) controls available.  IoT Central Applications are created on-line without any coding necessary; configuration is all driven from the web interface.  This document will walk the user through each step required to create an IoT Central application that interacts with Avnet’s Azure Sphere Reference Design Project.

I’ll make the assumption that you’ve completed the simplified non-connected example.  If not, please go back and complete that examplehere. For the IoT Central lab the following prerequisites must be met.

• Visual Studio 2019 and the Azure Sphere SDK are installed and confirmed working
• You were able to run the non-connected example without any issues (link)
• Your device is connected to a Wi-Fi access point and has access to the internet

IoT Central Application Features

Our application will have the following features

• Display X, Y and Z axis g-force (gravitational force equivalent data label named GForce) measurements from the built in LSM6DSO accelerometer in a graph
• Display X, Y and Z axis angular rate measurements from the built in LSM6DSO gyroscope
• Display pressure reading from the built in LPS22HH device

• Display event data generated when user buttons A or B are pressed
• Allow the user to toggle the User RGB Red, Green, and Blue LEDs from the application
• Allow the user to toggle the WLAN and APP LEDs from the application
• Display the current firmware version running on the Starter Kit
• Display the current connected Starter Kit Wi-Fi SSID
• Display the Wi-Fi AP bssid
• Display the current Wi-Fi network and frequency
• Remotely exit the application using a direct method call

Build your own application or start with a pre-built template

There are two different paths to create your IoT Central application.  In both cases we'll learn how to configure IoT Central and our Azure Sphere application to connect to the IoT Central application.  These different paths can be identified by looking at the section titles.

• Use Template: Follow instructions under these section headers to use a pre-defined IoT Central application template

• Build from Scratch: Follow instructions under these section headers to build your own IoT Central application from scratch

• Both: Follow instructions under these section for either path, "Build from Scratch" or "Use Template"

Use a pre-built template application (Use Template)

IoT Central provides a feature called template export.  Basically an IoT Central application can be exported and users can use the template to deploy the exported application in their own Azure subscription.

This path will take less time, and will be less work.  To follow this path, make sure you work through all the sections with "Use Template" in the section title.  Sections common to both paths will contain "Both" in the section title.

Build the application from scratch (Build from Scratch)

We've included step by step details demonstrating how to create a new IoT Central application from scratch.  I recommend this path if you are interested in learning more details of creating a custom IoT Central application.  You'll learn how to define all the different interfaces that your IoT device can provide including telemetry, device twins (properties) and direct methods (commands).

This path will take more time, but you'll learn more about IoT Central and can apply what you learn to create custom IoT Central applications for any future IoT solution that you develop.  To follow this path, make sure you work through all the sections with "Build from Scratch" in the section title.  Sections common to both paths will contain "Both" in the section title.

Implementation Steps (Use Template)

To deploy a new IoT Central application using the application template the following implementation steps need to be executed . . .

• Create a custom IoT Central application
• Upload and verify the Azure Sphere Tenant CA certificate
• Update our application to connect to IoT Central

• Migrate our device to the device template

• Exercise the device

Create a IoT Central Application (Use Template)

The first step is to create the application.  The template that we'll use is here, click on the link to open the IoT Central application Template.  When you click on the link, a browser window will open similar the one shown below.

• Create a name for your application.  Note that this name must be unique across all of Azure since your application name will also be used for the application URL.  If you provide a name that’s already taken, you’ll get an error message stating the issue.

• Select the “Free” pricing plan for a free 7-day trial.  You can also select the Pay-As-You-Go option; you’ll need an Azure account with a balance or a pay-as-you-go account associated with a credit card if you choose this option.  When the 7-day trial expires, you'll have the opportunity to convert your application to a paid account.

• Click the “Create” Button

Your new application is provisioned and it opens up to the Dashboard screen.  At this point you can skip down to the section titled "Configure DPS for our Application (Both)"

Implementation Steps (Build from Scratch)

To build a custom application from scratch the following implementation steps need to be executed . . .

• Create a custom IoT Central application
• Create a device template
  • Create interfaces in the template
    • Sensor interface (telemetry)
    • Button interface (telemetry)
    • Wi-Fi information interface (device twin/properties)
    • LED interface (device twin/properties)
    • Command interface (direct methods/commands)
  • Create views to visualize our data
    • LED remote control view
    • Device data view
• Upload and verify the Azure Sphere Tenant CA certificate
• Update our application to connect to IoT Central
• Migrate our device to the device template
• Exercise the device

Create a IoT Central custom application (Build from Scratch)

The first step is to create the application.  Follow this link to create a new custom IoT Central Application. 

You should see a screen similar to the one shown below:

• Create a name for your application.  Note that this name must be unique across all of Azure since your application name will also be used for the URL.  If you provide a name that’s already taken, you’ll get an error message stating the issue.

• Select the “Custom Application” option.  The other option is "Custom Application (legacy)"  The new IoT Central is much different, these instructions will not correlate with the legacy implementation.
• Select the “Trial” option for a free 7-day trial.  You can also select the Pay-As-You-Go option; you’ll need an Azure account with a balance or a pay-as-you-go account associated with a credit card if you choose this option.  When the 7-day trial expires, you'll have the opportunity to convert your application to a paid account.

• Click the “Create” Button

Your application will be provisioned on Azure and you’ll be taken to the main page of your application. 

Here you’ll see the landing page.  The first thing we need to do is to create a “Device Template,” so click on the Device templates tile.

Create a device template (Build from Scratch)

A device template is where we’ll define all the information and interactions for our device.

• Select the "IoT device" tile
  • Note that all the current certified IoT Plug and Play devices are also available from this page.
• Click on the "Next: Customize" button at the bottom of the page

• Select "Next: Review"

• Click on the "Create" button to create and empty template

• Name your template.  I selected "Avnet Starter Kit OOB Template"

• Next you have the option of creating a custom template or importing a capability model (Optional)
  • If you like you can import my capability model by downloading the json file from here.
    • After you download the file, click on the "Import capability model" tile and select the file
    • I recommend you browse the rest of this section to understand how to add new data items to the application
    • You can skip to the section titled "Create Custom Views"

• Click on the "Custom" tile

• Next we'll create a custom interface
  • The interface is where we'll define all the telemetry data that our application is sending up
  • Best practice is to group like things into separate interfaces.  For example we'll create the following interfaces . . .
    • Sensors
    • Buttons
    • Wi-Fi information
    • Information
    • LEDs
    • Commands
• Click on the "+ Add interface" link

• Select the "Custom" tile

• Rename the interface by selecting "Edit identity"
• Type the new interface name into the "Display Name" field such as "S.K. Sensors"
• Click on the "Save" button

Next we'll add all the sensor capabilities for our application

• Click on the "+ Add capability" link to bring up the Capabilities interface

This is where we will define the sensor properties for this interface.  In this interface we can configure telemetry, device twins and remote method calls.  For the sensors we'll configure telemetry items.

For the first example we're going to add the X Axis g-Force telemetry item.  To do this we just need to fill out the form.

• Display Name: The name of the telemetry item to add, enter "Acceleration X Axis"
• Name: This is the “key” string of the {“key”: value} key pair telemetry data.  The sample Azure Sphere application uses “gX” for the X g-force component, so we enter “gX” in this field.
  • Note that the interface automatically transferred the "Display Name" string to this field for you.  You can change it if you need to.
  • Make sure you match the case of the "key"
• Telemetry | Command | Property: Select "Telemetry"
  • Telemetry is used for, you guessed it telemetry data from the device
  • Command is used for commands or direct methods to the device
  • Property is used for Device Twin Properties
• Semantic type: This is used to pre-select the data representation.  For example Acceleration, Pressure . . .
  • If you don't select a "Semantic" type you can enter custom units
  • Select "None"
• Schema: Select "Double"
• Units: Our data is in milli-g so ideally we would select “mg,” but this is not an option.  Select "None"

• Display Unit: Type in "mg"

• Comment: Add any comment you wish
• Description: Any description you wish

We just defined a Telemetry item!  Your screen should look similar to mine . . .

At this point we can click the "Save" icon to save our work.

• On your own, using the "+ Add capability" link add the following telemetry items

• Save your work by clicking on the "Save" link at the top of the form

I've rolled up all my Telemetry items, but your screen should look similar to the graphic below . . .

Add Button Interface (Build from Scratch)

• Add a new interface by clicking on the top level of the Template then "+ Add interface"

• Using the same steps we used for creating the "Sensors" interface above, create the "Buttons" interface
  • Rename the interface "Buttons"
  • Add the following capabilities

The example application will send up button press events as telemetry.  Using the information in the table below, populate your "Buttons" interface with the button press events.

You should have the hang of this task by now.  Use the tables below to build our the rest or our interfaces

Add Wi-Fi Information interface (Build from Scratch)

The example application will send up Wi-Fi information as properties (device twin reported properties).  Using the information in the table below, populate your "Wi-Fi Information" interface

Add Information interface (Build from Scratch)

The example application will send up the application version string as a property (device twin reported properties).  Using the information in the table below, populate your "Information" interface

Add LED interface (Build from Scratch)

The example application will operate using device twins to control the on-board LEDs.  Using the information in the table below, populate your "LEDs" interface

Add Commands interface (Build from Scratch)

The example application implements a direct method to stop the application from the cloud.  Using the information in the table below, populate your "Commands" interface

That's it for the interfaces.  If you just filled all that in, good for you!  I learn by doing, and entering in all this information is tedious, but it helps me remember how to do things.  Important review all your inputs carefully.  Once you "Publish" your interfaces it's difficult to change them.  We don't need to "Publish" the interfaces yet, but you may want to review all the information while it's all fresh in your mind.

Create custom views (Build from Scratch)

Views are collections of items from your template interfaces.  You can design views using your interfaces depending on what you want to present to the user.  For this example we'll create two simple views . . .

1. LED Remote Control

This view will contain controls that allow us to change the LEDs on the board.

2. Device Data

This view will graph the acceleration, angular rate and pressure data.  We'll also add some status data and a link to run the "Halt Application" direct method

LED Remote Control View

• You should still be on your device template screen, if not click on the "Device templates" link in the left most pane of the IoT Central Application
• Click on "Views"
• Click on the "Editing device and cloud data" tile

• The view form opens
• Change your form name to "LED Remote Control"
• Select "2 column layout"
• Expand the "Properties" item
  • Note that you see all the interface items of type "Property" (device twin)
• There are two ways to get items from the list into the view
  • Click the box next to each item you want to add and click the "Add section" button at the bottom of the interface (should that be "Add selection?")
  • Click and drag each item over with your mouse
• Update your view to look like mine, or do your own thing
• Click on the "Save" link at the top of the interface

Device Data View (Build from Scratch)

• Create a new view by selecting the "Visualizing the device" tile

• Build out the view to look like mine, or create your own
• Hints
  • Try selecting multiple telemetry items (check boxes), then the "Add tile" link
  • Try dragging single items from the list to the view (Pressure)
  • You can resize tiles from the menu on the tile, or by dragging the corners
  • You can change properties of each tile by clicking on the gear icon on the tile (tile title for example)

• One you're happy with your view, click on the "Save" link at the top of the interface

Publish your Device Template (Build from Scratch)

The interfaces and views that we created will not be available to devices until we "Publish" the changes.  Once you're happy with everything, I recommend one more review of your interface items, click on the "Publish" link in the top right corner of the interface.

Configure DPS for our Application (Both)

The next thing we need to do is to configure the IoT Central application so that devices from our Azure Sphere Tenant are allowed to connect to our application. IoT Central uses a Device Provisioning Service (DPS) to provision devices. Remember in blog #2 we had to prove to the DPS that we owned the Azure Sphere Tenant, we need to complete a similar exercise here for the IoT Central application.

Download the public tenant CA certificate (Both)

• Open the “Azure Sphere Developer Command Prompt” application
  • Start --> Azure Sphere --> Azure Sphere Developer Command Prompt
• Make sure you’re logged into your tenant:
  • Azure Sphere CLI V1 and V2
  • • azsphere login

Copy and paste in the command to download the Azure Sphere CA Tenant public certificate:

• CLI V1

• • azsphere ca download --output CAcertificate.cer
• CLI V2
  • azsphere ca-certificate download --destination-file CAcertificate.cer
• Note the output file must have the .cer extension

Upload the public tenant CA certificate to Azure IoT Central and generate a verification code (Both)

In your new IoT Central application

• Select the Administration --> Device connection
• Select the “+ Create enrollment group" link

• The "Create new enrollment group" dialog opens
  • Give your enrollment group a name, I recommend using the same name as your Azure Sphere Tenant
  • Select the "Certificates (X.509) Attestation type
  • Click on the "Save" link at the top of the dialog

• After clicking on the "Save" link the dialog will remain open, but there will be additional information at the bottom of the form
• Click on the "+ Manage primary" link to add our Azure Sphere Tenant CA public certificate
• Note the "+ Manage secondary" link.  In a real world deployment you would use this link to add a secondary certificate.  The Azure Sphere CA certificate has a lifetime of 2-years.  Towards the end of the 2-year period a new certificate is automatically generated by the Azure Sphere Security Service (AS3).  You can upload and verify the new/update certificate using the secondary link so that there is not a lapse in coverage when the primary certificate expires.

• The Primary Certificate dialog opens
• Click on the folder icon next to the Primary input box
• Browse your file system and select the CA certificate we download above
• The interface parses the certificate and displays the Subject and Thumbprint from the certificate
• Click the "Generate verification code" link to generate a verification code

Next we need to generate a validation certificate using the Azure Sphere CLI.  In this next step we're proving to the IoT Central application that we have access to the Azure Sphere Tenant and the private key.  This is accomplished by providing a IoT Central generated verification code to the Azure Sphere CLI.  Using the verification code AS3 will create a verification certificate that contains the verification code in the subject field.  The certificate is encrypted using the Azure Sphere Tenant Private key, and since we uploaded the Azure Sphere Public CA Certificate, the IoT Central application can decrypt the verification certificate and validate that the subject matches the verification code that it generated.  At that point the IoT Central application assumes that since we can generate an encrypted certificate that it can decrypt with the CA certificate that we have access or the authority to manage devices in the Azure Sphere Tenant.

Generate and download the verification certificate (Both)

• Copy and paste in the command below to generate and download the verification certificate, make sure to replace the <code> text with the verification code from your IoT Central application

  • CLI V1

    • azsphere ca download-proof --output validation.cer --verificationcode <code>

  • CLI V2

    • azsphere ca-certificate download-proof --destination-file validation.cer --verification-code <code>

• Note the output file must have the .cer extension

• Click on the "Verify" link
• Browse your file system and select the verification certificate we just downloaded

Your certificate is uploaded and a notification is displayed stating that the certificate has been “Verified.”

• Click on the "Save" link at the top of the form before exiting

That completes this task.  Now any devices from our tenant that try to connect to our IoT Central application with the proper DPS scope ID will automatically be provisioned to our application.

Configure our application to connect to the IoT Central Application (Both)

We're going to use a tool called "ShowIoTCentralConfig.exe" to pull all the bits we need to populate our app_manifest.json file.  This utility is included in the repo along with the Avnet example code.

Find all the required information for our Azure Sphere app_manifest.json file (Both)

• There are 4 pieces of information we need to provide for our application to connect to our IoT Central application
  • DPS Scope ID (This is case sensitive)
  • DPS Global Endpoint FQDN (This is case sensitive!)
  • IoT Hub FQDN(s) (These are case sensitive)
  • Azure Sphere Tenant GUID (This is case sensitive, must be all lower case!)
• We can find three of the four easily, however the IoT Hub FQDNs are buried deep in the IoT Central implementation.  Remember that for our Azure Sphere application to be able to talk to any external server, we need to provide the FQDN or IP address in the app_manifest.json file. 
  
• Open a command line window, or use the Azure Sphere Command Prompt CLI
• Change directories to your repo\Samples\AvnetAzureSphereHacksterTTC\HighLevelExampleApp\Tools\win-x64Tools directory
• Run the "ShowIoTCentralConfig.exe" utility
  • This utility must be run from a command line.  If you run it from the file explorer, a window will open and prompt the user for information.  The application will output the data we need, then exit before you can see it.
  • When asked if you’re using a legacy (2018) IoT Central application (Y/N): Answer N
  • Next you’ll be prompted for the URL for your IoT Central application. Copy the URL from your browser window and paste it into the command prompt window. You only need the URL up to and including the *azureiotcentral.com
  • Next you’ll be asked for an Azure IoT Central application API Token
    • Go back to your IoT Central Application
    • Select Administration --> API tokens --> “+ Generate token”

• • Next we need to find the ID Scope and provide that detail to the utility
    • The ID Scope is for the Device Provisioning Service that’s deployed for your IoT Central application
    • Back in your IoT Central Application select Administration --> Device Connection
    • Copy the ID scope using the copy button
    • Paste the ID scope into the command prompt window

• • The utility will generate entries for your Azure Sphere applications app_manifest.json file. See the graphic below for the items we need to copy into our app_manifest.json file.

The graphic below shows my ShowIoTCentralConfig.exe execution

• After supplying the requested information, the utility responds with the details I need for my app_manifest.json file

Modify the Azure Sphere source code (Both)

Now let’s go back to Visual Studio.  If it’s not open, go ahead and launch the Visual Studio application and open the \Samples\AvnetAzureSphereHacksterTTC\HighLevelExampleApp project.  Visual Studio keeps a list of recent projects, your project should be found in that list.

Updating the app_manifest.json file (Both)

Open the app_manifest.json file for this application. There are four items we need to include in order for our application to use DPS and connect to our IoT Central Application:

• DPS Scope ID: See the output from the the "ShowIoTCentralConfig.exe" execution
• AllowedConnections (11):
  • The DPS global device endpoint FQDN: See the output from the the "ShowIoTCentralConfig.exe" execution
  • The IoT Hub’s FQDNs: See the output from the the "ShowIoTCentralConfig.exe" execution
• DeviceAuthentication:
  • This is the GUID for your Azure Sphere Tenant. This is included so that this application will only work on devices claimed to our Azure Sphere Tenant. So if someone was able to get our application and side load it onto an Azure Sphere device, that device would not be able to connect to our Azure services, unless that device is in the same Azure Sphere Tenant.
  • From your "Azure Sphere Command Prompt Preview" CLI execute the command >azsphere tenant show-selected

My updated app_manifest.json file.

Update the CMakeLists.txt file to define which Avnet Azure Sphere Kit you are using Rev1 or Rev1 (Both)

• Open the CMakeLists.txt file in the project
• Determine which Starter Kit revision you have Rev1 or Rev2.  This can be determined by looking at the silk screen text under the Avnet Azure Sphere certified module
• Find the azsphere_target_hardware_definitions lines.  Make sure you uncomment the line that describes which kit you have
  • In the example below I 'm using a Rev1 kit
• If you get this wrong, the wifiLED device twin control will not work correctly since the GPIO driving the LED is different between the two kits

Update the build options (Both)

Remember in the simple non-connected application we discussed the two different build configurations:

1. No cloud connectivity.  This is the simplest configuration.  The application runs and you can monitor sensor data from the Visual Studio debug window.
2. IoT Hub connectivity.  This configuration requires an Azure IoT Hub and DPS or an IoT Central application 

For this example we’ll enable the IoT Hub Connectivity configuration.

• Open the build_options.h file
• On about line #6 remove the “//” comment characters to enable the #define IOT_HUB_APPLICATION configuration.
• On about line 17,  remove the "//" comment character to enable the #define USE_PNP configuration.
• Save your work by typing (Ctrl+S).

To review.  The modifications we made to the source code . . .

• We enabled the IOT_HUB_APPLICATION define in build_options.h
• We enabled the USE_PNP define in build_options.h
• We updated the CMakeLists.txt file to specify which Avnet Starter Kit we're using

• We added our DPS Scope ID to the "CmdArgs" line in the app_manifest.json file
• We added our Global device endpoint string to the “AllowedConnection” entry in the app_manifest.json file
• We added our hostname strings to the “AllowedConnection” entry in the app_manifest.json file
• We added our Azure Sphere Tenant GUID to the "DeviceAuthentication" entry in the app_manifest.jston file

We should be ready to build the IoT Hub configuration!

Build and run the application (Both)

To compile, link and load the application onto your Starter Kit, you just need to click on the “Remote GDB Debugger” button in the toolbar.  You’ll see the build process run and a popup box stating that Visual Studio is starting the application.

• Make sure your device is connected to your PC
• Ensure your device has a Wi-Fi connection
  • azsphere device wifi show-status
• To compile, link and load the application onto your Starter Kit, you just need to click on the “Remote GDB Debugger” button in the toolbar.
  • If you're asked to save the changes click "OK."

If you look at the output window, you should see something similar to the text below.

Let's review this output . . .

AZURE_SPHERE_PROV_RESULT_OK

This output confirms that the DPS successfully provisioned our device into the IoT Central application (IoT Hub in the background)

Updating device twin

This output is showing that the application is sending device twin updates.  You can see in the output that these updates are sent as JSON {key: value} pairs.

IOTHUB_CLIENT_CONNECTION_OK

This output shows that our device has connected to our IoT Central Application (IoT Hub).  If you don't see your device connect to the IoT Hub, please review the Troubleshooting Azure IoT Hub Connection Issues blog entry.

Sending telemetry

This output shows the telemetry data we’re sending to Azure.  As with the device twin update message, we’re sending JSON key: value pairs. To send telemetry, you just need a valid JSON structure.  The IoT Hub will collect this data and simply pass it on to any services that subscribe to the IoT Hub. 

Did you know?

Click Boards There are over 1000 different Click Boards available that can be used on the Avnet Starter Kit Use the parametric search tool at https://www.mikroe.com/click to find the board to satisfy your hardware requirements. Pmod Boards Digilent, TI, MAXIM and others provide Pmod peripheral boards that can be used on the Avnet Starter Kit https://store.digilentinc.com/by-function Grove Boards Over 100 low-cost Grove boards available at https://www.seeedstudio.com/groves-us

IoT Central (Both)

Now that our application is running on the Avnet Starter Kit, let's open our IoT Central application.  The first thing we need to do is to find our device and associate it with our device group / template

• Navigate to your IoT Central web site
• Click on "Devices"
• Click on "All Devices"
• Select your device; your device is the one with the long ugly device name/ID.
  • Click on the selection box
  • Click on the Migrate link
    • If you don't see the Migrate link, click on the ellipses
  • Select your device group

Now you can open your device, see the data your board is sending and exercise the LEDs using your new LED Remote Control view.

Review

That concludes the exercise, what did we learn?

• How to create a IoT Central application from scratch OR How to create an IoT Central application from a Template (maybe both!)
• How to configure our application to connect to the IoT Connect
• How IoT Central uses JSON objects for device twin data
• How to use IoT Central to view telemetry data
• How to use IoT Central to change device settings

Avnet Azure Sphere Starter Kit

The Avnet Azure Sphere Starter can help you jump start your next IoT Project.  Azure Sphere is the easy button for IoT Security, and the Avnet Starter Kit makes it simple to connect hundreds of different sensors and I/O devices for your prototyping needs.  Prototype on your Starter Kit, then migrate your project to the Certified Azure Sphere Module in your final design.

Order your Starter Kit today: Link

Additional Azure Sphere Resources

• Free Azure Sphere training from Microsoft: http://avnet.me/azureSphereMSFTLearningPath
• Listing of all the Avnet Azure Sphere Blogs on Element14 plus other resources: http://avnet.me/azure-sphere-resources