MQTT Experts Answer Your Questions - June 2022

Watch the Webinar

Webinar Overview

Drawing upon the success of our previous ‘Ask Me Anything About MQTT’ webinars and on popular demand, we started a webinar series under the same name. In this June 2022 edition, our MQTT expert Jens Deters answered questions around MQTT 3, MQTT 5, MQTT Sparkplug, OPC-UA, etc.

Feel free to ask questions on the HiveMQ Community Forum.

Key Takeaways

• The HiveMQ Enterprise Security Extension (ESE) expands the role, user, and permission-management capabilities of HiveMQ Enterprise and Professional editions.

• Retained messages are a valuable feature in MQTT that mitigates uncertainty regarding message publication. By enabling the retention of the most recent message on a topic, subscribers can stay informed about the current state, even during periods of inactivity.

• MQTT Sparkplug’s Report by Exception rule ensures that data producers publish data to the UNS only when they detect changes in the monitored value. 

• Sparkplug was originally designed for the manufacturing industrial context but Sparkplug workflows and mechanisms can be used in other IoT contexts such as smart homes, smart buildings, or anywhere you want to have a plug-and-play mechanism for your devices.

• The HiveMQ Enterprise Extension for Kafka adds monitored, bi-directional MQTT messaging to and from Kafka clusters for a highly scalable and resilient end-to-end IoT solution. For example, this extension can be used to transport MQTT data into the cloud ecosystem.

• While Transport Layer Security (TLS) enhances security, it can increase resource consumption. Aspects to consider when enabling or disabling TLS is whether you have a private MQTT server and whether the payload is encrypted.

• MQTT makes sense in any event-based architecture and is not only limited to device communication in IoT use cases.

Transcript

Welcome and poll

Jayashree Hegde: 00:00:09.000 Hello, everyone. Good morning, good afternoon, good evening. Welcome to our Ask Me Anything about MQTT session. Thank you for taking time today to join us. It is a pleasure to have you all. I'm Jayashree moderating this session. With me today is Jens Deters, who will be helping us with answering the questions. And joined by Jens is Gaurav Suman, Director of Product Marketing at HiveMQ, who will be moderating the Q&A. Welcome, Jens, and Gaurav. Thank you so much for joining us today. Before we kick off this session, I would like to share that this session is being recorded and it will be shared via a follow-up email. Feel free to submit your questions in the Q&A pod, which is right in the control panel. We have already received a couple of questions which we'll be covering in a short while. Lastly, there will be two polls running, one right at the beginning and one more at the end. I request you all to participate and cast your votes. It will help us in getting a lot of feedback. So without further ado, I will hand it over to Gaurav and launch the first polls. So welcome, everyone. 

Gaurav Suman: 00:01:26.857 Thank you, Jayashree. So I'll wait for you to put up the poll?

Jayashree Hegde: 00:01:32.168 Yep. 

Gaurav Suman: 00:01:32.769 Okay.

[silence]

Jayashree Hegde: 00:01:45.710 I've launched the polls. 

Gaurav Suman: 00:01:46.572 Excellent. Thank you. 

Jayashree Hegde: 00:01:47.553 [crosstalk] to cast the votes.

[silence]

Jayashree Hegde: 00:02:50.233 I'll end the polls now. Thank you so much for participating.

Introducing the panel and Q&A format

Gaurav Suman: 00:02:53.324 Thank you, Jayashree. Hi, everybody. My name is Gaurav Suman. I lead product marketing here at HiveMQ. I'm based out of Ottawa, Canada. And joining us today is Jens Deters. Jens is heading professional services at HiveMQ. Jens, you want to say a quick hi and then we'll dive into questions? 

Jens Deters: 00:03:08.388 Yes, of course. Yeah. Yeah. So I'm responsible for professional services at HiveMQ. And yeah, at professional services, we are helping our customers to implement their use cases to set up the HiveMQ Broker cluster in the right way and to configure it. We're doing architectural review and recommendations for cluster setups, for cloud architectures, and yeah, also how to implement the use cases in the right way, basically. 

