Posting a Message to Azure IoT Hub
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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:
- Create an account at https://azure.microsoft.com/
- Follow the instructions here (or below) to set up an IoT Hub in your account
- Log in to portal.azure.com
- On the left sidebar, select New -> Internet of Things -> IoT Hub
- Fill in the form and submit to create the IoT Hub. Deployment of the IoT Hub will take a few minutes.
- On your console dashboard, open the IoT Hub that was just created.
- Click on the key icon to open Shared Access Policies. Open the iothubowner policy and copy the connection string.
- 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- Open Device Explorer and paste the connection string into the IoT Hub Connection String field and press update.
- 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.
- Use the Device Explorer or WICED functions to generate a SAS token.
Using Device Explorer Using WICED functions - Select the SAS Token action
- Select the desired device and enter a TTL value.
- 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)
Configuring WICED app:
- Download the attached .zip file and extract into apps/snip.
- Modify wifi_config_dct.h with credentials for your WiFi AP.
- 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> - 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
Changetls_version_num_t tls_maximum_version = TLS1_2;
tls_version_num_t tls_maximum_version = TLS1_1;
- Compile and run the app with the target "snip.azure_https_client-<platform> download run"
- 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
Device Messaging REST API documentation can be found here: Device Messaging REST APIs
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Good post. Thanks for the update.
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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( ).
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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.
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.
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Hi
Good procedure
Have you the same procedure for the demo in SDK 5.1 ?
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
good video to understand AMQP
https://www.youtube.com/watch?v=ODpeIdUdClc&list=PLmE4bZU0qx-wAP02i0I7PJWvDWoCytEjD&index=1
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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