 So, welcome to OpenJS World and today Jesse and I are going to be talking to you about Internet of Things with Node.js both practical and fun. Before we get started a little bit about ourselves, I'm Michael Dawson, the Node.js lead for IBM and Red Hat. What that means is I get to be an active community member, I'm a collaborator, member of the technical steering committee, and generally active across the project. It also gets to mean that means that I get to work with great teams across Red Hat and IBM. For example, Jesse, in terms of our support for Node.js on different platforms, as well as, you know, all sorts of things in terms of making Node.js first class citizens in our offerings. And thank you, Michael. I'm Jesse. I work with IBM, as Michael mentioned. I'm the business architect of open source on a platform known as IBMI, which you may have not heard about before, but it's definitely a platform with a strong footprint in IT. It powers banks, insurance companies, all kinds of Fortune 100 and Fortune 500 companies as well. But in my role here at IBM, I get to set the strategy around open source technologies for that IBMI platform around things like open source languages and IoT. So just before we get started, a little bit of an idea of what we're going to go through. So we're going to start with a brief introduction to IoT and MQTT. So what are they? Where are they important? We'll look at using MQTT with Node.js, because they're a great fit. We'll take a look at some real physical devices. We'll talk about the anatomy of a simple MQTT light and temperature sensor that might fit one of your business use cases. We'll then show you MQTT and devices in action in a demo part. We'll then touch on leveraging MQTT with the cloud. And we'll finally, we'll finish up with a few thoughts on reactive applications and Kafka. So to start with, what is the Internet of Things? Generally, it's what's used to refer to a network of physically connected devices. These devices provide data, often a constant stream of things like temperature, pressure, and so forth. They can also often be controlled, though. You can send a message back to the device and you could turn a light on or off, open a door, those kinds of things. And if you want a more comprehensive description, you can go and check out the Wikipedia listing for the Internet of Things. Now, one of the most commonly used protocols with IoT devices is MQTT. It's MQ, it stands for MQ Telemetry Transport, was actually invented by somebody at IBM quite a while ago. And it's really popular because it's really lightweight. You can do a publish and subscribe. So it's a message base where you publish the topics and you can subscribe to topics. But it's very small, it's got a small footprint, it requires low bandwidth, so you can get it into small devices and it's fairly easy to use and that's kind of why it's so popular. Again, if you want to go back to a reference, you can look at MQTT.org in terms of the formal definition there. The great thing is it's asynchronous, which is a really good fit for Node.js, as we know. So let's dive into some of the specific terminology. So the first thing you need to know is the client and the broker. So clients are basically devices, applications running on CNIBMI or some other platform who connects to a topic either to publish or subscribe messages. There's some great clients out there, so Fao and MQTT.js. So Fao is one which provides clients across a number of different platforms and languages. MQTT.js is a NPM module written by one of the members of the Node ecosystem and it's a great choice when we're using Node. The broker is the piece that actually provides the message queues and the persistence and sort of the backend. Often MQTT is provided as a protocol along with a bunch of other protocols, so later on Jesse's gonna show us AMQ and AMQ supports a number of different protocols, MQTT being one of them. Mosquito is a javascript peer javascript broker that you can also use for experimentation as well. So that's the client and the broker. Topics are basically an ID that we subscribe to when we wanna listen for messages or what we publish on when we wanna send messages. Messages themselves are free form so they can basically be any text. So it's up to you to figure out what that formatting is gonna look like. And then QoS stands for Quality of Service and MQTT provides three different qualities of service, zero, one and two, which we'll talk about in the subsequent slides. So let's look at topics. Topics are one or more levels separated by a topic separator. And in this example, we have factory is one level, floor is another level and machine is another level. And I can ask, when I subscribe, I can subscribe to a very specific level so I can subscribe to factory floor machine one in which case I'll just get messages for that one topic. Or I can subscribe using wildcards which I show a little bit below so that I could get like all messages for topics that are underneath factory floor one, for example. There are a few restrictions. They must be at least one character each level and they are case sensitive so it's good to be aware of. Wildcards which are very useful when you're subscribing on topics are the plus which matches a single level. So in this case, factory plus slash plus slash machine one will match factory floor one machine one but not something where there's two intermediate levels like the second example. The hash sign, number sign, matches multiple levels but it's only allowed at the end. So it basically says I wanna get messages for all topics below this route that I'm specifying and those end up being quite useful. At very least if you're trying to figure out what topics are available and messages are coming into you on. Quality of service, there's three levels. They're very simple. Zero is at most once, one is at least once and two is exactly once. And if you think about simple devices at least often at most once is all you need. If I'm sending a stream of temperature readings it really doesn't matter if I miss a message. Because the next one will come along and I'll still have the data. But depending on your application you can use some of the other ones which is like at least once you're guaranteed to have it delivered although it may be repeated in that case and then two is like it's only ever gonna get it. Of course as you pick the higher levels there's gonna be more overhead and so unless you really need to zero is probably the way to go. The other thing is that the QS is determined by the receiver so even if you actually ask for a higher quality of service when you're sending you may not get that on the other end. So now over to Jesse to sort of give us a little bit of why are people interested in IoT in our context? Yeah, thanks Michael. And obviously it's easy to see that IoT continues to play a growing part in everybody's day-to-day lives. I'm guessing each person attending today uses IoT in some shape or fashion and probably with multiple devices. We have smart watches, smart appliances, smart TVs, smart cars, all of these things we call smart but we have IoT devices more and more prevalently available in our life. But from a business perspective if you are a developer or a manager or an architect and you're trying to see, am I in an industry that cares about IoT? The short answer is most likely yes because IoT technology now is really transcending across many different industries. So we have IBM I clients for instance in the trucking industry who are managing their fleet to make sure that things like the temperature of their meat when it's in shipment is good to keep the product safe and so on. We have clients in the medical industry and they're investing in smart devices that are easier to maintain, have lower rates of failure and things like that as well. So IoT is very prevalent in many, many industries these days. Okay, now just, oh yeah, there you go. We'd lost your video there for a second. So you're back. Sorry, I'm back. All right, fantastic. So we do have, oh, lost me again. All right. Now we see again. All right, fantastic. So a simple publisher example that we have here is written with that MQTTJS project that Michael mentioned that is relatively easy to use, relatively flexible. And it's kind of the tool of choice for us because of those reasons, right? Lost my video again. We're getting a little bit of technical glitches. The IoT technology works much better than my current web cam technology. But top to bottom, it's a pretty simple example in the sense that we just require some pretty common modules that you see with FS and PATH. We require in this MQTTJS module and most of the code is actually setting up the SSL bit because we chose in our demos that we set up to encrypt the communications with TLS. And so that requires us to set up the options with the client certificate and certificate authority, trust stores and things like that. And so really you can see, we're just setting that up in this MQTT options object. And then we call the MQTTJS library to connect to the broker of choice. In this particular case, it's an IBM I system we use for demo. And then once we're connected, we can subscribe to a topic. And in this case, we just spit that output out to the console just for quick demo debug purposes. Right. And the previous one, the previous page just showed, actually publishing on the same topic. Yep, absolutely. And the code is pretty much the same. It's just the only thing that's different is what are you going to do once you get connected? You register a callback for a message received versus calling the readily made APIs for doing that simple publish to that MQTT broker. That's right. We just didn't want anybody being able to publish to our broker, so we added some security. So now we can move on and actually look at some devices. The IoT devices you can use range from all sorts of different things and sizes. If you look at the lower right, that's an ESP01, that's a very small but it has built-in wireless and enough memory to be able to run a small program. And the one beside it is a slightly larger one that already has like a USB port. It's one that I commonly use because you can just plug it in and now you've got something that's got some pins that you can use to turn things on and off, take readings. And then all the way up to something like on the top left where we have a Raspberry Pi, where you can run a real operating system and all sorts of things in between. I kind of like the socket one on the right because that's one where actually you can load in your own JavaScript code, connect to an IoT network and turn the light on and off and stuff like that in addition to some of the ones that we've built here. This is another one I've worked on more recently. It shows that the Wemos Mini D1 where it's a weight sensor. And so basically the sensor that reads the weight connects up to that little device which can then connect and send over MQTT the weight of whatever you put on top of it. You might also ask, well, what about some existing devices? So instead of trying to build my own, build my own, there's a bunch of devices but not all of them use MQTT. So a quite common pattern is to use a MQTT bridge where you have that bridge converting from whatever protocol the devices are using into the MQTT protocol. In my example, there's a lot of devices out there that you can get that run on 433 megahertz. And so like we have a door sensor, a motion sensor, actually a fire alarm that will go off and again send messages on 433. The most right one is a temperature sensor. And I have a bridge written in Node.js actually that can take the messages that come in through the 433 megahertz and we can convert them to MQTT and then use those messages. And actually this one isn't written in Node but this one's built on ESP8266 that can do that conversion. So now let's look at what it would take to say build your own device just so you can see that it's really not that complicated what's going on in the devices if you wanna build something that's purpose fit. In industrial cases, you'll more likely want to buy a commercial device for support and so forth. But if you wanna start experimenting and sort of proof of concept what you might be able to do in your business, this is a good way to get started. So let's imagine that for example, your business grows plants. Maybe things like temperature, humidity and light intensity throughout the day might be interesting. And in this case, this is something that I've set up. I'm growing a few plants in my basement, mint and basil, some nice spices, stuff like that. And I ended up through that device which you can see there. It's built on again, one of those ESPs and it collects light, temperature and humidity. And through the MQTT network I can fairly easily get that data out. And then I put together a Grafana dashboard that consumes that data and shows me the trends of the humidity, temperature and light. You could set up alerts to say, okay, wait a sec, the lights went off when they're not supposed to or if things are getting too hot, too cold and so forth. This is the version of the devices that we're actually gonna show you in the demo. A slightly earlier version of those, I'm just trying to raise it up so you can see it. And it builds in the ESP, has a light which blinks every time it's sending the message and it collects light and temperature information. This is the circuit diagram of what it looks like. So we have that Wemos which has a nice USB port you just plug in. It's got a light sensor which is that GL device. It's basically just a resistor that changes resistance based on the amount of light that there is. It's connected to the analog pin on the Wemos through a resistor divider so that you get a different value depending on how much light is being presented. And then on the right hand side is a DS18B20 which is a integrated temperature sensor and basically through sort of a one wire protocol you can talk to it, ask for the temperature and it gives that back to you. And then for as shown when I was showing you a device there's also an LED that we can turn on, turn off and it's set up to turn on and off whenever it's sending you some data. Looking at what's actually in the device itself we saw topics. So when I introduced the concepts topics were one of the important topics and you can see there the light topic, the temp topic and the LED topic. So those are the topics that the device will publish on when there's a light reading, a temperature reading or basically you wanna tell it to turn the light on or if the light changes. On the right hand side we see some of the code and again just like the case that Jesse showed us earlier in terms of the node client a lot of this is just boilerplate so that we can get our connection to the network and our certificates. Again over here is still more sort of boilerplate. The nice thing that you'll notice here is like I didn't have to write the code to query that temperature sensor. There's already a Dallas temperature sensor sort of library that's out there and so we can leverage those in a lot of the things that we write. These tend to be, they tend to work very much like you would expect an asynchronous system and if you're familiar with node through callback. So in this case, part of the code is a callback that says when I get a message posted to a particular topic this is the code that I wanna run and in this case it says like when I get a message I'm gonna check whether that's a message telling me to turn the light on or turn the right off and associated you know it then calls the function that will actually write the appendage to make that change. Now we start to get into the code itself and you can see that I'm creating the pub sub client and I'm passing here that callback which we saw on the previous page to say okay this is the callback when you get a message that I want you to run along with the connection info that says you know what's my MQTT port and server string. The code itself here now is mostly around getting the certificates all set up and passing in a unique ID. The one of the key things is every client really should have its own ID otherwise I've found that some of the brokers get confused. So in this case we use the MAC address as a unique ID because that's gonna be unique for every device. And you can see here that when we create our clients so we create a client, we've created a client and within this loop we basically at the first we check to say are we connected to the Wi-Fi? If so let's start, if not let's actually say let's connect and here's where we're passing in that unique ID and once we're connected we subscribe to the topic in this case the LED topic that we can send. Then inside that loop the other thing we do is every so often so we've got our transmit interval seconds and delay. We want to take the temperature and light readings and publish them to a particular topic. So we saw those topics earlier, the temp topic and the light topic. So this code basically interacts with the library that I mentioned, converts it to a string because we said that the messages were just plain formatted text and then publishes to the temp topic and the light topic and then toggles the LED so that you get some feedback that is actually sending the data out. Now I showed you C++, if you don't like C++ and you want to do it in JavaScript I won't go through the same description but you can do that through a Sprino and you can write it in JavaScript. The code looks very similar, you have a similar loop and in fact I did that to push the same code into a demo type that device like this and if you want to go check it out you can go check out my GitHub repo to take a little more look and more detailed look through the code there. So now we're at demo time. I'll hand it back over to Jesse. So Jesse is still there? Sorry about that, yes I am here. We are going to walk you through a really quick demo and then we'll show you the code behind it. What we're actually going to do is we're going to show consuming data from these light and temperature sensors that Michael just talked about and then we're going to actually store that information in a database to be used by other database applications. So set up to get this to this point I have active MQ running on my system and it happens to be an IBM I system but that's not necessarily relevant. It can be anywhere, these are all very portable and we wrote a little bit of node code that I'll show you in a little bit. What Node.js code does and make sure that the database exists and you can see in this case it already has the schema and everything because we've run this before and now because those devices are sleeping and sending data as temperature changes or light changes or every 10 seconds you're going to see this light and temperature sensor data coming in on a periodic basis, right? And so when that light and temperature sensor comes in we see the console output here and that information is also available in the database. And so I'm going to pop up an SQL tool here where I'm doing a simple select from this table that I created, this IoT records table for temperature and sensor data. And you can see there's a couple of tabs that popped up down on the bottom and you can actually see the historical time behind the various sensor values for temperature and for light as well. So if you're interested, that's the temperature in my office and I can actually put my hand over the sensors here if we want to see the light go down a fair amount. But maybe we'll come back and take a look at that afterwards if you want to go ahead and show the code. Yep, if we have time to do that we'll circle back and do that in a little bit but the code behind it is going to be very simple and very familiar to the code we showed you earlier in the presentation today. We're going to set up the connection to the broker in exactly the same way. We showed you the example client certificate setup and the SSL setup and Michael, I need to stop sharing. Oh, sorry. No, I did stop sharing. We need you to, we need the slides back up. Right. There we go, sorry. The only thing that's different is, when we're consuming data, we showed you this one before, we're consuming the data, we stick it in console.log, you see it in the terminal but we're going to take that a step further like I just showed. So if you go on to the next slide we actually wrote some code to store it to the database and I'm not going to walk you through all the details here. We're using an IBM database connector, creating a table if it doesn't exist and just doing some basic database setup there. And if we go to the next slide, all we did is we modified our callback for when we receive a message to do a simple insert into statement with SQL. And as you can see, it's just a few lines of code to get that level of integration. So now any database application can interact with this IoT data. Yeah, and that's really, I think, one of the reasons why it's so popular is that really a very small amount of code, just a few steps, and now you've got data flowing from the devices all the way into your database where you can take some more sophisticated action and stuff like that. Yep, exactly. So we've shown you actually connecting the devices directly to a system, which is running a broker. If you don't want to set up that yourself or you want to make it something that can go across, it's not necessarily stuck within your organization. One good thing to do is leverage the cloud. So you could sort of do what's shown in this first picture, which is to move some of the pieces from your internal system out into containers running in the cloud. And that's actually what I did for some of the applications I've been playing around with is I ran an MQTT broker in the cloud and then a node application. And in this case, it's an example where, either through a UI on a computer or on my phone, it can talk to that controller, that controller will convert whatever buttons you press to say turn on lights, turn off lights into an MQTT message, publish it to that broker that's in the cloud and then that device, which is a plug, plugged into my house and is connected to a Wi-Fi that can get out to the outside world, connects to the broker. Now I'm controlling everything without having to be running a broker on my own premises. But even better, there's a number of IoT platforms that you can get from organizations. And they will provide you all those pieces so that basically you can just say, here's the devices I wanna connect up to my IoT system and both from the devices and from the clients. The thing I did wanna mention here is that the one thing that's a little bit different is they often have a few more constraints over things like the topic. So for example, in this particular part of the code, I show that you need to change the light topic so they're structured in a way, for example, this is for the Watson IoT cloud, in a way that fits their environment because it's a multi-tenant environment. So in this case, I need to say IoT2, event, light, and they even sometimes add some extra features, in this case, it's formatting. So I can tell it what format the message is coming in. And so I had to change the format of my topics and I had to change the format of my messages. The nice thing about that though is that then they let you very easily start to chart, graph and work with that data because having it being structured as JSON, for example, they can extract it and you can put it on charts and so forth. So if you're getting into this, that's another good way to sort of have a quick bootstrap to getting charts, graphs and data and all that kind of stuff. All right, and I'll quickly just mention a couple other tools that are available for doing IoT programming. One of my favorites is Node-RED, which actually allows a low-code graphical type of designer that allows you to just define your application logic as a flow of data through all these various nodes. I worked with a client once who actually set up a very large manufacturing integration with PLC devices all linked up through Node-RED and it works like a charm. And it's very simple to use, very easy to prototype and deploy to production. So that's something definitely worth looking into. And another trend that we're seeing is this whole notion of reactive systems. And so if you go out and you read the reactive manifesto that comes in various key attributes that are defined as a reactive system, right? It needs to be responsive, elastic, resilient and message driven, right? And so we're seeing an uptick in interest in messaging technologies and Kafka is quickly becoming the ML, the standard mode of operation, the messaging component of choice. And so as you're defining your plan for IoT, you need to also maybe take this into consideration as well because your IoT data might need to very well integrate with some kind of messaging system. There's a product out there called Apache Camel, which is really great as I say, for tying anything to anything, including tying IoT devices and technologies to messaging systems as well. So I'll hand it over to Michael to wrap things up. Yeah, just to add on the reactive systems, I think the structure that we've seen like the MQTT side of things, Jesse and I joke that we only use these devices every so often, but they keep working. I unplug them, I plug them back in. And so the reactive systems are sort of looking to leverage some of that same approach where the pieces are detached and decoupled and sort of the message broker is the piece that lets you glue it all together, but it's a very resilient approach and way that you can scale. And yeah, we see that Kafka is quickly becoming the choice there. So when you're thinking about your IoT systems today, it would be good to think about like, how are you gonna bridge that data into maybe a bigger Kafka backbone that's serving your enterprise applications as well. I think that's all the time that we have today. We hope you enjoyed this sort of whirlwind introduction to what IoT is, some example of what it looks like in terms of devices that you could build and experiment with, how you use MQTT with Node.js and how it's such a great fit because IoT is all around being asynchronous and asynchronous events and Node fits really nicely with that. And then we hope that you see that like, it's really, it's not that hard to get started to connect those devices in, get the data into your database as Jesse showed and then even leverage the larger cloud-based IoT systems or plugging into your more enterprise-oriented applications that might be using reactive approaches in Kafka. So thanks for watching and we hope you enjoy the rest of the conference.