Gaurav Suman: 00:03:40.314 Thank you, Jens. Great, thank you. So thank you for joining everybody. I see a few familiar names here. Appreciate you guys showing up. And what we do in the Ask Me Anything session is, of course, we give people an opportunity to submit questions ahead of time, and some people have. So we'll go through those questions. We'll see if that individual is on the call, and if they are, then we'll give them an opportunity to ask a follow-up question. So please, do that. We are here to help the community out. This is to make sure you know all that you need to know about MQTT and what could be your next steps with respect to your IoT deployments. Now that being said, I do want to say that the only bad questions are the questions which have not been asked. And another quote I like about questions is that there are no bad questions — there are only bad answers. And I can assure you with Jens here, there will not be any bad answers. So please keep them coming. 

Jens Deters: 00:04:31.374 [crosstalk] So it’s up to me not to give the bad answers, right?

Is it a good idea to structure Pub/Sub topics differently?

Gaurav Suman: 00:04:34.639 [laughter] Fair enough, Jens. So yeah, let's get started and then please, if you have any questions, there's a Q&A pod at the bottom of your screens. That's where we invite you to add your questions so I can keep organizing the questions and we'll keep sending them Jens way as we get those questions. So where we'll start today is a question by Christopher Donovan. Christopher Donovan is asking if it's a good idea to structure Pub/Sub topics differently. So I'm not sure what they mean differently in comparison to, but that's the question they're asking. What are your thoughts on this, Jens, about [crosstalk]? 

Jens Deters: 00:05:15.776 Yeah, it's a pity that Christopher is not actually joining our meeting today, obviously. So I think what he means is to have a different structure for publishing data and a different structure for subscribing to data. And I'm not sure if this really makes sense because I'm subscribing to a topic where I expect to get data from and I'm publishing exactly to this topic as a data provider. Otherwise, I have to make sure that if these are different topics, that the right data is handed over from one topic to another. So I need additional services to transport the data from one topic to another, like a bridge mechanism inside the broker. And it depends on the use case. But for now, I can't find any meaningful use case for this. So yeah, it would be interesting to get more context from Christopher here. 

Jayashree Hegde: 00:06:41.138 You're on mute, Gaurav.

Should the topic tree always include an identifier, a unique ID, UUID type value?

Gaurav Suman: 00:06:44.285 Thank you, Jayashree. So the other question they have is around identifying particular topics, and they're asking: Should the topic tree always include an identifier, a unique ID, UUID type value? What are your thoughts on this, Jens? 

Jens Deters: 00:06:59.255 Yeah, this also depends on the use case. For sure, I can't make a general recommendation that is always useful to include a UUID or some kind of identifier in the topic tree. So for some use cases, it really makes sense in terms of separating the data in the right way by subscribing to certain topics. So by subscribing to that topic, I make sure I'm subscribed to data from this specific device or this specific user. For instance, I know that this kind of approach is done in the automotive industry when receiving data from cars. Then any car has a unique identifier also for authorization. This might make sense. On the other hand, of course, you can add this kind of identifiers into the payload or if you're using MQTT5, you can make use of the user properties in this case. 

Gaurav Suman: 00:08:10.105 Right. And Jens, what happens in the case if — so in case of cars, that's an interesting example because an OEM is manufacturing a car — the car is then in your control. The manufacturer knows the code they're going to put in the car. But when the endpoint is not in your control, and then how do you allocate an ID? What's the way for a unique — does the client connection number become that kind of a unique identifier in that case? 

Jens Deters: 00:08:36.926 Yeah, the first unique identifier for sure is the client ID, which you are sending through the connection process with the connect message. That's the main identifier of the clients. But again, the car example, in the use cases, I know the car industry is using or implementing — there are several connections, MQTT, different devices who are establishing different connections inside or from the car. So using the client ID as a unique identifier might not make that much sense because if I have 10 connections, I have to use 10 different client IDs, but to make sure or to identify that all the data is coming from one car, for example, I can use a kind of identifier mechanism included in the topic structure.

