 the hacked 2-year lights. Those lights actually can talk with the alternative firmware via MQTT. And we can use this to our advantage. And I will go into that a little bit in this talk and see how we can build on this. My name is Kresje. Some people call me Uth, or know me just as A, because they're lazy, probably. I've been tinkering for years with different stuff, and the normal day job involves industrial control systems. So it's a bit away from this, but still technical. Some people might know me from the Angry Nerd podcast. And I want to preface, I am not an expert on these subjects. But I think they're awesome. And that's why I want to share them with you today. We're going to see a buildup of three building blocks to create our entire system. And the first one will be MQTT itself. I mean, we've probably seen the term. But what does it stand for? It stands for nothing anymore. Originally, it was called MQTelemetry Transport when it was first developed by IBM. Now it's just the four letters and used like that. It's a Publish and Subscribe Network Transport mechanism. It shouldn't be called a protocol. I was corrected just after I finished the slide. So there is some protocol reference in there. It's a transport and not a protocol per se, as it's unaware of the data it is carrying. It's a system where you have one broker, one central server, where everything connects to just using one simple TCPIP port. So on a network, it's very easy to route and firewall. There are authentication and SSL support options. But I'm not using it in this demo because that would be too complicated and convoluted for this short time. Like I said, it was developed by IBM. And development started in 1999. It was an internal development for use in pipelines to communicate all the status information along the pipeline. It had to be lightweight. It had to use very little power, very little CPU power, and bandwidth. But it had to have some guarantees for data delivery. And there is a QoS built in in three levels will we come to later. And in 2010, which is quite a while after its initial release, version 3.1 was released royalty-free to the public. And that was when we first were introduced to it. And it has slowly been, well, it became part of the standard IoT and home automation suite, I think. In 2014, we had a little update with the 3.1.1 version. And that is the one we usually see supported in our devices and our libraries, if not the version 5 that was released in 2019. Version 4 does not exist, or at least it kind of does. Because in the header of the packet, they used version 4 when they were using 3.1.1. And that's why they skipped to version 5. So what happens? There is a client. And this client can publish into a topic. Another client or the same client can subscribe to a topic or several. And then the broker, which is the central server, will relay messages between clients. Every message in this system has at least a topic and a payload. And this payload can be anything. It could be a binary file. It could be text. And most commonly used is a text or JSON or just a number. So if we visualize that, we'll see. We have a broker in the middle. We have two clients. And if client 1 on the left publishes something to the topic room temperature, then the message gets sent to the broker and nothing happens. There is no subscription. And the message is lost forever. There is an exception, and we'll come to that later. But first, we'll need some clients to subscribe to the topic. And then if there is a publish on that same topic, the broker will relay the message and send the message to client 2, who now gets the updated value. This also works with multiple clients. And note that the client number 3 uses a different topic than clients 2 and 4. So if client 1 now sends the updated room temperature, only clients 2 and 4 will receive this message. The topics are the addresses of the messages in MQTT. And they're structured in hierarchy, a bit like a file system with a slash as a separator. In contrast to a file system, you don't start with the root with a separator. Just remember that when you build this for yourself. You can use wildcards in the topic names when subscribing, but only for a complete level or multiple levels. You cannot do character substitution. It's only for the whole part between the separator between the slashes. And they are case sensitive, although some firmwares will actually listen on both the full caps, the non caps, or the capitalized version of the same topic. Please don't put spaces in your topic names. That would be annoying. And no weird characters. Just use common ASCII, and you'll be fine. You could actually go and build a ginormous hierarchy for your house. You could also make it very simple and just say, OK, I want sensors. And I'll just number them 1 through 3, and so on. And later on, we'll be talking about TessMota. And there we'll see TessMota already provides a default way of topics. Earlier I said a message was lost forever if there was no subscription. But there was an asterisk. And the asterisk is a retained message. You can actually say, OK, I want this message to be remembered forever, or until I have a new message flagged as retained. And this message will actually survive a reboot of the broker. And if a new subscription is done to a topic, this message will immediately be sent to the client. But you don't know from when this message was. So it could be a week old. And the quality of service we mentioned in the beginning of the talk, the delivery guarantees. We have three levels. We have QoS0, which is like rate 0, nothing, because there is no guarantee. It just tries once. And if the client receives, it's sure. And if it doesn't, they're not. QoS1 requires an acknowledgement from the client. This could also mean that the message is sent three times. And then finally, the acknowledge comes through. And the client has received the same message three times. If that is a toggle for a light switch, this is annoying. So that's why you have QoS2, which will make sure that the client only receives this message once and once only. Last Will and Testament is a method where you can, while connecting, tell the broker, OK, if you lose connection with me, please inform others of my disappearance by sending this message to this topic. And that will enable you if, at the other end of the pipeline, original development, at the other end of the pipeline, the power is cut and the device disappears, but only transmits an update every five minutes. You don't have to wait five full minutes to notice it's gone. You get a response within a couple of seconds because of the keeper life to the broker not being updated. And then the broker notifies the rest of the world, I lost a client. Maybe you want to do something about that. So let's see if we can actually get this to work in a live demo. I did try to pray to the demo gods this morning. Pray with me. What we can do is simply look at a mosquito subscription command, which is make it slightly larger, is just subscribe to all the system topics that the broker already provides. The slash V in there is to actually get the topic names with them. So if I run this simple command, I get all my information from the broker. These are all retained messages because I immediately get some data. Normally you only get when there's an update, but these are retained. What we can also do is actually say, OK, I want the broker information, but only the number of messages sent in the last five minutes or the messages received in the last five minutes. And to demonstrate that, I'll type it correctly, the plus sign is the wild card for a single level. And as you can see at the bottom of the screen, which is a little bit, the received or sent differentiation is done in the second to last level of the topic. And I use the plus wild card to wild card out that single level. And I also have a retained message from last week, and I actually put it in last week so it now tells the truth. We can make it slightly more complicated, but more fun if we have a publish command. A publish command is also provided with, in this case, the mosquito browser to send messages. So if we start sending out some random data and then take another screen and subscribe to our test, we actually see some random numbers. We could also do this with, of course, a Python script because there are libraries available for many languages, including Python. And with just a few lines of Python, we can actually generate random numbers in another topic. In this case, it's PyRandom. And we'll see that in a later demo as well. And I'm running this as a live demo on, in this case, Raspberry Pi Zero in the little box on the desk here. And that's basically all you need. It could run on any OS. Linux is commonly used, but there are Windows implementations Mac OS. You can run it on very light hardware, like the Pi Zero I have over here. And this should not be anything you need to invest in to get started. So I hope you start tomorrow when you're back at home or after a tear down in a couple of days when you're back at home. And when you install Mosquito Broker, keep in mind that it usually defaults to only listening at local hosts. If you want to connect more devices to your broker, you need to add a listener in the config file to listen to all the devices. This is the first Google action you do after installing it because it doesn't work. And then you get to this. And I had to put in Allow Anonymous because I'm not running any security, which you should because there is already a slight vulnerability in there. But now you have the MQTT broker. You need something to connect to the broker. And that is where I usually use Tasmota, which is a universal firmware for ESP chips, like the one we saw in the two-year light in the previous presentation. And this enables you to control any ESP over MQTT via a web UI over HTTP get requests or even over a serial connection. And it already has support for many, many peripherals you could hook up to your ESP. It's very configurable, and although it started out for a smart relay, a sonoff relay, it is now a huge library for a lot of different devices. And you could probably have the ESP version of the two-year light in there with just a few clicks, which we will actually try and do. There are alternatives for this. You could use ESP Home or ESP Easy to get the same tasks done. In this case, we'll just go for Tasmota. And what you usually do is you flash it, you set up the Wi-Fi, and then you over the air configure and update your devices. So if it's stuck behind a wall or somewhere high up in the ceiling in a light fixture, no worries, as most things can be done over the air. And the easiest way to install is the new web installer using WebUSB, just like the badge that you probably have already tried. So if you have the correct browser for it that supports WebUSB, you can just plug it in, go to the website, and say Flash. It'll blink a few times, and then it'll take you through the Wi-Fi configuration. And then your physical device, and you're greeted with the standard Tasmota web UI. And from there is where the fun starts, because now we have a configuration button to actually configure our device. And this can be done with the templates for all the common devices that we already see. And in this template, you say, OK, I have this, for example, son of smart relay. And we define it has a button, it has a relay, and it has a status LED. And it's on these and these pins. The pins that are usually definable, which can be used by the user. And for the son of, there's a few pins actually, a few IOs broken out on pins on the inside. You put them as user. And then when the user has selected the template and goes into the module configuration, you see the pins that were user defined available to set up whatever you want. So if you would want to connect something extra to it, this is where you tap into. And of course, you have to also set up the MQTT broker. And one thing I always do is I set the telemetry period from five minutes down to 15 seconds, because otherwise I have to wait too long when I'm tinkering. I don't have any patience. But with this set of tools, we can build a lot of different setups. We can do things with power monitoring, environmental monitoring, lights with or without RGB. And we'll try if we can do this for real now. So what I have here is an ESP8266. It also works on the ESP32. But this is what I had laying around. And it's in this little box here. So it's just this ESP. And the configuration starts out empty. There's nothing in there. So I wanted something. I added a shield with a temperature and humidity sensor. And all I have to do to get the data is just say, OK, I'll go to pin. Let's see, configuration is over there. Module pin D4. I want my AM 2301 sensor. I click Save. Wait for it to reboot. Wait for it to reboot. And my temperature sensor is done. I can now put this on the field. And it's done. Thank you. If we look at the MQTT data, we actually see there is already a telemetry package coming down with the temperature of 22.8 degrees on stage. So this is how easy it is to get started with your project. And if we want anything more from this, we could simply add another thing like a button. I have a shield for a button. So let me just go back to the browser and click on configuration again. Add my button to the top pin button. This is button one. We actually have support for eight different buttons. So we could actually make a box with eight buttons, eight relays, or any configuration between those. Now we don't see much. We need to put something in there to actually show us the output. Let's add some RGB. I think that would be fitting. I do not have this exact shield, but I have a little RGB light in there. So if we go to the configuration to D7, I can put in an RGB LED or a whole strip of LEDs. You could actually have a couple of meters of LED strip connected up and make it do all kinds of rainbows. Once it's rebooted, we're actually greeted with a complete interface to turn on the LED, make it shine, make it different colors. I hope you can see it from the back of the room and on camera. But we have full control over our RGB LED now, just by a few clicks. And obviously, we can control this through MQTT as well. If we want to add more, this is actually the full setup that is in the little box on stage with me. I've added two more sensors, and I've added them using I squared C bus. So we just go back into the configuration, go into the module. And for pins two, we have the data. And here is the clock. Click Save. Go to the main menu. And now we have all the sensor data we want. I'm running in this of a power bank. I could now put this in the other tent. And through Wi-Fi, get all my data via the web interface or via the MQTT messages that come by every 15 seconds. There it is. We added the button. I can click the button over here. I can click the button on the web page for toggle, or I could send a message through MQTT. We see the MQTT messages. And they use topics and these topics. And now I have to find the slide again. There we go. The topics are defined by Tasmota per default with a prefix that tells you what kind of MQTT messages you'll be getting there and its own name, which is Tasmota underscore and the last part of the MAC address. You could change this into anything you want. And if it is not included in the firmware as you like it, you could actually build your own firmware because this is all open source now. You can send the commands through MQTT, through web interface, through get requests, through the serial console. You can string multiple commands together. And there are a lot of commands. I mean, I could make this slide 10 times bigger. You won't be able to read it, but please go to the documentation on Tasmota and you get the full list of the 150, 200 different commands. And we're not even touching on the scripting that is possible within Tasmota as well. There's also very nice information when you're using an ESP8266, which pins to not use because there's a couple that are high on boot or low on boot mandatory. So if you do that, if you connect a button to the wrong pin, it'll boot loop. But this enables you to get any smart socket, and with an ESP, and run this firmware. Maybe someone saw this on Twitter once. I've taken a BlitzWolf smart socket and added a temperature sensor, and that worked. But if we have measurements, if we have a smart socket, maybe with and build in temperature sensor or not, we have to make a decision. At some point, we want some part of our MQTT network of devices to make decisions and have effect on another part, on another device. And that is where we actually come to the last part, which is Node-RED. And Node-RED is an event-based system of nodes. And these nodes connected together create a flow. There are messages that go from node to node, and they have a payload and a topic, just like an MQTT message. It's not exactly MQTT, but it is close. There are nodes that come with Node-RED by default. There is a whole slew of more nodes available on the internet. They can be easily installed. And in this demo, we'll see, very short, but we'll see a little dashboard node as well, being installed separately. And version three was just released. The demo is still using a version two point something. I didn't want to risk it two days before the talk to upgrade. So nodes and flows, that looks like this. In this case, we have on the left a MQTT input node. This listens to a topic. So it subscribes to a topic just like we did in the first demo. And if a message is received, this will pass on the payload and the topic to the next node, which in this case is a switch node. It has one input and two outputs. And it'll check is the payload more or less than 50. And depending on that, I will set the payload from the value that came in to the word on or the word off. And if it's different than the previous time that a message was received, it'll go through the filter node up to the MQTT output node, which just does a publish on MQTT. And it actually sends it, in this case, to the power topic of this ESP. Like I said, flows are triggered because something happens at the beginning. So when this MQTT node here gets a message, it'll start going through the flow. But that means that only at that specific moment you have the payload available. What if I want to have a value from another device, from another MQTT message that came in just recently, and use that in a decision I want to make now? What you could do is use the flow or global variables to store some data. And you can do this with either a change node or a function node. In a function node, you can actually make your own JavaScript to create a complete program within one node. So I think we'll just have to look into it and try to get the demo gods to cooperate one last time. This is the Node Red Editor. And I'll just make this disappear with a little arrow. This is the flow we just saw with the addition of two nodes for the dashboard. So we have a MQTT node that connects to my local host broker and listens on PyRandom. We already saw the PyRandom because that is still running in the background spitting out numbers. And it passes on the number into this, well, if then, statement in the switch node. So higher than 50, output 1. Otherwise, output 2. We set the payload to either the word on or the word off. And we'll send it off to the power of this LED if I connect the last line over here and deploy my changes. Immediately, the light turns on because the current value is higher than 50. And if we want to see that in the dashboard, we'll actually have to, well, I'll just type it in. It's probably faster. We can go to the dashboard, and we actually see 61, 60, 61, which are the numbers we can also see over there. So now it is working. And if the randomness would help and go below 50 right now, which it probably doesn't, I'll just restart it and hope it'll get, well, obviously not. It's the demo, God. Yes, it's off. The light in front of me is now off. I hope you can all see it in the back as well. And if it actually goes up above 50 again, the light will turn on again. There it is. So that works. We can do different flows as well. Let's see if we can get over here. Yes. The flow variables that we mentioned earlier are available within this tab in the editor. A global variable is available on all the different flows, all the different tabs. But here I have another one. And what we have here is the same MQTT topic with the random numbers. And the only thing it does is setting the payload from the message to a local flow variable. So this is the mechanism to store the value for later use. I also plot it on the chart just to show you that if you want a fancy graph like this, it's very simple. You just drag in one node, give it a name or a title and tell it I want 10 minutes or I want an hour or 24 hours. And you instantly get a nice graph. If you want to use this information, we can have a function node retrieving the same data. You just call flow.get and the variable you stored earlier. And there's your data. This is a special node, which is also at the top of the available nodes on the left. And this node can be activated by pressing it. Or you can tell it at the bottom of the screen there. It says you can put it onto an interval, in this case, 21 seconds. So it just keeps repeating and repeating, triggering this single node. And what it could do is change the color of our LED friend on stage here. So what I did is I took the stored value, which is updated every 15 seconds. This injection node is running every 21 seconds. It gets the latest value it had and just calculates it, divides it by nine. So it would get a number between 1 and 12, which is compatible with the color command in TessMota. And that actually changes the color of my LED. There's also a green node over here, which is very handy. If you are making something new, it's the debug node. If you look in the sidebar on the right, we can have a debug window. And as soon as this is triggered, we get updates of the payload visible on the right. So you can immediately see what data goes where. If I was curious what the injection node was sending out, I could just drag a line from over here to my node, deploy it. And now I have full visibility over what is actually going from node to node. What we could do, what I don't have with me, but if you want to see this, find me later, we could actually have the result from the one ESP set a command on a different ESP. So I could turn on a light based on what this ESP is doing. And with that, I am through my demonstration. And it actually worked. Thank God. If you want to know more, thank you. If you want to know more, there's a lot of documentation available on the MQTT website, on the TessMota website, and on the Node Red website. I want to thank you for your attention. And I would love to see what you are going to make with this. And if you tag me on Twitter, I will definitely look at it and like it and retweet it, et cetera. And we have time for some questions. So please, if you have questions, come to these microphones in the middle. Also, I don't know if we have any messages over the internet. Nope, OK. Yeah, we'll take this question. Go ahead. Thank you very much for doing this speech. You are the one that taught me how to do MQTT. I was like expecting and talk about MQTT, but you did the whole shebang. And it was like an epic talk. Thank you very much, man. Thank you, thank you. Because this is the man who said, you should do this as a talk. Yeah, go ahead. Thanks. One question, if you have lots of devices, like 50 devices plus, would you advise to set up a separate wireless LAN, or will you congest my normal wireless LAN? Yeah, so setting up a separate AP might be a way. If you have an AP that supports different SSIDs on one access point, that would be ideal. Because then you don't pollute the airways, but you still have the separation. And you could run them all in a separate VLAN. And if you have your broker running on a machine that has access to that VLAN, you could just route the one port that you're using for your MQTT on there. OK, thanks. Thanks for a great presentation. Thank you. Is that I understand correctly? You have one broker running on your RS3 Pi and one Node-RED instance, right? Yeah. OK. Can you remotely access Node-RED instance as well? If you have access to the Pi, then you can. So it creates your own access to it, basically? Yeah. It is all run locally, so you are in full control. If you want to set it up to be accessed from outside, you could. I personally use this only on my local network, and I can VPN in on my local network. And that way is the easiest way to keep it safe. But this is all locally running, so there's no cloud involved. There's no 2.0 that has some infrastructure. Thanks. All right. Now, we have time for one more question if eBay has it. If not, let's give another round of applause for this presentation. Thank you.