Parker talks with Brandon Satrom of Particle about the future of IoT and then design and prototype an IoT device.
John Adams joins Parker and Stephen to discuss IoT Security, Crappy IoT Devices, and WS2812B LEDs.
Stephen learns that MIDI tutorials that are online only cover the basics and Parker has haunting vias.
FB: @ubidots
Twitter: @ubidots
Visit our Slack Channel and join the conversation in between episodes!
Parker is an Electrical Engineer with backgrounds in Embedded System Design and Digital Signal Processing. He got his start in 2005 by hacking Nintendo consoles into portable gaming units. The following year he designed and produced an Atari 2600 video mod to allow the Atari to display a crisp, RF fuzz free picture on newer TVs. Over a thousand Atari video mods where produced by Parker from 2006 to 2011 and the mod is still made by other enthusiasts in the Atari community.
In 2006, Parker enrolled at The University of Texas at Austin as a Petroleum Engineer. After realizing electronics was his passion he switched majors in 2007 to Electrical and Computer Engineering. Following his previous background in making the Atari 2600 video mod, Parker decided to take more board layout classes and circuit design classes. Other areas of study include robotics, microcontroller theory and design, FPGA development with VHDL and Verilog, and image and signal processing with DSPs. In 2010, Parker won a Ti sponsored Launchpad programming and design contest that was held by the IEEE CS chapter at the University. Parker graduated with a BS in Electrical and Computer Engineering in the Spring of 2012.
In the Summer of 2012, Parker was hired on as an Electrical Engineer at Dynamic Perception to design and prototype new electronic products. Here, Parker learned about full product development cycles and honed his board layout skills. Seeing the difficulties in managing operations and FCC/CE compliance testing, Parker thought there had to be a better way for small electronic companies to get their product out in customer's hands.
Parker also runs the blog, longhornengineer.com, where he posts his personal projects, technical guides, and appnotes about board layout design and components.
Stephen Kraig began his electronics career by building musical oriented circuits in 2003. Stephen is an avid guitar player and, in his down time, manufactures audio electronics including guitar amplifiers, pedals, and pro audio gear. Stephen graduated with a BS in Electrical Engineering from Texas A&M University.
Special thanks to whixr over at Tymkrs for the intro and outro!
Hey everybody, welcome to the Mac fab engineering podcast where your guests Cameron,
and I will see from movies.
And we're your hosts, Steven Craig and Parker Dolman. This is episode number 97. So Augustine is an electrical engineer from Up B. F h, Munster, he helped engineer a remote monitoring solution for Airbus Germany. Afterwards, he founded the IoT application enablement platform movie.com.
And then Cameron joined UI dots as the Director of Operations. He graduated from UC Berkeley. And he has previously worked in operations and project management at get around Inc. and UBS financial services, while also focusing on efficient team and client dynamics and quality assurance.
So for those of us who have been longtime listeners, I know I've been a longtime listener of the podcast, we have actually talked about Ooby done in the past. So I was working on a project, the i spindle, this, gosh, how many episodes probably 1012 episodes ago, we talked like that. So and in the in working on this project, I kind of myself got introduced to be dots because of the documentation that went along with this project. And so we talked about that on the podcast. And lo and behold, somehow the UIA that's guys caught wind that we talked about it, and they ended up contacting us. And I believe Cameron contacted us, is that right?
Yeah, exactly. Right. So I was actually listening and on your guys's podcast a little while back. And then I heard our name and the discussion of boom, lots and I couldn't resist. I had to send an email. You guys are just too funny.
Well, somebody we have one listener, thank you camera
Believe it or not, I'm here for you guys.
Oh, that's so So yeah, that was that was kind of cool. So we talked about we dots on that podcast. And and the blue dots guys here, contacted us and said, Hey, you guys want to do a podcast and talk about IoT and talk about data and talk about how you get data into the cloud. So we said Yeah, sure. That sounds great. So fun. Yeah. Thanks for coming on, guys.
Absolutely. Thank you very much for having us.
So let's talk about movie dots. What is it?
Yeah, for sure. So movie dots itself is a point and click IoT application builder for data storage, data analytics, and data visualization. We focus on transforming sensor and actuator data and applications to provide valuable insights to make better business decisions for engineers or management. Our focus is to work with the system integrators and hardware engineers like yourselves to cut down the development time and the overall project costs. To help deploy devices into the field. Our focus is really to work with hundreds of engineers in the sweet spot between about five and 1000 devices to help deploy POCs and help quickly get connected solutions up and online so that we can actually start extracting value instead of just talking about deploying solutions. We believe that actually getting the products out in the field is the most efficient way to deploy IoT solutions.
So what's the difference between the UI dots platform and other platforms that are out there?
For sure, so UI dot itself really focuses on that longtail solution. So we like to make sure that we stick between the five and 1000 devices for first projects. And then with that, we help foster the growth of the project and the engineers that are helped deploying them. So for example, if you might be doing a humidity sensor, and a wind containing unit, you might be losing the whiner know, the vineyard might be losing wine to minimal humidity standards. And what we can do is we can help work with the engineers to get three or four devices immediately deployed in that location. So the vineyard itself can see whether or not that value is is helpful. If they enjoy it, then all of a sudden, you can deploy another 10 or another 20 devices because they want to build build out the application. Gotcha. Gotcha. That's our sweet spot. And that's how we do it best. Yeah.
So it's basically you provide kind of a, a service in terms of they can test drive. The service basically, is that is that my understanding? Exactly?
That's exactly right. And not only do we, we don't just stop there. So once we get that test drive done, that typically is in a two or three month period. We also we also support the actual development and the deployment aspects because we have built in features that allow for scaling up to 10s of 1000s of devices.
Quick note to that, guys. Yeah, so I think where our users have recognized that, you know, stands out from the rest of the platforms is the fact that we give them complete application layer for the LTE solution means we other platforms might be very good at inserting the data or allowing you to manage your devices remotely by turning them on or off, or doing like some control around them. But we actually ran that last mile, where we actually created something that could be put in front of the end customer. So if you're a hardware engineer, or you have an idea in mind, or you have the customer just want to build a solution that's in the middle, we get you to the end user. So we do a lot you can deploy a ready to use portal that can help you make you and your customer make sense of the sensor data of your deployment.
Right, right. I noticed in using it myself that you guys spent a lot of time working on the aesthetics, making sure that it, it looked a particular way, and certainly looked nice.
Cool. Yeah, thank you very much for that. I know that our our UX engineers are really focused on that. And one thing that we focus on is, and I hope you experienced it yourself is that ease of use, being able to use UI dots? It's a software and you guys know your hardware guys, not always do you know, what an API, the end. And the front end should look like. So leave that part to us, we'll take care of it. And we'll provide that service as best we can.
So speaking of that, I guess we'll go right into our next segment is like, what is or how do you get started in IoT? And then I guess the start with that is, you know, step back even farther, and it's like, what actually is IoT? Like, from a base level? What is it?
For sure, I can take that one. So we view IoT as a four pronged process, each one being a layer. First first layer is going to be the device, the actual hardware. So if you're using a PLC and Arduino, anything that you guys have built, the second layer being the connection protocol, how you're actually connecting to the Internet, whether or not you're plugging through Ethernet, you're using a cellular connection, or you're using a new advancing technologies like MCAT. One. What's MCAT? One? Augustine, I'll let you carry that on. Or if you want to see. That one gets a little bit more intense.
I've never heard of that,
either. Yeah, I mean, there's this exciting, new new types of trends that are coming into IoT. So for connectivity has covered with saying, in fact, we recently made a survey within our user base. And we found Wi Fi and Ethernet cellular to be like the top three types of connectivity, which makes a lot of sense, because it's what all of us are used to. But then there's a new wave of connectivities, that will enable applications that were impossible before, like, for example, if you had, let's say, you had a business, refrigeration, and you had 100,000 refrigerators on the fields, maybe put in a cellular device in each one of these refrigerators would be too expensive, compared to the amount of data or the value that you would extract from these data. So your customer,
your customer had to pay like 30 bucks a month for that cellular service
Exactly. Like only the data alone would kill the project. So lucky for all of us, there are a lot of players trying to push down that barrier of not only the cost per month of the data plan, but also the battery consumptions and the size of the little chips that communicate with the Internet. So this next wave of things of connectivity types is the Sigfox is one, Laura, one is another one, and then the next generation, let's say 2018, and so forth, will be cut M one, which is an optimized mobile connectivity type. That is a specific specifically designed for IoT.
Okay, so who's who runs that network then? Is it a network?
Yeah, it isn't a network. It's been planned out and deployed by current mobile operators. So some of them are going for narrowband IoT, which is kind of a competitor in the space. It's mostly NB IoT, narrowband IoT is closer to Europe. Cap M is been pushed by mostly in America. So yeah, let's see. I mean, we're eager to see what happens in that space. It's going to be exciting for all of us.
Yeah, that sounds I'm gonna have to, you know, look up more of it when after this.
Yeah, so the Cat M one and NB IoT are gonna be back ended by the major telecommunications providers. So they're viewing that as the potential solutions, and three, four or five years down the line. So they're looking to build out that technology as much as much as possible, in the hopes that it might take over the current cellular capabilities.
Gotcha. Alright, so back to, we're talking about number two is connection. So what's number three?
Yep. Yep, quick recap. So we start with a device, then we're connected, then once we're connected, we've got to have it somewhere to send the data. So that's where the cloud comes in. And once the data is in the cloud, it can be stored, computed, analyze, visualize everything. And in order to be able to visualize and take it from the cloud to the actual end users, so that you're getting a copy of communication from machine to human, that that machine to human interface is going to be either your cell phone or your laptop with UI dots. And that last aspect is the is the final aspect of the four layers. And that's the application development. That's what we'll be nots comes in. And we use that point and click environment that you guys have already experienced, in order to build widgets, visualize data, create computations of your data, VR rolling windows. So we view those as the four four layers of IoT. Any any questions in there? Aside from the connectivity?
I think I think that's good.
Well, here's actually one point that I'm a little bit curious on, and maybe I should know this, maybe I don't maybe you guys know this better. But like, what actually makes an IoT device? Or I guess, what makes something constitute an IoT device? Like, when does the device stop being a device and become IoT?
You mean, because technically a computer would be? It's connected to the internet? And
it's and it sends data? And it does all the things that an IoT devices? So like, what is it that makes it that?
Cool? Let me address that. So there's a much broader definition for IoT. I mean, there's a lot of definitions, right? Okay. There's one that I particularly like, and it's it's described as the convergence between the digital and the physical. So the moment that computing went out of our screens, so if you look at all of the computing thus far, from the 70s, until very recently, most computing is about So for programs running at a computer screen or a mobile screen. With IoT, I think the big, big difference is, we're embedding computing into objects, we want to make them smart. So I would say like, if you have an embedded design, that is not a mobile device doesn't have a screen doesn't have, you know, the typical ons like Android or iOS or, or the desktop operating system. So I think that's the moment where the computing goes out of the screen. So I like the definition of IoT, it's making objects is bringing computing into almost everything. And that everything, of course, is objects on randomness to make them smart. What do you want to make this smart for? Well, that's what we're here to talk about. But that's kind of the destination that I would be more inclined to.
Okay, that's, that's pretty good. Yeah. It's
interesting, because sort of with that definition, I mean, I assume that, you know, in the future things will gel a little bit more, because it seems like if it's not a computer, but it has some kind of smarts in it, then it constitutes IoT in a way. But I suppose it has to connect digitally and send data across a network, in addition to that, but I don't know.
Yeah, that makes sense.
Okay, so
API's? Oh, yeah. So I was about to say is on, you got. The first is the device two is, you know, actually talking wirelessly or wired to the internet. And three is getting data to the cloud, which would, you would have to use a, you know, a protocol to talk to a server. And I want to guess that's what an API is in terms of IoT, correct? Absolutely. Me myself, I made myself sound really dumb, because I know what an API is an
API API. Well, okay, well, I'll be the dumb one here. I actually have no idea what an API is. I mean, I know it's, it's a string of characters that you copy and you put into your firmware, and then it can talk. That's an API. Okay, yet see this? This is, this is the extent of my knowledge here. So please, enlighten if anyone enlighten me on what an API is cool.
Yeah. Well, you know, before I define this, I'm also a hardware guy. So any definition I'm going to give you So if there are any software developers listening to this was like, Okay, excuse me, I missed something. Or if I'm oversimplifying it, I'm just gonna go straight to say what I understand what API he's said he didn't know up until, you know, five years ago, we begin with you be done. So, an API, let's talk first about the how the internet works, like, not the internet of things, but the internet of people. So if I'm, as a user, when I go to website, and I type in the address, I go, like HTTP, blah, blah, blah. So what the browser is actually doing, it's, it's going through the server, and it's asking the server, the server, please give me this chunk of data. Right? Now, the server replies with a very long file or text of what is the HTML, and then the browser just takes that HTML, and then translate it into pretty UI, so that you know what the website is about. So the devices are not very different. I mean, with devices, use a device, you also request data from a server. And then, you know, this data is relayed back to you. But it's not an HTML format. It's a much simpler format. Because you know, you can imagine, if you had a 32 bit microcontroller, trying to parse out the data from Google, it would be a lot of data to parse. So IoT optimized API's, what they do is that they put the data in a much simpler format, so that the device can understand it. Now, of course, I'm zooming in into what HTTP is, this is what most API's talk, it's HTTP, is a protocol that runs most of the web today. And it is no coincidence that most IoT API's also raw HTTP, even though it was not optimized for microcontrollers. So it without for example, we support HTTP out of the box. So if you want to query let's say, your you have a sensor that is measuring temperature, you want to know the last value of the temperature, then your device would go into our API, make GET requests, just as if it were a web browser, and then get the data back. If you want to create data, then you wouldn't use what what is called a GET requests, you would use that post POST request pizza POC. So what a post request means is you create something, so you make a post request to an API, it will create a New Value Indicator up dots, he will create a value. Let's say you would be a bad opponent of a temperature for example. So that is like a fair comparison between current web API's and IoT API's to support HTTP. But there are more protocols that are more optimized for IoT, if you want to dig into that. Yeah, that Yeah. Cool. So yeah, so I mean, HTTP is just
sorry, there was some lag there. Okay.
So, as I was saying, acbp, became sort of a standard for most IoT API's. But it was really, because all of the web was run on HTTP. But it's not the most efficient thing for microcontrollers. So to give you a comparison, HTTP runs on top on top of TCP, TCP is a transport control protocol. It's in its most basic form, a client being a device or tablet or desktop, they open a connection, let's call it that like a tunnel, they open a tunnel with a server. And then they agree on how to exchange that data. And now one of those that remains to exchange data through a TCP tunnel is HTTP, but it could be anything else. So if we go one notch down to the basic form of TCP handshake between the client and the server, it's about 20 bytes from wireless, if you use HTTP is is at least 200 bytes. So you know you are sacrificing the amount of data to use or data optimization For a standardization, so we see a lot of users that choose to go down the TCP route. So instead of doing a whole HTTP request, they just use our TCP broker because we also have our TCP API. And it really lowers down the cost of data packets, for example, and the processing cost, of course. So, you know, if you're a hardware engineer out there, and you're planning to do a deployment, there are a lot of things to weigh as to which protocol tissues, but if data consumption is one of them, then I would recommend just using plain TCP packets, and then of course, fewer to encrypt these. And if you want to do something more elaborate, and, of course, you know, choose different protocols. Now, there's something called MQ TT, it's a very popular protocol for IoT. It's great for controlling purposes. So the problem with older protocols was, let's say, I want to open a valve remotely to fill in a tank, for example, in this valve, in order to get the command from the cloud, it would have to be asking what we in the system engineering, what we call calling, you know, so the valve would have to be polling, let's say every second, asking the server, can I open now? Can I open? How can I help him? So with HTTP, that's very inefficient. So there's another protocol, and TTT, which allows you to, or allows the valve to sort of leave that tunnel open, and then only get like a push notification or a message to open the valve when it's required. So instead of asking a second, can I open the valve now, he will just stand still, and have an open connection with the server. And then only when the server worshiped, he would send it the control instruction down to the device, so that it does say the control process. So yeah, there you have it, like three of the most popular use protocols on it, or at least the most, the ones that we see being used the most in actividades.
Gotcha. I never heard of the MQ TT. That sounds pretty cool. It sounds like more of a it's like a push notification kind of setup. Exactly.
Yeah. That was it was optimized for that. Among other things. It was optimized on that. And it by the way, it also runs on TCP. It's like a layer up. TCP. Gotcha. Yep.
Yep. All right. So we're gonna start even farther down the rabbit hole, I guess, here. So let's say we're gonna start from the hardware perspective from Steven. So I'm putting words in his mouth right now. So he's got an arm, okay, no. Okay. And then, let's say it's got a temper. So we'll use the example Augustine was using, which is the temperature sensor. Okay. So it's got a temperature sensor on it, and it controls a valve. Okay, what's going to be the way he control that with? Let's say it would be dots. And his I think, let's say the web interface, okay, cool. So that he can say, if the temperatures up, you know, goes to a certain number, he can do something about it, and then make a valve opens and basically requests back down to the Arduino device. So we'll assume that there we know has like, connectivity, I guess, to the internet, because he can just go download like a library that does that. He's shaking his head, right. That's exactly what I would do. So what would be the first step? Okay.
So, first of all, I would see which board you have. There's a lot of doing news out in the market. Around the Arduino. There's a bunch of them. So I would see, you know,
so what, what Arduino Did you all see the most being used?
For Wi Fi, we see the ESP 3266. Like, okay,
so how about we just go with that? What does
it do with that? We have an ESP. ESP comes with a very nice package called node MCU. So that already ships you know, it's a box. You can plug it to your computer, and then the Arduino interface will recognize it. So let's play with that. So with that particular filmer, what I will do is first I will do a program to send data so no control Yep, just send data to the cloud. You could do you could either use a unidos library for the NodeMCU we already exists. Or if you're a more advanced user, you can just look for existing libraries of HTTP or nzdT. That are there for. So where can people particular device?
Where can people get so that you'll have it on your website? So
yeah, if you're using up those library, you can go to help that up.com Type in the device you have. And it will pop up, like all the available articles that we have for you. We have over 150 articles describing how to integrate different types of hardware. And we have all of them in our lab. So if you have any questions, just, you know, shoot us an email to productivity doesn't come and you know, we'd have a one of our hardware engineers take a look. So yeah, the first thing I would do is to try to use, like out of the box library. If you're more interested in learning how it works, you know, on the backstage, I would actually look for an existing library, let's say, I mean, I'm sure they're in Qt libraries through there's one called boop soup, I think it's a GitHub, and it's the SUV. Like publish subscribe. So that type of libraries that were already developed by somebody in the hardware community, and what they do is they have structure all of this complicated protocols that I just described, into very easy to use, you know, code, or lines of code. So if you take, if you have that, plus an API, documentation of up loads of, or whatever cloud service, you shouldn't be able to make it work. So that will be my first step, my first recommendation would be just to go to your device, see the manufacturers, if it has a library, try to connect it to to be dots on send data,
I guess we need to get a I guess you need to, you know, get an account and get an API key and give that feed that into copy paste that into your devices. You're
exactly, yeah. So you would open an account, it would give you the token key, you can extract this from from your profile view. Once you have a token, you put this into your filmer. We have a bunch of examples, by the way that you can find in our Help Center. And that would allow you to, you know, go online and see the device data in the cloud. Yeah, gotcha that that would be sort of that my first recommendation is to more than sending data straight up does is understanding the protocol behind like, we see a lot of, let's say, support tickets of people that, let's say they buy a device, plug it in, it doesn't work. And honestly, like we're not a hardware company, we just try to do our best to integrate with a bunch of hardware companies. But most like oftentimes, what we see is that they didn't digest the concept of what HTTP request is, or an N Qt T request is depending on what they want to use. So my first recommendation would be just try to understand the concept, and what the payload looks like, what a token is. And by the way, we explained all of these in our onboarding process of the platform. And that would be like a huge takeaway normally for for using humidors. But for doing any IoT projects. So that would be my first recommendation. And then once you have the data in the cloud, in the middle, you can set alerts. So what you just mentioned about you know, if the temperature goes above a threshold, or below the threshold, and you must choose the threshold, and then the triggers, which means are the actions which means what do you do after a trigger is met could be either send an email, send an SMS, send another HTTP request to somewhere else, or you can set a variable. So you can, you can trigger you can set that up those variable to for example, let's say either one or zero. And then you should have a logic in your device that says if the variable that says, let's say, temperature or not temperature is input, but let's say the output would be the ACS system. So I'm going to turn on my, yeah. So I would, I would put AC to one or two, zero, depending on the value of interpret two. And then your device, you had to be reading this AC variable to see if it's one or zero. And if it's one, then you make you make a logic to control that AC in your device. So that that's on a very high level. That's how it would look like.
Alright, cool. So, so we got the connection up to the server, right? And using the Ruby library or a library that talks in HTTP, or TCP, basically, because that's how you will use the API to talk up. So it's in the platform, I guess, you use the the web portal to basically design your app, correct? Yeah,
that's exactly right. And I'm happy to fill in that answer. So once you have an account, Adobe dot, you can just jump online where there's two different platforms, either the educational platform where you can use one device up to 10 variables for free. And then our business platform where that's obviously considerably more robust. Once you're logged into the platform, you can then just use the point and click environment. So with your device that has the firmware uploaded to it, as Augustine has already described, the first time you send it.as, what we refer to as a single message, that temperature reading that gets that creates a device on the platform, and you'll be able to see it, adjust its name, adjust its identifier. And then from there, you can create a dashboard. And within that dashboard, you can click graphs with creating widgets, visuals across any number of predetermined widgets that will be available. And then beyond that, you can also create the event center. And then Augustine was just discussing you guys were looking to do and so the events engine, you can send emails, web books, to SMS messages, and telegrams. So all you have to do is just click in and say, I would like to create an event, I would like the event to take the Arduino ESP 8266 device, I would like to read the temperature. And anytime that the temperature exceeds 90 degrees, I'd like to be sent an SMS alert, that SMS alert might go to a manager, it could come to me it could come to you guys, whoever you guys want. further beyond that, you can also send a web hook so that web hook might communicate with another machine. Or it might be bi directional, where you're sending a message back to a control that says turn on a flow meter because the temperature is increased or turn off a flow meter because the temperature is increased. So you have all of these things predetermined within the platform. And it's all available through a point and click, it's just up to the end user to determine what the application is going to do. Gotcha.
Right. So it all boiled down. It's kind of just a, a bunch of different fancy ways to display the data, or to act on the data.
You're exactly right. So the goal of that is to be able to allow end users to extract value at their own capabilities. So you might be you might deploy two or three, temperature and humidity sensors, but you didn't have to hire an engineer to come through it or, or as an engineer, you didn't have to charge $15,000 to deploy this solution. And instead, you can charge $150. And then for the software side movie, not just gets a small cut of that you engineer being able to take all of that value add, we only provide
no see what you do. So what you do is you charge to $15,000
so that we can get some more engineers, if we can get some more engineers that are going to be deploying $15,000 solutions, and it's only two or three devices. Bring it on, we want more.
Well, that's great. So yeah, so I obviously with the I spindle project that I worked on a couple weeks ago. So you know, I got introduced into OB dots with that project. And really, the way that the documentation worked for that project is it basically tells you how to connect the dots. But after that, it really doesn't tell you much on how to use the b.so. I was kind of left in the dark there. But what I personally found was that I was able to just get on there and it was like, Oh, if I want a graph, just click graph, and then it asked what variable you want. Well, I want the variable from my first device and bam, it's there. So I found that to be really nice, and to be really I'm not trying to like sell, it'd be gush over this, but I'm just being honest. It was very nice. It was very cool.
I hope our engineers get to hear that because I know they focus a lot on that UX. Making it really simple is a big focus of ours. Because as you guys
will And you know, it's it's kind of funny because like I this there's a lot of different ways to display any variable on that and and I found it kind of fun to do different different things for different variables like my the battery voltage for my eye spindles, there's still running right now I set them up as gauges, I guess it could be a graph, I guess it could just be a list of data or what Yeah, but I set it up as a gauge, just like it looks like a fuel gauge for how much voltage is left on the batteries. That's kind of cool to be able to look at that way. Yeah,
and and that that value for you as an engineer means that you can deploy the solution, the Iseman of solution, if you have you're working with a small brewery or something like that. They just want to see what their information looks like. But it's up to you as the integrated deploy all the beautiful capabilities. And it's just how the end user wants to see it. If they're better off with a number, they're better off with a range of the gauge, give it to them. Who are we to say no, come on.
Right, right, right. So I'm curious about what are the export capabilities from movie dots. So obviously, you can go to log into your account and see all the data. But what if I want to use it in a different way outside of the Uber platform, what options to add? Yeah, so
we have two great options for that one option is going to be with the API, we can then control third parties. So if you want to apply like an analytics engine, or you want to apply some API from outside that movie dots world, you can go ahead and overlay that data and you can send push and get requests to either send data out or pull data in from outside sources. And then in addition to that, we also for our business users do support CVS downloads, so you can download all your data, either from an individual device or from a larger grouping of devices or, or an entire organization of devices, each one of those downloads can then just be exported into Excel. And if you're trying to run some computations off the platform, you can go ahead and do so no problem. We support that and we endorse it.
So if you don't want to use the fancy graphs in the browser, you can use the France.
If you like we can overlays, or we can overlay some really fancy graphs and browsers through another API, it just depends on how the client wants to build their IoT solution. There's so many Well, I guess,
I guess what I'm thinking of is maybe a little bit more of a of a traditional, like, you're an engineer at whatever at ad company.co. And you have to give a presentation to the CEO, you know, and he wants to know the status of all of the sensors out in the field, like, what's an easy way that you can throw it up on a PowerPoint and show him some graphs? Yeah,
exactly. So either you can show you can log in with your username and just shown that ob das display, or if you download the CVS, and you want to put that into Excel, you can just have it be a standard Excel format, and deploy that over PowerPoint, so he can see it. He just grabbed the graph and drop it in simple.
So that's that's actually a way to just screenshot it. MSP
screenshot is always a go to for presentations
did like, yeah, that just Yeah, it's right on the slide there. So actually, so I have I have a question that comes, maybe this counts as customer support. Yeah, fire away. So curious about. So I was playing around with some of the data on my account. And one of the things that either it's not available, or I don't know how to do it. What what I what I did originally with my spindles was I did a whole test batch of some really nasty beer. And I ended up throwing that whole test batch away. And I wanted to restart the test. But I already had all of this data backed up from the first test of the i spindles I wanted to restart. So effectively, what I wanted to do was erased all the data that was currently on all of my devices. And I wanted to start fresh. But I didn't see an option to do that. The way I got around it was I just deleted all my devices and created four new devices. And I was able to start fresh from a zero point. But I just wanted to throw away all the old data. Now I know you're you can go in and delete individual data points, but I had 1000s of data. Yes. So is there a way to like group Delete?
Yeah, there is and so that that's recently been made available that's just on the per device level. So one way to do it is to delete the whole device and the first time that device is sends a message again, it self populates a new path. So the one way you did it the way you did it is one quick and easy way to start from scratch. The other way is instead of deleting each individual option within the within the variable, you can also do go into the variable, excuse me, not the Variable View go into the actual device and from a drop down in the center of the screen. You can select each option and a time period that you want to get rid of and there it goes.
Ah, that's fantastic. Okay, that's that's exactly what I was looking for.
I guess you don't want the data from your old beer?
Well, it just so it didn't mean anything to me that that old because it was a failed experiment. And there was all kinds of bad stuff in there. I just wanted to start fresh, where my first data point was the beginning of my experiment. And I didn't figure out how to do it. So I just did the quick and dirty way of just creating a whole brand new device. The only problem with creating a whole brand new device is that I then had to go and recreate all the other graphs that tied to that device. Exactly. So that's why I was wondering if I could just pour out a chunk of
data, you absolutely cannot. And we'll have to create better information to get that word out. And then what I would like also stress is our support system is really, really fantastic. We focus a lot on a 24 hour rule. So if anybody writes in to our in app chat channel, we got a little tiny little blue.in, the bottom right corner of the web applications, if you click on that, you can always type in a question. And our support team will get back to anybody within about 24 hours or less.
Cool. So I have one more question.
It's your guys's job to fire my fire Armada. So whatever you got, shoot,
and actually, this is gonna be question for everyone. So Steven, why answer and I'll answer to it's How do y'all view the term Internet of Things? Because it means a lot of things, a lot of different people. And it has a lot of bad connotations and good connotations with it.
Why don't we just go around the circle? August, I'll let you lead off.
Well done well done.
writing my notes. Cool. Yeah. So I guess, above all, like IOT is a concept, you know, in a lot of different settings, it has tried to be seen as a trend as a solution. But technology has always been about problems solution. So it doesn't matter if your solution is IoT, or is or if it's blockchain or AI. Like it doesn't really matter how you call it as long as as if it's a solution. So for me, IoT is only a concept is only a definition to describe what we talked about earlier, you know, what is IoT and what is not. So it's just a concept to stick to the definition. But at the end, what really matters is that technology has always been a problem solution. So you have a problem, you just find a solution. It doesn't matter if it's connected, if it's not connected, if it's AI, whatever. It's just problem solution solving. That's what really matters.
Yeah, and I'd like to piggyback on that, from my answers, I think it's pretty accurate. To me, IoT is simply a buzzword. It's a way that our millennial generation, and the generations that are going to come after us are being able to understand the current technological wave. And that's being able to produce edge and cloud based solutions, getting hardware to connect to systems, and then having that hardware create solutions, as Augustine was saying. So IoT is simply a phrase that gets thrown around on the internet, and that these massive conferences, but IoT solutions are actually being purchased. So if I say we're going to deploy an IoT solution, nobody cares. But if I say we're going to deploy ru monitoring solution that does temperature, humidity, pressure, and then from that we can better monitor our h max systems, all of a sudden, that's a solution and IoT falls to the wayside. It's a solution. So I view IoT is just kind of a gateway or a portal into finding a solution. And we do that through technology.
Right, Steven? I think IoT is like you, like you said, Kevin AI a buzzword. It's something that exists today. Because the idea and the concept hasn't fully coalesced into what it will be. I think it's a term that represents what the future of electronics will be as more and more things connect the internet and become more interconnected. And as that becomes more of our everyday life, I think just IoT is sort of like the proto word for what that will actually become.
So I guess since I'm fourth, the I think of more of a, instead of the devices I think even more of like its data management and analytics, is what IoT really is. Like, you can buy a refrigerator that's got a TV on it, and people are like, I have an IoT fridge. I'm rich, it doesn't actually click not at least not yet. Next day, it might, you know, collect how often you use the ice machine and water and say you need drink eight cups of water a day.
Yeah, but so does my doctor and my mom, it's an IoT device. Yes. Does that mean does that make my candidate because she tells me I need to drink more water all the time.
And she probably has a huge network
as long as she's doing data management and analytics on your drinking habits,
the Internet of mine,
I'm sure that she has an opinion on my drinking habits, but we'll leave her to make those say her opinion.
That's, uh, that's how I do it as it's, it's using data and analytics to improve whatever or make better whatever you doing. So, sure, okay. Yeah. But it's, it's not really just that in analytics, it's being able to collect it in a single spot, like in the cloud. The cloud, which is it's a server. That's that's what it
is. It's a server that you don't have to plug into.
Exactly. Yeah. So that's, that's my view. I guess. So cool. I would agree with you all on it being. You don't remember what
you like, that's a good synopsis of the World of Internet of Things. I feel like it's all you know, yeah.
Yeah. That might that might be a new idea for us. Yeah.
So I guess in the Cameron, where can people find out more about Ooby? Dots, not y'all, etc.
Yeah, so the best way to do it is just to go check out our website will be test.com. We're also pretty active on social media through Facebook, Twitter, and LinkedIn. And then always, if you have a question, just shoot us an email at either support@uber.com or sales adobe.com. And somebody will get back to you. We're very, very, we take that very seriously. And if we don't have clients that talked to, we don't have a business, so anybody that chats with us, we like to chat with them too. Cool. Awesome.
So thank you, Augustine and Cameron, for being on our show.
Well, that was five, focus. I mean, we are your guests. Actually. I will say it in camera.
Ed, we were your host, Stephen Craig and Parker Dolman. Thanks a lot guys. Take it easy. Later.
John Adams joins Parker and Stephen to discuss IoT Security, Crappy IoT Devices, and WS2812B LEDs.
Stephen learns that MIDI tutorials that are online only cover the basics and Parker has haunting vias.
Parker talks with Brandon Satrom of Particle about the future of IoT and then design and prototype an IoT device.