What is the best strategy for saving and processing MQTT data on a private server?

Gaurav Suman: 00:09:51.522 Sounds good. Sure, sure. And just for the sake of reference for people who don't get exposed as much to the connected cars ecosystem, one of our clients has as many as 5,000 sensors on one vehicle chassis. So you can imagine the amount of complexity and density of data we are expecting from there. So as Jens was explaining, there are many best practices when it comes to organizing your data streams from those devices. So these are nuances which are worth understanding, of course. Great. Thank you for that answer, Jens. The next one is around — let me read the question, which is: Suppose I need to save and process MQTT data on a private server, so let's say on Google Cloud, what is the best strategy for that? Is it by subscribing to a topic? And the reason they need to save and process on their own server is because their customer requires that they log in via mobile apps. So the database is set up on the server to store and validate the login data. It's a Node.js app, and it's running on the server to validate and process data from the IoT devices. This question is from Novita, and Novita is not live on the call here, but let's see, Jens, what your thoughts are on this. 

Jens Deters: 00:11:04.993 Yeah. Again, it would be great to have Novita on the call to get more context on that. So I would say basically the best way to transport MQTT data into a cloud is via the event stream, the cloud providers — yeah. The hyperscalers to provide. In Google Cloud, it's a Pub/Sub mechanism. In Azure, it's the Azure Event Hubs, for instance. And in most of these cases, it's Kafka behind that. So you can make use of the MQTT Kafka combination in terms of the HiveMQ Broker. It's really a dream team to use the Kafka extension to transport the MQTT data into the cloud ecosystem. 

Gaurav Suman: 00:12:02.879 So Jens, how about this element where they're saying they need to — I find this interesting because they're trying to authenticate a client with data that is stored on their local server. So they are in this — I don't know if it's the best practice or not, so I would love your views on this. They're saying they want to bring in all the MQTT traffic on a server which is hosted on a cloud provider, and they are doing authentication local to that. They don't have to do it this way, right? The authentication could potentially happen in another auth store somewhere else, right? 

Jens Deters: 00:12:36.519 Yeah, sure. Yeah. So this could also be done — in terms of HiveMQ Broker, maybe it's also a good idea to use the Enterprise Security Extension for authentication and to connect to any authentication and authorization mechanism you would like to. So yeah, it would be cool to get the context of this use case — why this is separated and not hosted completely in one cloud ecosystem.

What's the best practice to provide the initial state to a device?

Gaurav Suman: 00:13:14.054 Sounds good. So Jens, we have received a question on the Q&A pod. The question is — they're saying it's a general MQTT question — and the example they are taking is of a temperature sensor. The temperature has only one user setting, a fixed time interval between different temperature values. And then when the device is just powered on, it needs to know its configuration setting, so the initial state. What's the best practice to provide this initial state to the device? Is it to use the function of retained messages?

Jens Deters: 00:13:42.629 Exactly. That's exactly what the retained mechanism is made for. So you don't have to wait for the next data push. Maybe the temperature is only changing once in three hours. And the value is pushed in an interval of one hour, then you might wait for about one hour to get the next value. And also in terms of the configuration, if you want to receive some data on the device, once it's powered on — so powered on, for me, it means it connects to the MQTT broker and subscribes to a topic. And if there is a retained message stored on the topic, the client is instantly receiving the current data, which the device might be interested in. The same goes for the value of the temperature the device might send. So if you're sending these kinds of data always [inaudible] as retained, any client who is subscribing to that certain topic will receive the last known good value. That's exactly what retained messages is for. And to go one step further, I also would implement here or I would do the report by exception approach here. So only update data which has changed. And in this case, you're saving a lot of bandwidth because you're not transmitting the same data with no change in a specific interval. And by sending these kinds of exceptional data retained, also any interested client is getting the last value and does not have to wait for hours for a change of this value it might cause a reaction on. 

