Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
IoT Messaging
11 Plays1 year ago
This episode is part of my series on developing IoT Solutions using .NET. You can follow along at the Basement Programmer Blog here: https://basementprogrammer.com/series/iot-dot-net
Recommended
Transcript
Introduction & Host Disclaimer
00:00:00
Speaker
Hello, Basement Programmers, and welcome to the February 2023 episode of the Basement Programmer Podcast. As always, I'm your host, Tom Moore, and I'm a developer advocate working for Amazon Web Services. The opinions expressed in this broadcast are my own and should not be assumed to be the opinions of my employer or any other organizations that I may be associated with.
00:00:21
Speaker
basementprogrammer.com is not associated with Amazon in any way.
Media Series on .NET and IoT Solutions
00:00:25
Speaker
If you've been watching my blog or my YouTube channel, you'll know that I'm currently working on a media series that I call IOT for the .NET developer. In this series, I'm looking at how you can build out an IOT solution that connects to AWS's IOT core platform using .NET. Now, why on earth would you want to do this, right? Well, modern .NET is designed to be cross-platform. This means that we're no longer bound to the Windows operating system.
00:00:51
Speaker
IoT boards typically run micro Linux installs on ARM based hardware. This allows them to be very power efficient and run low powered CPUs. Our .NET code can now run on these devices. This means that if you're like me, you can use your favorite programming language, C sharp in my case, and build out these IoT solutions.
00:01:12
Speaker
What's even better is that .NET 7 brought us native ahead of time compilation.
Evolution of IoT and Device Capabilities
00:01:18
Speaker
This means that we can now build native Linux binaries. With native AOT, the target system doesn't have to have the .NET framework installed on it. There's no JIT compilation.
00:01:29
Speaker
when the application first runs and our executables can be a lot smaller. Now, I do have to mention here, native AOT is in a first release state at the moment. There are a lot of things you have to be aware of. Some of your libraries may not be fully compatible with native AOT. Now, this could run into issues like data loss or runtime errors, so you must be very careful with your testing. That said, native AOT is only going to get better.
00:01:59
Speaker
Now, let's talk a little bit about what this thing called Internet of Things is. Back in 2001, I kind of almost stumbled into the area of mobile software development space. When I moved to Australia, back then the market was dominated by Symbian and Palm Pilots.
00:02:18
Speaker
Now, I worked for a company back then called Yambang, and they were really groundbreaking in the technology stack that they were developing. They were doing protocol conversion between various networks and providing in-field applications on these Palm Pilots. Fast forward 20 odd years, and the landscape has completely changed. We've seen a rise and fall of the Windows Phone OS, and these days, iOS and Android are pretty much the only players in the smartphone market, or only major players anyway.
00:02:47
Speaker
Smartphones are great. I can't function without mine. My entire life is in my calendar. But they are completely focused on the user experience. What they are not good at is the idea of long term, low power use devices.
AWS IoT Tools Overview
00:03:01
Speaker
Now since the turn of the millennium, there had been this concept of the Internet of Things. There were some research projects going on. But about 10 or so years ago, we started hearing about this idea of Internet of Things in conjunction with mobile technology. Instead of your thing being a vending machine that was plugged into a wall, it could now be something the size of a deck of playing carts, for example, run on a button battery. These opened up to floodgates for different use cases.
00:03:31
Speaker
However, these devices were generally small, they typically run ARM based hardware, as I've mentioned, and are often running some form of embedded Linux distribution. The aim of this new generation of devices was to have really long battery life, or maybe battery with solar recharging. The industry was crying out for devices that could be installed, potentially in remote locations, and then left for long periods of time.
00:03:58
Speaker
This is great, but it really left us .NET developers behind as there was no option to develop solutions in .NET. We were tied to the Windows operating system back then. As I said earlier, this has all changed. We are now able to develop and build applications that target these systems using .NET and build high performance, low resource applications.
Importance of Messaging in IoT Solutions
00:04:22
Speaker
And AWS provides us with a whole suite of IoT services that were designed to help developers to build out the backend infrastructure of IoT-based solutions. Now, I've been at AWS since about 2016. Back then, there was only one service. It was called IoT. Since that time, the IoT product teams have really expanded offerings that are available to IoT developers and users.
00:04:52
Speaker
The core platform, there are services around management and security, there are services for analytics, there's a rules engine for processing messages, and of course you can connect IoT services to AWS Lambda, which means that you have access to the entire AWS platform.
00:05:11
Speaker
Over the years, I've spoken with customers about a range of IoT-related use cases. These are things like monitoring the temperature and location of shipping containers, monitoring water flow and checking the status of valves. These are just some of the options. These applications are at one end of the spectrum where you might have had thousands of devices that are reporting big data back to the solution.
00:05:36
Speaker
Now, on the other hand, on the other side of the equation, you might have internet-connected vending machines send back stock levels. One thing that is core to all of these IoT-based solutions is messaging. And that's what we're going to talk about for the remainder of this podcast. Messaging, or sending of data really, is what transforms a device into an IoT thing. With that data being transferred, we can do something really amazing things.
00:06:07
Speaker
Now let's say we're shipping perishable food from one location to another. I'm going to load all that food into a refrigerator shipping container. Load that container onto a truck or a ship and send it off. There is a huge risk here of spoilage when it comes down to maintaining the environmental conditions of the container within acceptable ranges.
00:06:28
Speaker
We don't want the inside of the containers to get too hot or the food will spoil. Too cold, it might freeze. We don't want things to get too dry and things will weld. Or, you know, too wet and we encourage mold growth. Spoilage causes a very real problem today. The problem is there's no convenient way to monitor and potentially correct the environmental factors in the shipping container.
AWS Device Shadow and MQTT
00:06:51
Speaker
But this is where IoT has the ability to really help out here. Let's think about a first application. Maybe we just start with monitoring the conditions in a container. So we have a small compute device mounted on the container. We have two sensors that are attached to that device. And they're able to read, say, the temperature and the humidity within the container and send back data to our application.
00:07:17
Speaker
Right away we are able to get some near real-time data about the conditions in that truck. This allows us to do two things. First, we can see if the conditions in the shipment are approaching the range that would result in spoilage, and we can make decisions before that happens. If the conditions indicate that the food is approaching one of these dangerous situations,
00:07:40
Speaker
We can stop the truck. Perhaps we can manually take some corrective action or maybe we reroute a delivery to some other location before the spoilage occurs and save the food. Second, we can use the streaming data to try to figure out what is causing the issue and make higher level decisions to correct things in the future.
00:08:01
Speaker
So, maybe we combine the readings with some GPS data and determine a new route. Maybe we adjust the temperature slightly when we dispatch the container. Maybe we adjust the shipping schedule to ship more overnight rather than through the heat of the day. Data allows us to make these educated decisions and monitor the results of those decisions. Streaming data like this requires messaging, and messaging requires planning.
00:08:29
Speaker
AWS's IoT services allow to operate two different forms of messaging. First, we have a concept that's called the device shadow. Consider this to be a virtual representation of the last known state of the device. The device shadow allows you to interrogate the device, even if it's not connected. It also allows you to change the current state of the device, again, even if it's not connected.
00:08:55
Speaker
The idea is that when the device does connect, it will read the new desired state and apply it locally. Also, when the connected device does have internet connectivity, it will update the last known good state of the device as things change on it.
00:09:16
Speaker
A device shadow is great for maintaining
MQTT QoS Levels
00:09:18
Speaker
a device's current state. You might want to consider the device shadow for, say, Command and Control type messaging. So, close the door. Open that valve. What's the current volume level of the speaker system?
00:09:31
Speaker
Device Shadow excels at providing that current state, or last known good state, as the case may be, and providing the ability to set the state in a variable connectivity type situation. What Device Shadow isn't good at is streaming data at constant points. Device Shadow isn't going to give you a stream of data points over time that you can look back over history.
00:09:58
Speaker
This is where the second form of messaging comes in. The second form of messaging that the AWS IoT services provide is the idea of streaming messages via a queue. In this case, MQTT is the technology that's being used. MQTT messages allow you to queue up a series of messages and then transport them once the comms become available. The difference here is, let's say your shipment is moving through an area of poor communications.
00:10:28
Speaker
Using device shadow, you'll have the last known temperature as you lost communication, and then the current temperature as you regain communication. However, if there are 20 data points collected in the time being, you'll have lost all of those data points. Using MQTT, you have the ability to bank up those updates and then receive them all once communications has been restored. So MQTT is a much better option for maintaining those streaming data points.
00:10:57
Speaker
Now the good news is this is not an all or nothing decision. You can mix communication where it makes sense. There's nothing saying you have to use only one messaging system. We think back to our use case. We would probably use MQTT to report back temperature and humidity points over time. But we might adapt a device shadow to reflect the settings on the truck. So what temperature is the cooling system set to?
00:11:27
Speaker
What do we have for settings for the ventilation system? Data like that that references the current state. Now, if we fast forward to a later stage in our development, we might use the device shadow to make changes to the climate control of the ventilation as a result of data that we're receiving through the MQTT data stream.
00:11:50
Speaker
Alright, so let's jump into messaging here. The first thing to consider when we're referencing messaging is something called Quality of Service. MQTT supports three types of Quality of Service, or QOS. Quality of Service 0 is designed for fire and forget messaging.
00:12:09
Speaker
This messaging is called at most once. There's no guarantee of delivery, and once the sender believes the message has been sent, the message is removed from the sent queue. This is a good option when you have a very reliable network, or if missing an individual message isn't going to cause you a major issue.
00:12:27
Speaker
For example, if I have a temperature sensor that's sending a reading every 30 seconds to, say, a minute, if I miss a reading, the next reading is going to come in in a short period of time. Missing an individual reading isn't a big deal in this situation, or may not be. It depends on your use case. So in this situation, I might use QoS0. A quality of service, a QoS1, is known as at least once delivery.
00:12:57
Speaker
With this type of messaging, every message that is sent is acknowledged by the receiver. Messages aren't removed from the transmitter until such time as the receiver acknowledges. Now, Quality of Service 1, or QoS 1, is known as at least once delivery.
00:13:16
Speaker
With this type of delivery, every message that is sent is acknowledged by the receiver. Messages aren't removed by the transmitter until such time as the receiver acknowledges the receipt of the message. Messages will be re-transmitted by the sender if the message hasn't been acknowledged in time. With this kind of messaging, it's important for the receiver of the messages to be able to account for the fact that they may receive a message multiple times.
00:13:44
Speaker
This form of messaging you would want to include some form of message ID so that the receiver can identify that they have received a duplicate message. With this form of messaging you also may receive messages out of order as a result of retransmission.
00:14:00
Speaker
So you might receive message 1. Message 2 might go missing. Message 3 arrives successfully. And then message 2 is retransmitted and received. So you have to know how to deal with potentially that data being received out of order and what to do with it there. The next thing we have is Quality of Service 2. This is known as exactly once messaging.
00:14:24
Speaker
With this form of messaging, you transmit a message. The message is then acknowledged. The acknowledgement is then acknowledged. And then finally, the acknowledgement of the acknowledgement is acknowledged. So for those keeping score, that's a total of four messages flowing back and forth for each bit of data that you are transmitting.
00:14:44
Speaker
Quality of Service 2 is clearly the most resilient option for transmitting data. However, it does add a lot of overhead, which may not be necessary. So you really want to consider here the cost of data, as well as the reduction in overall speed. If we've got to make four passes back and forth across a slow connection every time, we're really going to throttle the amount of data that we can push through the system.
00:15:10
Speaker
So we need to consider is the exactly once functionality a better benefit than potentially just having to deal with the occasional retransmission.
IoT Messaging Structure Example
00:15:23
Speaker
Now once I've planned out my messaging scheme, so what form of quality of service I'm using and which option am I doing MQTT or am I doing device shadow or both,
00:15:36
Speaker
I'm then going to have to try to figure out what exactly I want my message structure to look like. Now let's think back to my use case that I described earlier. I'm going to want to include the device ID, as this would allow me to identify which shipping container that I'm referring to.
00:15:54
Speaker
I probably want to have a transmit sequence ID or a message ID specifically that can be combined with my device ID. It would allow me to uniquely identify which messages are coming from which device at what time. I want to include a timestamp, obviously, that will help me make sure I process the messages in order. And then finally, I want to include the sensor readings, so temperature and humidity.
00:16:22
Speaker
Given the nature of this information and the variable reliability of a wireless network, it's probably a good idea for me to settle on quality of service one. This will give me a good deal of resilience without the excessive overhead of quality of service two. And I'm probably going to settle on a JSON data format. This gives me a lot of flexibility because if I need to adapt my message formatting later and really
00:16:48
Speaker
These days, almost everybody uses JSON for almost everything. Back in 2001, when I first started in mobile, we were packing messages into binary datagrams. JSON is a huge sanity saver here. Let's put this all together. I want to have a small device.
00:17:07
Speaker
I'm going to have some sensors attached to it that will read temperature and humidity ratings. And obviously, I need to have some form of communications that's probably going to be a 3G, 4G connector. Or if I'm going via, say, a shipping container that's loaded onto a ship,
00:17:29
Speaker
maybe I want to have an intermediary satellite communications piece there. I then want to connect all of that into an IoT backend service like AWS's IoT Core platform. It's going to allow me to receive the messages and then process them and do all my backend logic on there.
00:17:52
Speaker
From there, what I would want to do is consider what I would think of for data and analytics. Maybe I can use some artificial intelligence to start finding out if certain trends in, say, humidity and temperature are going to result in a spoilage factor later on down the track. I've got a whole world of operations going there.
00:18:15
Speaker
But really what I want to do is I want to receive those messages. I'll probably use lambda to throw them into a data store because I want to store all of this data permanently so I can use it. And then look at my next stage down the track. So there we have it. It's a discussion on IoT messaging, really kind of broken down into the component parts.
00:18:35
Speaker
And this project I'm working on, use case, is actually going to be a water meter, a water level meter, but the messaging concepts really follow the same logic here.
00:18:46
Speaker
Now if you're interested in following along with the development I'm doing, you can do so on my blog. Go to basementprogrammer.com forward slash series forward slash iot dash dot dash net. This series also has companion YouTube videos that help you follow along. So I've got all the code and the instructions on my blog post and you can watch the video as I'm developing the solution as well.
Podcast Conclusion & Listener Invitation
00:19:14
Speaker
The idea there is to try to make it as easy as possible for anybody to follow along. Thanks for listening to this month's podcast. If you find my episodes interesting, please consider subscribing to the podcast. If you have any comments,
00:19:29
Speaker
Feel free to email me. The address, as always, is tom, that's T-O-M, at basementprogrammer.com. And if you'd like to appear on the podcast and you want to chat about anything we're talking about in technology, please feel free to reach out to me and we can chat. All right, until next month.