Not many times people consider the mobile service provider for their IoT data needs because they can change the plan anytime. But does it really matter? Well, it does.
This is the second last post of the [series on IoT Communication](/blog/communication-for-iot-or-embedded-applications) which has gone on for slightly more than a month now. In this post, I endeavor to connect an IoT device to the Azure IoT Hub without using the provided IoT libraries.
Today's post is rather short as the end to the series on IoT communication nears.
As per the previous blog post, a TLS connection was established. A few issues like client-side certificate verification were solved. In this post, all I sort to show was doing the MQTT communication on a secure port.
In the previous post (post #6), we got mbedTLS working and it delivered content to us from a server using SSL/TLS. However, in the code, you should have noticed a line saying that in real life we should bail out when the certificate verification fails
In the previous post (post #5), we added mbedTLS to the project and agreed that we would follow the sample that comes with the mbedTLS pack. If you followed everything correctly you should see an output such as the one below. There are several additional steps but I discuss them below the dump.
This post will also be very short (or so I hope).
Setting up MQTT in your Keil MDK project is very easy especially for the Eclipse Paho client for C. I did this in one git commit. You will notice that of the three flavors available, I chose the MQTTPacket because it is lightweight. The other flavors required some more work. Setting the timing parts for the MQTTClient, required understanding the library perfectly to work it out. One requires the timing to work if you need to subscribe to a topic or if you need the broker to confirm delivery (QoS 2 or QoS 1). For the basic proof of concept, QoS 1 works fine. It means I need no response from the broker.
This is going to be a rather short post because it has been covered by other people elsewhere. I will concentrate on which protocol works best for the IoT tutorial we are on. This is the third post of the tutorial.
At the tail end of this post, there are additional resources for further reading.
There are a number of protocols out there and sometimes we get confused by the marketing around some of them. That is evident in the picture below.
There is really a lot of talk about IoT and how many billion dollars it will be worth in the future. However, unless we solve actual problems that we face, that might be a dream that will only connect a bunch of toys to the internet without much of information for our use. One of those problems is connectivity.
Most examples available online from hardware manufacturers, for development kits, and from cloud service providers will only describe the connection to the internet via ethernet. If they do not show ethernet, the application is most likely a Bluetooth Smart client app that does not connect directly to the internet but via a host like a mobile phone. Using a mobile phone is not always the best option unless it is a wearable. There are many of those nowadays. You also cannot use ethernet everywhere you want. Your piece of hardware is grounded.