Gaurav Suman: 00:15:48.154 So Jens, if my memory serves me right, this is a Sparkplug specific feature, right — report by exception — or is it generally available at MQTT 3.1.1? 

Jens Deters: 00:15:56.351 This has to be implemented. It's not specified by the MQTT specification. It's a concept inside of the Sparkplug specification because it really makes sense. But also this concept or this approach can be implemented in a vanilla MQTT situation also. So for me, a report by exception always makes sense. If you're not implementing the Sparkplug specification.

What's the recommended way to consume MQTT messages in Azure services?

Gaurav Suman: 00:16:28.901 Sure. I mean, the impact on bandwidth and computing resources is massive. There's less to process. [crosstalk]. Sure. So I don't know who the individual is because they entered this question as anonymous. So if you are willing to just share your name, we would be happy to answer any follow-up you might have on this. You can put your name in chat or just in the Q&A pod again. We'll keep moving down the list of questions, but if you want to ask a follow-up, we are happy to do that. So just going back to the list of questions which have been submitted to us, Jens. And thank you, by the way, for that answer. Really, really helpful. The next one here is around — what's the recommended way to consume MQTT messages in Azure services? I'm using a Paho library to read the MQTT messages in Python and deployed that as an Azure web job. Is there any better way to consume the messages? This question is by Kumar Rabinov and they are from Capgemini. So Jens, what are your thoughts? 

Jens Deters: 00:17:30.614 Yeah, it's kind of similar to the last question about how to transmit MQTT data into Google Cloud and so on. Especially when it comes to transmit MQTT messages into Azure, I highly recommend to use the Kafka extension to connect to the Pub/Sub service. This has several advantages. And one is — you don't have to implement and to operate a specific service which is just subscribing to a certain topic and transfer the data into a database in Azure. So if you make use of the extension mechanism of the HiveMQ Broker, you don't have to take care of hosting and operating on additional services just for transmitting the data because it's included in the broker runtime, basically. And when using the Kafka extension, it's an extension provided by us from HiveMQ. So we will take care of the software quality and the support of this extension. Especially when it comes to Azure, we might also share the link to our resources on our website. We have some webinars available and white papers available about the HiveMQ and Azure connection, and yeah, some use cases and some examples and this might be helpful to have a look at.

Gaurav Suman: 00:19:18.580 Absolutely. Thank you. Thank you for mentioning that, Jens. In fact, I was going to show this particular blog post which was done by Matthias. You can see my screen, Jayashree. Can you confirm if you can see the blog post?

Jayashree Hegde: 00:19:31.886 Yes. 

Gaurav Suman: 00:19:32.643 Okay, perfect. And here is where Matthias, who's on Jen's team in our professional services group — he goes in-depth into how the HiveMQ extension for Kafka, which as Jens mentioned, at runtime, is invoked and it starts to do its job. And there are very particular nuances, as you can see here around message size, etc. So we've done a deep dive on this, and you're welcome to check this out on our website. The other page I'll bring your attention to, which can really give you a deep insight on where is it that Azure and MQTT broker technology come together and how HiveMQ is doing that. We have an Azure solutions page where we explain this in great detail. We are putting a lot of content out specific to Azure. I know it's an important conversation to have with our community here. You'll see on our website a lot of resources to educate yourselves and also choose to figure out your path in terms of Azure and MQTT integration. 

Jens Deters: 00:20:32.466 Yeah, this is not only limited to Azure. So you can think of Azure as just an example of a hyperscaler here. You can do it in a similar way if you're using AWS or Google Cloud. 

Gaurav Suman: 00:20:53.407 Makes sense. Thank you, Jens. Let me just see. I think we have in the Q&A pod — we have some other questions. Okay, so Tobias, if you're okay, I will unmute you. And for the previous question you had around getting the initial state, we'll give you the opportunity to unmute yourself and ask any follow-up you have for Jens. And I see your other question, but anything you want to ask as a follow-up for the previous one, you're welcome to unmute yourself and ask. 

