 Good morning, everybody. Welcome to my talk. Thanks for coming. It's called Sensly, Office Automation with the Internet of Things and Python. I'm going to stand because this feels really awkward. There's a good crowd in here. I think there would have been an even bigger crowd had I put, like, deep learning in the title or something. It's hard to hear. I'll speak louder. Cool, thanks. So the goal of this talk is to discuss the results of a 24-hour hackathon that my team and I put together at my last company, namely in which we put together a wireless sensor network for detecting whether or not conference rooms were actually booked in real time or people were actually in these conference rooms. So there's a hardware component, a networking component, and a backend data component. And I'm going to speak, of course, that happens. I'm going to speak about the Python code that I wrote and my team wrote to put all of this together. So before I go any further, although I'm giving this talk, the results are due to my entire team, some of which are here today. So I want to thank them before I go any further. Who am I? My name is Luigi Petruno. I'm a data scientist or a software engineer, depending on the day and what needs to be done. I'm also an adjunct professor at Fordham University where I teach statistics. My background is in computer science and mathematics. The slides can be found online at my GitHub. And there's my LinkedIn, just in case you want to check me out. As a graduate student at Fordham, I studied application of machine learning to wireless sensor data. So I'm kind of going back to that field with this project. And part of the reason that I'm drawn to the internet of things in particular is the engineering challenges that are presented with each of the components. Because of the hardware and networking components and software together, it's kind of a fun challenge. So what is the internet of things? If you look at Wikipedia, it'll say that it's a network of physical devices that are embedded with sensors, software, and network connectivity that enable them to share, collect data, do an analysis on this data, and then make decisions. The sensors are able to sense within an environment and operate within a larger network. And there's an estimated 50 billion devices to be part of the internet of things by 2020. And this presents various challenges having to do with infrastructure scale. There are privacy concerns. And of course, the network challenge. Although the internet of things has picked up very recently in the news, and you hear it's a buzzword and you hear a lot of stuff about it, people have been talking about it for some time. And actually, there's a seminal paper in 1991 by Dr. Mark Weiser at Xerox Park. The paper is called The Computer of the 21st Century. And I really encourage you all to read it if you're interested in these things. And within this paper, there's a really profound quote, I think. And he says that the most profound technologies are the ones that disappear. So they become so embedded within your life that you don't even realize they're there. And how he introduces this with the technology of writing and reading. Previously, before the stuff existed, all of human knowledge was just contained within an oral tradition. And it was just after the stuff started being written down that we've been able to pass knowledge on. And we don't think about that anymore. You don't think about writing as a technology. But it's probably the biggest technology that's existed. And another fun part of this paper is he talks about how this technology is going to affect our lives. And in particular, he discusses it in terms of office life in the 21st century. And it's with this that I show you this picture. So who here works for a company that uses Google Calendar to manage booking conference rooms? All right, a few of you. If you do, then this photo might be rang true to you. This is the schedule for a particular day on one conference room. And as you can see, there is no availability whatsoever. I assure you there's nothing special about this room. There's nothing in there that might want to keep you there. This picture is the same for every conference room, at Namely. And Namely is a fast-growing company. They've quickly outgrown their office space. And due to recurring meetings, it's almost impossible to book a conference room the day of or a day before a meeting. A co-worker and I have actually been able to convince numerous newer employees that we're holding meetings within the office restrooms. And as an HR company, HR has frowned on me for saying these things. But so the idea my team had to conquer this challenge was, what if we put up some sensors within each of the conference rooms and try to detect whether or not people are actually within these rooms? The goal of this is, let's say there's a scheduled meeting that ends early and we can now actually use this conference room. Well, maybe we'll be able to detect that's available and be able to use it. Otherwise, let's say there was a meeting scheduled and no one actually showed up. Due to the Google interface that we're using, we don't actually know that. No one goes online and cancels their meeting, actually. So the meeting room stays booked and you're unable to use it. And this is the sort of architecture that we put together to conquer this challenge. And again, this happened in 24 hours. So the physical network is made up of this set of Node MCUs, which are these really, really cheap hardware units. And I actually have one right here. If you're in, I'll pass it around, so check it out. I'll talk a bit more about the Node MCU. But it's basically a small computer within a breadboard and you can connect different types of sensors. The network component actually uses the MQTT transfer protocol, which is a very, very lightweight transfer protocol on top of TCPIP. And basically, data is published to certain topics. And there's a Daemon Python process that runs in the background. Subscribes to this topic, collects this data, persists to Postgres. And then we set up both a Flask interface or a web application to this data. And we actually wrote up a Slack bot as well because we use Slack at Namely. So Slack would speak to Postgres, read some data for a particular room, and show whether or not someone was in the conference room. So I'll give a bit of background on the hardware component and then show you some Python code for both MQTT, Postgres, and Flask. So like I said, the Node MCU is the actual physical computer that we're using. It's an open source IoT platform that uses the Lua scripting language. Its Wi-Fi enabled supports MQTT and is extremely, extremely inexpensive. These units cost $10 each. And the sensors cost anywhere from $5 to $20 apiece. So we were actually able to hook up a small computer and three sensors in each conference room for the cost of about $20 to $25. And we hooked up 15 conference rooms for less than $300. So it's actually a very economical way of setting up a sensor network. And it's very, very easy to program these things. And it just makes prototyping extremely, extremely simple. So I've mentioned MQTT now about five times, and I haven't said what it is. MQTT is the messaging protocol that's used to transfer the sensor data from the physical devices to our Python back-end data service that's collecting and persisting this data. It's a public subscribe messaging protocol, which means that you need a message broker to transmit this data from some source to some sync. And there are several message brokers out there, and we decided to go with Mosquito. It's an open source implementation. It's really, really simple to use. And there's a Python client that we're going to look at some code for. So there's a lot of network protocols out there, and it's hard to talk about how relevant they are. But actually, MQTT is used both by Facebook and Amazon. I'm not sure if it's used any longer, but Facebook used it for Facebook Messenger, and Amazon uses it for its IoT platform. So this is actually a useful thing. So I've heard this from several people. There's been a lot of introduction and a lot of these talks. Just show me some Python code. So what I want to do now is change microphones. Can you hear me? So what I want to do now is show you guys some code. And I'm not actually using the sensors in this talk, but we're going to just publish some test messages to Mosquito and process them to Postgres and just display them in a very simple flask application. The goal of this is just to get you guys up and running if you want to start your own sensor network. So you can use this. And it's fully dockerized, so you can just take this docker image and run it on your own computer. You almost have to touch the microphone. Very good. So like I said, this application is fully dockerized. And I use Docker Compose to run multi-containers and link them together. So the first thing I want to do is just launch Mosquito and publish and subscribe to some topics and show you what the messages look like. So can you see this? So the first thing I'm going to do is just launch the Mosquito Broker. If you're wondering what these commands are, I just have aliases set up for Docker Compose and Docker Machine. So DCO stands for Docker Compose. So now I have the Mosquito Broker up and running. And if I open another terminal window, so what I'm doing here is connecting to the Docker container from my local machine and subscribing to the PyGotham topic. And if we navigate back over to the window, you see that there's a new connection from some IP address and some port. The port 1883 is the default port for Mosquito. And I'm connecting as Luigi sub. And that's actually the identifier I used right here. So if I open another window and publish a message, you'll be able to see that to the screen. So what I've done here is, again, I'm using the command Mosquito pub, which just publishes a message. I'm identifying myself as Luigi pub. And if I go here, you'll see there's a new connection from Luigi pub. I'm speaking to this host address, which is actually the IP address to my Docker machine. Again, I'm publishing to the PyGotham topic. That's the dash t flag. And dash m is for message. And I'm posting Hello World. And if we go to the terminal window where I'm subscribing to the PyGotham topic, you see Hello World pops up here. I can do the same thing and write some other message. And if we navigate back over, you'll see Hello PyGotham. So what's going on here is that the Mosquito message broker is up and running in my Docker machine. I've subscribed to a particular topic on my local machine. And I'm publishing a message to that topic, again, on my local machine. And we're communicating back and forth to the Docker container. So this is all nice and fun. But whereas Python, I still haven't shown you any Python. What I want to do now is basically show off the Python data collecting service, which will accept this data from Mosquito and persist it to a Postgres database. So this Python module right here, data collector.py, it's tasked with actually connecting to the Mosquito broker, accepting this data, and then doing something with it. So the first line here is I import paho.mqtt.client. And this is the Python library that is used to connect to Mosquito. There are some global configuration variables here, such as host, port, topic, client ID, username, and password. Again, the host is the IP address of my Docker machine. The port 1883 is the default port. I'm using the PyGotham topic. And I'm identifying myself as data collector. So if we actually look at the main method here, what I'm doing is instantiating a client object from the MQTT library. I'm setting a username and password. And these are just empty strings here, because I'm not authenticating really. And I'm registering two callback methods, an onConnect method and an onMessage method. And these are the methods that are called when first connecting to the Mosquito broker and when receiving data from the broker. I'm connecting. And I'm calling loopForever, which is a blocking call which just sits back and waits for messages to come on. If we look at the onConnect and onMessage Python methods, they're actually very, very simple. In onConnect, I'm just subscribing to a particular topic. And that topic, again, is PyGotham. And in the onMessage method, I'm receiving data, which is a UTF-8 encoded. And then I'm writing it to the database. And I'll show you the db.py. All I'm doing here is importing PsychoPG2, which is a Python adapter to Postgres. I'm connecting to it in the connection method here. I just passed the authentication variables. And I set auto commit to true. I returned that in the write record method here. And I just have some very, very simple SQL to insert just the raw data into Postgres. If you have any questions, you can ask me afterwards. So if we run this now. So if I publish the same message, go over to the database. And the message is there in the database. So we can do the same thing, write something else. Hello, PyGotham2. And what's going on is that Python is collecting this data and persisting it to the database. How much time? I have very little time left. I'll just show you the last component, which is just adding Flask. The Flask app is actually just really simple. I just basically want to display some data to the screen. We run that. And that data that we persisted to the database is just being recalled from the database and posted as JSON to a simple endpoint. And we can continue to post messages, and we'll see them. So if you want to know anything more about Flask, see the Miguel Greenberg tutorial online. You'll learn everything you want to learn. So in short, also we had a project manager on my team, Jordan, who took notes on the hackathon as it went on. And basically, our spirits were very high when we started. He took progress reports, and we basically worked in an agile manner with goals every hour. At 2 PM, we were filled with spirit. At 2 o'clock, we were maybe doing some things. And at 3 AM, one of us was asleep. I had drank three Red Bulls already. And there was much, much trouble until, luckily, at 10 AM, right before the hackathon ended, we were able to actually get the Flask application working. And the results were that we were actually able to see in real time whether or not people were in the room. So somehow it came together at the very end. And our team was able to win what we call the Sequoia Capital Moonshop Prize, where we're going out to dinner with some venture capitalists from Sequoia. So we've actually teamed up with a team of designers, at Namely, and are looking forward to putting out this mobile application, which looks much better than our Flask application did. And basically, you're able to, from your iOS device or Android device, see room availability, as well as other statistics like temperature, and the availability of certain equipment within conference rooms, like projectors and couches. So it's pretty cool. That's it. Thanks. Any questions? Yeah, it's using Flask in the back end. No, so we actually, due to this very, very short time, we have putting this entire thing together, we used a very, very simple model. We had a motion sensor. So basically, if there was any movement within the past minute or two, we said that somebody was in the room. And given more time, we would like to make the model much more robust, obviously. But we're able to use that. We're showing that data in some data visualizations, so you're able to still access it. Yeah, so we talked about shaming people that way. What the Slackbot currently does is just, if you send in, like, backslash, sense, Kent. Kent is one of the names of our meeting rooms. It just returns the data from that room for the past several minutes. It was being used when we first started, yeah. Yeah, we teamed up with some, none of us are designers, and the design of our first application was pretty funny. So we got together with some of the designers at Namely to start designing a mobile application. It's not out yet, though. Those are just mock-ups. No, it's just within the organization. Yeah, there's a few more minutes left. So I actually didn't work on the hardware aspects of it. Our co-worker, Attila, was like the hardware smee. And he went with these devices primarily because of the simplicity, and it's pretty cheap. Now, no data is stored on the device. It's just actually pushed to Mosquito over MQTT, and Python is in charge of collecting and persisting to Postgres. So we were actually, within the first several hours, we were persisting. We persisted like 600,000 rows of data. So Postgres is going to be a bottleneck rather soon. But we just wanted to get something up and running that we were comfortable with. I think there's one more minute. No, my name is Luigi. That's fine. Thanks a lot, guys.