Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob

Posting a Message to Azure IoT Hub

lock attach
Attachments are accessible only for community members.

Posting a Message to Azure IoT Hub

AndrewY_86
Employee
Employee
25 sign-ins 25 replies posted 10 replies posted

This application will demonstrate how to sent a device-to-cloud message from a WICED device to the Azure IoT Hub over HTTP.

 

Before running the app, you will need to have an Azure IoT Hub set up, and a device provisioned in the account.

Configuring Azure:

  1. Create an account at https://azure.microsoft.com/
  2. 1.PNG
  3. Follow the instructions here​​ (or below) to set up an IoT Hub in your account
    1. Log in to portal.azure.com
    2. On the left sidebar, select New -> Internet of Things -> IoT Hub
    3. Fill in the form and submit to create the IoT Hub. Deployment of the IoT Hub will take a few minutes.
    4. On your console dashboard, open the IoT Hub that was just created.
    5. Click on the key icon to open Shared Access Policies. Open the iothubowner policy and copy the connection string.
  4. 2.1.PNG
    3.PNG
  5. Use the Device Explorer GUI (Windows only) to provision a device. Instructions; Download (scroll down to downloads)
    or
    Use the iothub-explorer command line utility (cross platform) to provision a device.​ Instructions
    1. Open Device Explorer and paste the connection string into the IoT Hub Connection String field and press update.
    2. Open the Management tab and create a device. Use your own device ID take note or the device ID if the Auto Generate ID option is selected.
  6. Use the Device Explorer or WICED functions to generate a SAS token.
    Using Device Explorer Using WICED functions
    1. Select the SAS Token action
    2. Select the desired device and enter a TTL value.
    3. Generate the token

    Psuedocode to generate SAS:

    stringtosign = resourceURI + '\n' + expiryTimeInUTCsecs

    signedstring = base64(hmacsha265(stringtosign,secretkey))

     

    snprintf(SAS,length, "SharedAccessSignature sr=%s&sig=%s&se=",URIencode(resourceURI),URIencode(signedstring),expiryTimeInUTCsec)

  7. 4.PNG5.PNG6.PNG

 

Configuring WICED app:

  1. Download the attached .zip file and extract into apps/snip.
  2. Modify wifi_config_dct.h with credentials for your WiFi AP.
  3. Modify the HUBNAME, DEVICENAME, and SASTOKEN fields with credentials from your Azure IoT Hub.
    The SAS token has the format: SharedAccessSignature sr=<devicehubname>.azure-devices.net%2fdevices%2f<deviceid>&sig=<signature>&se=<expiry>
  4. As of SDK 3.7.0, TLS v1.1 is needed to connect to IIS servers. This workaround is temporary and should be patched in the next SDK release.

    Open the file <WICEDSDK>/WICED/security/BESL/host/WICED/tls_cipher_suites.c
    Change

    tls_version_num_t tls_maximum_version = TLS1_2;

    To

    tls_version_num_t tls_maximum_version = TLS1_1;

  5. Compile and run the app with the target "snip.azure_https_client-<platform> download run"
  6. Open Device Explorer to the "Data" tab and start monitoring for data
    or
    follow the instructions​ for iothub-explorer to monitor device-to-cloud messages
  7. 7.PNG8.1.PNG


Device Messaging REST API documentation can be found here: Device Messaging REST APIs

Attachments
1634 Views
Comments
AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

Hi aky​,

The documentation is good.

However, I have one suggestion:

Even though you can fix the issue to use TLS v1.1 to connect IIS servers.

Is it possible to support run-time select which TLS version to use rather

than compile-time determinated.

i.e. The application can use TLSv1.1 to server1 and/or use TLSv1.2 to server2.

VikramR_26
Employee
Employee
25 sign-ins 10 sign-ins 10 comments on KBA

axel.lin​ As mentioned earlier this is a temporary fix, the actual fix will be provided in next release, you can test it then.

The fix will be in BESL libraries.

AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

vik86 wrote:

axel.lin As mentioned earlier this is a temporary fix, the actual fix will be provided in next release, you can test it then.

The fix will be in BESL libraries.

OK, since the fix  is  in binary library.

BTW, you seems misunderstand my suggestion about TLSv1.1 and TLSv1.2.

Currently, the application cannot run-time select to use TLSv1.1. or TLSv1.2 to connect server.

It would be nice to support that.

DarrinV_91
Employee
Employee

Good post. Thanks for the update.

DarrinV_91
Employee
Employee

FYI, for anyone trying this, there are two instances of tls_maximum_version in tls_cipher_suites.c.  If you don't change them both, the code will crash with an exception when calling http_client_connect( ).

TLS.JPG

AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

dtv wrote:

FYI, for anyone trying this, there are two instances of tls_maximum_version in tls_cipher_suites.c.  If you don't change them both, the code will crash with an exception when calling http_client_connect( ).

No, your comment is pointless.

These two tls_maximum_version are guarded by #ifdef USE_SSL3.

Only one of them will be compiled depends on if USE_SSL3 is defined or not.

If you really hit "crash with an exception", it's caused by other issues.

MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

We should be able to release 3.7.0-5 shortly.  I believe this is the release with FreeRTOS/LwIP support that also fixes all known memory leaks. I saw some email traffic on the topic this morning, so I am waiting for a date.

vik86rashgangironwong

AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

mifo wrote:

We should be able to release 3.7.0-5 shortly.  I believe this is the release with FreeRTOS/LwIP support that also fixes all known memory leaks. I saw some email traffic on the topic this morning, so I am waiting for a date.

vikr rash grga rowo

mifo

I think there are some gap between the communication.

We have well tested our firmware base on sdk-3.1.2, we need the library fixes for 3.1.2.

The TLS memory leak in 3.7.0 serial is a good example that new code may introduce critical bugs.

We cannot use latest sdk in my product because it has too many unexpectable bugs, it's too risky.

In additional, the problem of the TLS library is your team breaks the compatibility of binary library between SDKs.

So I cannot copy the TLS library directly from 3.7.0-7 to 3.1.2 due to your internal API changes between SDKs.

In such situation, I have no choice but asking your team to deliver the TLS library fixes for 3.1.2.

Anyone using WICED SDK to make product will hit the same issue: the SDK they currently use will become an

older SDK someday and they still your support for the binary libries bug fixes.

You cannot asking users to always upgrade to latest sdk, that won't work.

I'm disappointed that we still don't get any update after waiting for more than 3 months.

rashgrgarowo

Anonymous
Not applicable

Hi

Good procedure

Have you the same procedure for the demo in SDK 5.1 ?

Anonymous
Not applicable
Anonymous
Not applicable

Hi,

Excellent Information!! I am working on posting the data to azure IOT hub. I was able to connect to azure IOT but I am not receiving any response from the hub. I have followed setup described. Can anyone tell me what exactly is the issue I am facing.

Thank You,

Srikanth