Jayashree Hegde: 00:21:27.713 Tobias, I have unmuted you. You can start interacting.

Is there a way to do data compression together with MQTT?

Gaurav Suman: 00:21:38.783 You're still on mute in case you're talking, Tobias. Okay. Let me, let me read the other question they've submitted, and if they feel like they can, of course, unmute and share their follow-up question. So the other question they have is: Is there a way to compress — oh, is there a way to do data compression together with MQTT, or does that have to be implemented manually on top of the protocol? They're saying, "We are using a low-bandwidth mobile connection, LTE-M1. So we want to use minimal data. What are your thoughts, Jens? 

Jens Deters: 00:22:15.256 So there's no compression mechanism included in the MQTT spec here. So you will have to implement this on your own. Yeah. And I think this is focusing on the compression of the payload, right? 

Gaurav Suman: 00:22:35.168 I would think so. Yeah. 

Jens Deters: 00:22:36.607 So the header of the MQTT packages is really very small. That's the beauty of MQTT, or one of the beauties, to have just some byte small header. And when it comes to the payload, you are free to add almost 250 megabytes of binary payload. But you can also — for sure, you can compress it as you like. So you can just zip it or compress it in a way like using a Google Protobuf, for example. And you will get a very compact data format using Protobuf, which is also schema-based. So it's also one of the advantages to use Avro or Protobuf here. So the short answer is yes, you have to implement your own mechanism to compress the payload data here. 

Gaurav Suman: 00:23:45.988 Sounds good, Jens. Unfortunately, Tobias doesn't have a microphone on the machine they're using, so that's [laughter] why they're having trouble unmuting themselves, but I think they did get their answer. The other thing I just wanted to add here, Jens, and also get your perspective on is saving bandwidth and saving, say, compute resources is vital to the success of a wide-ranging IoT deployment. And one use case that comes to mind we've implemented for a company based out of — I believe it is Sweden. What they're doing is they have remote traffic management services. So if there's a construction site, they will install remote traffic signals. What was interesting was this is in the middle of nowhere, pretty much. Many times they will have construction happening in a countryside somewhere in the mountains. There's no person there to change the configuration, etc. So they want to be able to do that remotely. So have somebody go install the device, but manage it remotely. And what they found was that just enabling TLS — which is absolutely recommended since you want to secure your traffic — but just by enabling TLS, the computing power went up for those devices, and also the bandwidth needed went up. 

Gaurav Suman: 00:25:02.211 So the option they needed was, because it's a private setup, by nature, not exposed to the internet — by nature, not exposed to the public. They were willing to turn off TLS, but doing that with, say, a hyperscale provider was not an option. And we're talking about one of the larger hyperscale companies. So what they're doing with us is they have a private MQTT server, and they've turned off TLS because it's a private setup. And what that enables them to do is conserve bandwidth. So the strategies can differ. We talked about Report by Exception before. As I just mentioned, you're turning off TLS, for example, is another. So depending on your use case, there's so many different ways in which we could find the right sort of optimal mix in this case. Anything to add, Jens, just from a conservation perspective? 

Jens Deters: 00:25:47.569 Yeah, yeah, yeah. So TLS costs some overhead for sure. So you have all these handshake stuff and you have to — yeah.

Gaurav Suman: 00:25:59.800 Excellent.

Jens Deters: 00:26:00.571 Yeah. In this way, if you can make sure that it's a private setup, it's reasonable to disable TLS to save bandwidth here. When it's traffic that is public routed, yeah, maybe you have to find other strategies to save bandwidth than deactivating TLS. 

Gaurav Suman: 00:26:25.208 Right. And then again, you know we could still encrypt the payload. The payload could still be encrypted. It's just TLS will mean that you're exposing the metadata more than —?

Jens Deters: 00:26:34.139 Yeah, that's the disadvantage when — it might go for the authentication because username password is readable or JWT token or something like this. That's encrypted when using TLS because it's a transport layer, clearly. But if you can skip this, you are always free to encrypt and decrypt the payload for sure, to make it more secure.

Any Sparkplug specifications included in MQTT 5, and are they different from MQTT 3.1.1?

Gaurav Suman: 00:27:07.949 Sounds good, thank you. The next one I want to take here is around recommendations around ways to consume. Oh, I'm sorry. We went through this one already on Azure. Let's pick another one around Sparkplug specification. And the question is around information on Sparkplug specification. Any Sparkplug specifications included in MQTT 5? And if they are different from MQTT 3.1.1 — is there a difference based on which specification are we using as a foundation for Sparkplug plugins? 

Jens Deters: 00:27:46.758 No, for Sparkplug, basically you need the support of retained messages. You need support of Last Will and Testament (LWT). You need quality of service one and two (QoS 1 and 2). So this is also specified by MQTT 5. So that's why you can clearly also use MQTT 5 for Sparkplug.

What are the advantages and disadvantages of pushing MQTT in directions other than IoT?

Gaurav Suman: 00:28:12.529 Sounds good. And I missed out. Kumar was on the call. Are they not there anymore? Probably not. I don't see them anymore. Okay. Yeah, I think we missed him by a few minutes here. But the last question was from [inaudible] and I missed the chance to give him an opportunity to ask a follow-up. So let me ask you this, Jens, just based on a conversation I recently had with a prospect. And they are tackling clickstream data on MQTT. And it was interesting because generally people would think of MQTT as an IoT protocol. And here we had somebody using this as an intra sort of Kubernetes cluster communication protocol, intra microservices communication protocol. So is there a more widespread use case you see? Can you speak to us about advantages and disadvantages of pushing MQTT in directions other than IoT?

Jens Deters: 00:29:13.478 I think in any event-based architecture, MQTT makes sense. So it's not only limited to device communication in IoT use cases. I recently spoke to someone who is implementing medical devices, and he's using MQTT and the MQTT mechanisms like last will and testament and retain messages for inter-process communication on a Linux operating system on the device itself. So he installed a small broker service and is using MQTT for, yeah, interprocess communication and uses this “last will” for being notified if a process dies and has to be restarted. So this could also be used inside one device. So not only for data transportation on a larger scale and with a huge amount of devices. And yeah, also in logistics, for instance. And you have devices like scanners or other barcode readers, but this is also a situation which is not really IoT like [inaudible] which are connected. Yeah. So in any scenario, which is event-based, you can use MQTT. This must not be a device-to-device communication.

What about using MQTT vs. ZeroMQ?

Gaurav Suman: 00:30:52.795 Right. Thank you, Jens. And now we have a question from an attendee who hasn't put their name on here, but they're asking about ZeroMQ. And if you have an opinion on using MQTT versus ZeroMQ. Any thoughts on this, Jens? 

Jens Deters: 00:31:16.782 [laughter] I'm really new to ZeroMQ. I know that ZeroMQ exists and it also does IoT communication and messaging, but I don't have a battle card ready for a shootout of the pros and cons between MQTT and ZeroMQ. 

Gaurav Suman: 00:31:44.763 Yeah, I'm just trying to look up because I don't recall what's there. Are they a GMS broker of some kind or if they're AMQP-based? I can't find enough information. The person who's asking this question, if you don't mind and identifying yourself and then just unmuting themselves, once you identify yourself, we are happy to answer your question in better detail. We need some more context here as to what your goals are and if MQTT can serve those goals. So I'll give you a moment if you want to put your name in the chat or in the Q&A pod again and we can get you to unmute yourselves.

[silence]

What's the ability for MQTT to interop with OPC UA servers?

Gaurav Suman: 00:32:36.012 Okay. Yeah, they're not coming back yet. Okay, let me ask you a question, Jens, around OPC UA. And this keeps coming up quite often, right? So what's the ability for MQTT to interop with OPC UA servers? So can an MQTT publisher write to OPC UA? And also the other way around — what's the interwork between OPC UA, Pub/Sub, and the MQTT traffic patterns? Any thoughts on that? 

Jens Deters: 00:33:15.443 So I know that there is an additional chapter to the OPC UA specification deck, which is quite huge. I think OPC UA specification and all this framework is about 1,200 pages or more than that. And there's one chapter about Pub/Sub with OPC UA. And basically, this is a bridge from the OPC UA ecosystem to an event-based ecosystem. So they recommend to use MQTT for implementing the Pub/Sub bridge. An alternative might also be AMQP, but I think in most of the cases out there, it's done via MQTT. 

Gaurav Suman: 00:34:10.172 Sure. Sounds good. And then I wanted to quickly reference content on our website again, where we detail how MQTT and OPC UA interwork. And as Jens was just explaining, implemented an MQTT broker for OPC UA communication. So there's great detail in here. And of course, we have this available as a download, so you're welcome to do that and follow up with us if you have any questions around that. 

Jens Deters: 00:34:42.280 It's really highly recommended. If you're in the context of industrial IoT, you should have a look at this because frankly, OPC UA, I know it's not popular, but OPC UA is not the answer or the future of industrial IoT. There are several reasons why it will not fit the industry 4.0 requirements and the digitalization in the industrial context.

Final words on overall best practices

Gaurav Suman: 00:35:20.487 Right. Thank you. Thank you, Jens. Anybody on the call here who wants to ask a question live, we can absolutely unmute you and give you an opportunity. Otherwise, we'll just go to Jens one final time for any best practice tips, any recommended reading, etc. And then I know Jayashree has a quick poll for all the attendees in the end. But final call for anybody who is live on the call here, if they want to get the opportunity to ask a live question, you're welcome to. So Mohammed, Michael, Johnston, Jay, Gerardo, Eduardo, David, Dave, Braxton, Rivaldo, if any of you have a question, you're welcome to let us know in the chat and we'll unmute you and you can ask a question. And Salim, I missed Salim. I believe they just joined. All right, looks like not. So Jens, any final words on your overall best practices? What should people read up and do in terms of just MQTT enablement, IoT strategy enablement? 

Jens Deters: 00:36:27.301 Anyway, I highly recommend to have a look at the Sparkplug specification because it's not only — basically, Sparkplug is meant to be created for the manufacturing industrial context. But you can also use the Sparkplug workflows and all the mechanisms for other contexts like smart homes, smart building, anywhere where you are interested in having a kind of plug-and-play mechanism for your devices. And yeah, this approach of device management Sparkplug is defining and the state management. And what was also interesting about the Sparkplug is that it's defining or it specifies the payload schema and the data format for the payload. So you have an open-source industrial specification, how to use MQTT. And this is, yeah, really interesting, not to invent the wheel twice all the time.

Gaurav Suman: 00:37:56.184 Great point, Jens. Thank you. I greatly appreciate your time and insights. Jayashree, over to you. 

Jayashree Hegde: 00:38:01.764 Thank you. Thanks so much, Jens. Thanks, Gaurav. And thanks, everyone, for attending. I will run the second polls. I'll give a moment for people to give feedback. Yep, the poll is up. I'll end the poll now. Thank you so much for participating. And it is great to have you all. See you all in the next session. So we will be sending out a follow-up email with the recording of the session. So you will get the follow-up email in a day or two. And we will also announce the next AMA session soon on our website. So please keep an eye on our webinar page. And we'll also share a couple of resource links in the follow-up. And if you have any questions, feel free to reach out to us. We are here to help. So see you all next time. Thanks, Jens. Thanks, Gaurav. Thank you so much. 

Gaurav Suman: 00:39:10.009 Thank you everybody. 

Jayashree Hegde: 00:39:10.907 Have a good day, everyone. Bye-bye. 

Jens Deters: 00:39:12.207 Bye-bye.