Deploying Your IoT Projects with Scalable Services (and Cloud APIs!)

Speaker: Rob Lauer - Director of Developer Relations 00:06

Hi everybody. Looks like we're about ready to get rolling here. I hope you're all having a great day so far and are locked in for the next 45-ish minutes or so as we talk about what happens when you deploy an IoT project. And yes, what that means in terms of scaling. Now, scaling is a really fun word to throw around, because we all like to think of that hockey stick diagram of a project taking off. Sometimes that is true, yes. But sometimes for some of us, scaling just means going from one prototype device to five, or five to a hundred, or it can mean a hundred to one million. When we do demos and workshops, and webinars like this, we commonly just quickly show off what happens when I take one microcontroller and hook it up to one Notecard and demonstrate how data can be quickly delivered over cellular to some remote Cloud Endpoint. Don't get me wrong, that's pretty awesome and engaging. However, in the back of our minds, we should be asking questions about, you know, things like how does my cloud platform scale? How do I programmatically access device data? Maybe you want to feed an internal legacy system, for instance? Or how do I manage fleets of devices and firmware updates at scale?

These are all really important questions and I don't know if we're going to fully address all of them today, because they are all really big questions, but at least we can touch on the ideas and hopefully inspire you to learn more. With that, I want to do a quick introduction for our speakers. First up for me—my name is Rob Lauer and I'm the Developer Relations Lead here at Blues Wireless. I'll be your emcee and kind of show off a demo or two here in a bit. With me today is TJ Van Toll. TJ is our principal developer advocate here at Blues. We are super happy to have with us today Beray Bentesen, who is the CEO of Qubitro. Now if you haven't heard of Qubitro yet, I think you'll be pleasantly surprised with what you see in their IoT active platform. Now for some quick logistics before we continue, if and when you have any questions for our speakers today, please type those into that Q&A panel you are provided—I believe to your right in the GoToWebinar interface—actually, it's this way, so I don't know which way your video is pointing to. We will of course be answering questions for individuals as they come in during the webinar. Please stick around for the end, and we'll get the speakers on and do some live Q&A for the entire audience.

Likewise, if you run into any audio or video glitches, or maybe you just lose connectivity altogether, please know that we will have a full recording of this webinar available in about a day or two on YouTube. Watch your email for a link to the recording. We will include some additional resources as well, and yes, maybe even a discount code in there. Speaking of YouTube, I can't stress enough how you need to lose yourself in some of our awesome video content. I mean, really, our own Gabe Sanchez is doing some fantastic Blues Wireless infomercials that are super entertaining. Take a minute later today to check it out. While you're there, I’d like to shamelessly ask that you subscribe to our channel. That definitely helps with our visibility in YouTube land, and hey, it alerts you to the new videos we post as well. Okay with those logistics behind us, let's start with what the heck Blues Wireless even is. If you've been to one of our recent webinars, you know that I kind of like to level set everyone and make sure that all attendees— whether you are brand new to Blues Wireless and don't know anything about us all the way through to one of our seasoned veteran developers—have a high level understanding of what we are up to.

If you've heard this intro before, again, feel free to tune out for the next two-ish minutes; I'll be as quick as I can. For the rest of you, let me start by stating that the core mission of Blues Wireless is really to make Wireless IoT easy for developers and affordable for all. Our focus really is on securing data from the moment it's acquired by a sensor all the way through to landing on your Cloud Endpoint. All of our hardware solutions are low power out of the box to the tune of about eight micro amps when idle. We're also very much a developer-focused company. Our developer experience is a top priority, if not the top priority, hence our elegant and easy-to-use JSON-based APIs. Quickly zooming into the hardware that we offer: The Notecard is the core of what we provide. It is a low-power cellular and GPS module measuring a tiny 30 by 35 millimeters. It does have that M.2 edge connector at the bottom for embedding in your project. As I mentioned, the API, the way you interact with the Notecard is all JSON, so gone are the days of those archaic AT modem commands to manage your cellular module.

We also have SDKs, Notecard SDKs for Python, Go, Arduino, C or C++, and there are Notecard varieties that work literally globally using the NB-IoT, LTE-M, Cat-1 cellular standards. Now to make it easier to use your Notecard when you are prototyping, or even when you're ready to embed any more permanent solution, we provide Notecarriers. Now, these are development boards that allow you to snap in a Notecard and connect it to virtually any solution you can dream up.

For instance, the Notecarrier AF, which is what I'll be using today. It includes a Feather-compatible socket with some onboard antennas. The A-model line includes headers that let you hook it up to any microcontroller you want. It also has some onboard antennas. The B is a small form factor Notecarrier, and the Notecarrier Pi is a Pi HAT for working with any Raspberry Pi compatible single-board computer. Finally, how do you get your data to the cloud? Well, Notehub is a thin Blues Wireless cloud service that receives data from the Notecard, and in turn securely routes it to your cloud application of choice. Also, within Notehub, you can manage fleets of devices, and you can update both host microcontroller and Notecard firmware over the air, which is an important topic for our conversation today. Notehub is again all about securely transmitting data, both from the Notecard to your cloud and vice versa.

That means secure as in data is transferred off the public internet via private VPN tunnels between Notecard and Notehub. To help you visualize at a high level where Blues Wireless fits into your current IoT solution, let's start with our sensors. You're generating some machine learning inferences, you're acquiring data like temperature, humidity, your pressure, or motion, whatever it may be, and this data is likely then being processed by a microcontroller or single-board computer, right? But you need to get that data to your cloud. See, then you’ll be using the Blues Wireless Notecard to securely deliver data over cellular to our thin cloud service Notehub, which then lets you route that data to your cloud of choice. Notehub takes a lot of the pain out of that secure transmission of data. Notehub even optionally optimizes those data payloads and conforms to whatever data structures your remote endpoint is anticipating.

Again, you can route data to any of the big cloud or IoT platforms out there, or even your own custom RESTful endpoint, and all of this is accessible via a developer-friendly JSON-based API. Everything you see is JSON in and JSON out. This applies whether you are in Arduino or Python, or even just experimenting with your Notecard using our web-based REPL at dev.blues.io. As a final quick, relatively simple example of what I just covered, let's say you have a DHT11 temperature and humidity sensor, kind of as basic as it gets here, you want to use the Notecard to send this data to your Cloud Endpoint. Well, Notecard is going to send that sensor data to Notehub along with some metadata about the request, like timestamps, and the cell tower location, and so on. You may not need or even want that data to end up on your cloud, so Notehub will optimize your data payload per your requirements, and send just the data elements that you want onto your cloud. That's Blues in like, two or three minutes or so. Today, of course, we're talking about scaling these IoT deployments with Blues and Qubitro.

I'm going to allow Beray to speak to his perspective of what value Qubitro provides. For me, one of the reasons we invited them to present with us today is because of how easily we were able to go from using and deploying one device to multiple devices on their platform. I think you'll see this play out to a certain extent today. More on Qubitro a little bit later on, but first, we're going to start with the weather.

Speaker: Rob 08:55

What do I mean by this? Well, TJ and I have decided to start up our own fictitious weather station device company. Since we live in slightly different geographic regions, we have multiple devices right now that are in the prototype phase, in multiple places, gathering sensor data like the obvious temperature, humidity, barometric pressure, and location. Now it's a classic and yes, slightly contrived, example of gathering data from disparate points.

However, what's key for us today is scaling. While we can and will show off routing this data to the cloud, we're also going to touch on how to take advantage of some notable features to scale our deployments. Since TJ and I do live in Wisconsin and Michigan, respectively, this unfortunately means we have to root against each other on a regular basis, which depending on the sport can be fun or painful for either of us. Since we do live across this giant lake from each other, we do have multiple devices rigged up with Notecards, securely relaying our accumulated weather data on a continuing basis to a common Cloud Endpoint, Qubitro. We're at a point with this company where we need to ask ourselves what happens when we scale? What happens when we move from a single or a handful of testing devices to multiple devices sharing a single dashboard? How do I programmatically pull event and sensor data to feed some internal system of ours?

How do I perform bulk firmware updates without recalling devices from the field? How do I securely route all this data to my cloud provider? It's a lot of questions to answer. Well, we're going to start at the beginning with the not-so-secret sauce. TJ and I are still getting up and running with our company—we are admittedly still in prototype mode, so that means I've got a couple of devices here, as does TJ, sending device data to the cloud or sensor data to the cloud on a regular basis. Now I'm using the Swan microcontroller here. It's our own microcontroller from Blues Wireless. The Swan is a Feather-compatible board that fits perfectly into our Notecarrier AF, which, if you recall, is effectively a bridge for Feather-compatible microcontrollers to use the Notecard. In this example, I'm using the Notecard  NBGL model, which is a global narrowband Notecard, and it is the default Notecard that we send to all of you in our starter kits.

In terms of sensors, I'm keeping it relatively simple with the BME 280 environmental sensor that helps me to measure temperature, humidity, and pressure. But what about location? Well, since the Notecard also has GPS capabilities baked in, we can pull in the location of our weather stations with GPS data from the Notecard. The cool thing, though, is if that's not available, if, for instance, the Notecard is buried deep inside a house or in my basement office as it were, getting a GPS satellite fixed can be very difficult. What's awesome is if GPS is not available, we can actually fall back on the nearest cell tower location to at least give us a rough idea of where we are at.

Speaker: Rob 12:06

That's enough slides for me, what I'd like to do is take you on a tour through our Notehub project so you can get a sense of some of the features that Notehub provides to help us scale up this project.

Alright, so what you're seeing here is our Notehub project for our weather station deployment. Now by default, we're popped into this devices pane here, which is going to give me a list of all the devices associated with this project. Now, I could spend an hour talking about all the individual features of Notehub.io. However, I want to focus on some of the scaling features. While I could dive into the details of individual devices, maybe what I'd want to do first—the first feature I want to show off here is the capability of updating both Notecard and host firmware. You can imagine a scenario where there is a feature update bug fix whatever it may be in the Notecard firmware or in your host microcontroller firmware, and you want to get that deployed as quickly as possible to 100 devices that you have here in Notehub. What I can do, simply by selecting all the devices here and clicking the Update button, I can then pick a Notecard firmware version. You can see we've got 2.1.1 that was just released a couple of weeks ago, this is our first LTS release, actually, and we can update firmware from here in a matter of clicks.

It's crazy how useful this functionality might be. Now, same again goes for host microcontroller firmware, and I highly recommend reading our guides on dev.blues.io for upgrading host firmware as well. We can tap into the SIM usage capabilities here, and we can see how much data has been transferred for all these devices. Now, fleets are another giant component of scaling. Of course, we can talk about best practices for fleets, we'd ideally want maybe an operational fleet, a decommissioned fleet, maybe a new fleet, or  maybe you want to triage devices as they're kind of onboarded in your system, before you deem them worthy of getting into the operational fleet. There's a lot of different ways to manage fleets. I'm not going to do any of the management here in the UI, because I want to save that for the API demo here in a second.

I am going to pop over to the events tab. Now, this is a, you could say it's a vomited list of all of the data coming from our Notecards, which can get very overwhelming very quickly when you start to scale. Now, in the UI here, there's a capability of filtering by a variety of different parameters. Say for instance, I just want to see the weather data coming in from our devices. I can just pass in the name of the Notefile. This is the collection of events or notes that have been sent to Notehub from our devices. You can see here, I can dive into a particular device and see all of the data that was sent, and we can see here the weather data that was sent for this individual device. We can get fancier with our filters, and we can say, well, I just want to see data for one specific device and we can filter that way.

You can put a bunch of filters together here. Maybe you want to filter by a date range as well, and you can save that as a favorite. That helps when you're starting to put together the right filter to see a certain amount of data, it helps to save you some time there in terms of saving that search as a favorite. Now, of course, routes are arguably the most powerful feature of Notehub, but I want to save that for TJ’s demo. I'm gonna skip over to Settings quick, just because I want to show the first of all kind of this table stakes, there is nothing like mind blowing here, but there is the capability of adding one or more members to a project. You may want to collaborate with one or more folks, so we can add them as project owners or developers are just viewers. There's role-based privileges involved with our member allocation here. Now, more importantly, I want to show off our environment variables. Now this, to me, is up there with routes in terms of the most key features of Notehub.

Now, what are environment variables? At their core, they are simply key value pairs that are stored in the cloud. What I can do, for example, is I could save a key value pair of temp data minutes, which I'm using to represent how often my Notecards are going to gather temperature data. In this case, it's just an arbitrary string. In this case, I’m sending it to gather data every five minutes. Now, what if we’ve deployed this project to 10, 20, 30 devices, maybe 1,000 devices, and we realize, oh, you know what, we're gathering data way too quickly, we don't need temperature data to be gathered every five minutes. Well, provided I've set things up in my project correctly, I can simply change this to 60 minutes and save it here. And the next time our Notecard syncs with Notehub, it'll grab these updated environment variables, and then use them in the project. Now you can imagine that you can do some amazing things with environment variables in terms of, you know, changing application functionality, changing how often and when the Notecard syncs data with the cloud. I mean, you can, really, the options are endless when it comes to these key value pairs. Now, what's really cool about these environment variables is they can be set on a project, fleet, or device basis. Think about when we have a fleet of non-operational devices, and we want to just tweak some settings on those devices, maybe there’s a command we can override to make them operational again, right. We want to limit the number of times they’re sinking because their batteries have gotten too low, or something like that. There's really endless capabilities that you have with these environment variables, so the Notehub UI is very powerful and we're investing a lot into Notehub going forward. At the same time, though, it's really important to know that virtually everything you see in the Notehub UI, everything I just demonstrated is also available via APIs.

Speaker: Rob 18:20

Now this is really a key message or even the key message I wanted to get across. Because UIs sometimes don't really scale. What I mean by that is, clicking through individual devices can be very useful, like if you're debugging a specific device, for instance. But when you need to perform bulk operations, or set up a process that runs every hour, you need an API to programmatically access that data, or even manage devices or pull devices in and out of fleets automatically, and so on. What I'd like to do is show off some of the Notehub APIs as well. Now all of our APIs are fully documented on our developer portal at dev.blues.io, and access to the APIs is secured via an authentication token; you can set that up after you create your Notehub account for free. But notice the big scary warning here, just so you know, this method of authentication that I'm going to show today will eventually be replaced by an OAuth-based solution in 2022. It's just a heads up that the method I show you today will have a new and improved option next year. Let me switch back over to my desktop for the API demo.

All right, so recall that virtually everything that I showed off in the Notehub UI is capable of being replicated in the Notehub APIs for when we're scaling in a more automated process. Now, I've already gone through the process of creating my authentication token for all these requests. Don't worry, I know I'm going to expose my token here, but I'm going to go ahead and delete this account that I'm using afterwards, so I'm not sharing anything too sensitive here. I am going to send my first command with a curl request. That is going to be to the devices endpoint, which we can see right here. This is simply going to provide all of the devices associated with this project, and what we get back is all JSON. I realize it’s not super legible in my terminal here, but this is an array of devices, and if we want to look into the details here, I can probably, if I'm lucky, find the endpoint here.

I think it's maybe right here. Yeah, or not the endpoint, but the end of my curly brackets, this is a single device that is associated with this project. Now, maybe I want to just grab information about a specific device. Well, to do that, there's an API to do. So let me clear my terminal here and paste this in. Again, this will just give me back the information for one specific device. There's information about the cell tower in here, the location, and the all-important, unique identifier for the device as well. Maybe we have a problem device; maybe I've determined that this device is a problem, well we have the capability of disabling an individual device, which I just did. Let's see what happened here, you can see this from a more visual perspective. Sure enough, that device is a problem. I disabled it and it turns all red in our UI, maybe I want to re-enable that device. Let me copy and paste that command in here, and that is just simply enable endpoint, and then I’ll head back here and reload. Sure enough, we're all good again.

Now we get into the more interesting management or viewing of data, and that has to do with the event APIs. Now, we're always going to recommend that the best way, the easiest way, for you to efficiently route data from your device to an endpoint is using our routes functionality. But if you need for any reason to query device data, there are a variety of event APIs to use. This one, this endpoint I'm using here, which is called latest is going to pull in all the most recent events for the entire project. Now this gets more interesting though when we use the get events by project API. Now, I'm not going to show this off, because it's almost too powerful to show off in one or two examples. What we can do is we can query our events API by project of course, but then we can limit it based on the page size.

How many events do we want to return? We can use this “since” parameter to show devices through a value from a previous call, we can separate it based on one or more device UIDs, we can sort the data, we can limit it based on start and end date. Again, there's some APIs in here; I highly recommend you consult dev.blues.io in more detail to get an idea of what you can accomplish with the event APIs as well. Other things I can do, let me head back here, I'm going to create a fleet. Let's create an operational fleet here. This is the fleet’s endpoint, and I've got an operational label. We're going to create that fleet and head over to our fleets tab to make sure that that showed up just fine. Really quickly, I just want to show off a variety of these APIs. Again, there's just a crazy amount that you can do with the Notehub APIs, and you can combine that functionality with the UIs provided in Notehub.io, to really, fully manage and scale up your project. That's enough of me talking. What I'd really like to do is hand things over to TJ, to have him show off some of the routing capabilities of Notehub to Qubitro.

Speaker: TJ Van Toll - Principal Developer Advocate - Blues Wireless  23:59

Awesome, and all right, Rob gave us a great start by showing us how to scale your projects using Notehub. Now, what I want to do is build on top of that and show you how to use Notehub routes. Now routes are our way of taking your Notehub data and securely routing that data to a provider of your choice. Now, that provider can be something like one of the big clouds like AWS, Azure, or Google Cloud; it can be an IoT platform like our friends Qubitro that you're going to be hearing from here in a minute. Or it could be something like your own custom HTTP-based endpoint that you could route to and then do whatever you want with your data from there. Regardless, though, I think this is one of those things that it's a lot easier to understand if you see it in action. Let's switch over to my development environment so I can show you how Notehub routes work. All right. What you're seeing here is my browser, and I have the same Notehub project open that Rob was showing earlier, and I'm going to head to the route section. Here, I'm going to add a route, which is basically just a place for Notehub to send data to when it retrieves it.

You can see that I have several different options for routing, again, some of the bigger clouds have protocols like MQTT. But to start and to learn how this all works, let's go with a simple HTTP request route. A basic HTTP route is your most flexible routing option, because you can forward your data pretty much anywhere. But for this demo, I'm going to use a handy little service called webhook.site. This is a utility you might find useful, even for non-IoT projects, really at its basic level, it just gives you an endpoint that you can send data to and verify things are working as you expect. To use it, all you need to do is go to webhook.site, and it generates this little ID for you. You can copy this URL, which I'm going to do, as this is where we want to send data. Back in Notehub, I'm going to paste that URL here as the place we want to route to. We're going to give this a name; we’ll just call this webhook.site. And you can see there are a bunch of additional things that you can configure about a route: You can set extra HTTP headers if your service requires it, or if you require it. You can rate limit, which is handy if you're using something that can only accept so many requests per second. You can scope routes to specific types of fleets. If you're dividing your Notecards into fleets as Rob showed, you can create routes that operate on only one of them or whatever combination you have in mind. Finally, you can transform your data using JSONata, which allows you to perform simple JSON transformations on your data before you route it to your external service. If you're curious how this works, you can click this link because actually, I think this is kind of fascinating and very powerful.

On our dev.blues.io site, we have a documentation page, so if you really just go to dev.blues.io and search JSONata, you can find some of the things you can do. But really, it's just a powerful little syntax that can let you take JSON and transform it into different forms, which can help you comply to a data structure that some service that you're sending your data to needs. But again, today, we're keeping things as simple as possible. So with these defaults in place, let's just go ahead and create our route. All right, now to test this, we need to create some events, because the basic flow is Notehub receives an event from something like a Notecard. When it does, it checks whether any routes that you've defined here need to apply, and if so, it routes that data accordingly. To create some events—and I'll turn my camera back on here for a second—I've got my Raspberry Pi hooked up here with a Notecard, and I've got a BME 280 temperature and humidity sensor hooked up here as well.

Going back to my desktop, I have this window open here where I've SSH into my Pi. I've got a little script here, don't worry too much about the contents of it, but it uses this BME280 to grab some temperature and humidity, basically weather data from this device, and it's going to send it up to Notehub. I'll go ahead and start that up now. Let's get this data and see the weather conditions in my office here and start pumping that up to Notehub. With my device sending data, I can go back into Notehub and go to the events section, where I'm indeed seeing my data coming in here on the top. What I can do is if I click on an event, you'll see that there's also this Route Log tab, and this is going to show me all the routes that Notehub used to send your data through, which in this case is going to be the webhook route that we just set up.

Notehub says the response was successful, so let's head back to the webhook site. You'll see that in fact, the data has made it through successfully, and several of them have, I configured this to send every 15 seconds or so. You're seeing the data come through into Notehub and then get routed into webhook successfully. Visibility can be quite powerful when it comes to scaling your apps, because it puts you in complete control of your data and allows you to build really anything you want with that data: something like a dashboard and a web or a mobile app, or maybe some sort of alerting system that sends notifications when sensor values go too high or too low, or really anything else you can dream up. The good news is if you don't want to build an entire system like that yourself from scratch, there are a lot of really high-quality solutions out there that can automate away some of that hassle for you. There are a lot of potential services that you might want to use, but today we have our friends at Qubitro on the call. As a next step, let's look at how to send our project data to Qubitro, and then I'll turn the webinar over to Beray, who can take things from there on the Qubitro end. All right, so in Qubitro, as with a lot of platforms, the easiest way to send your data over is just through an HTTP endpoint. In the case of Qubitro, according to their documentation, they provide an endpoint here, which I'll go ahead and copy because we'll need that in a second. They also want two different HTTP headers, which they list down here. To actually wire things up, what we'll do is we'll head back to Notehub. I'm going to head back to the routes section, and we're going to create a new route, so they provide an HTTP endpoint. We'll just go with a general endpoint here. We'll call this Qubitro. I'm going to paste in that URL we grabbed earlier. Remember, that Qubitro wanted two headers, which I'm going to go ahead and copy and paste from my notes here, because you don't want to see me type all of this out live.

I've got my project ID and also the signing key as well. With that, pretty sure we're good to leave all the rest of these at their default values, so I'll go ahead and create that route. What's cool is that as soon as this route gets created, Notehub will start using it immediately. I don't have to take any other actions. So, my Pi, we will check in on it here, it looks like it's still sending data every 15 seconds, so that means I should have some new events. If I go into one of these events and go to the route log, you'll see that that data was indeed routed to both webhook and Qubitro successfully. You can wire up multiple routes, as you can see here, which is kind of cool too, because it allows you to sort of experiment with different providers at the same time, which can be kind of fun and handy for this sort of thing, and the data is going to Qubitro.

I'm going to turn things over to Beray here in a minute; he's going to talk to you about Qubitro in detail. For now, I just want to head into their portal and just quickly show you that the data made it over from my event. If I go into this weather station project, you'll see that one of my devices—Rob and I both have been playing with this—one of my devices was last updated a few seconds ago. Qubitro here just gives me a nice way of viewing data about the, in this case, the Notecard itself. Then also the custom data that I'm sending in, you can see that the temperature and humidity and such is coming in as well. Qubitro also allows you to make fun little dashboards, so I built this one to show off the data that's coming from both Rob and myself as we've been prototyping this little weather station app that we've been building over the last handful of days. Overall routing gives you a lot of power when working with IoT data, whether you want to build up your own cloud infrastructure around that data or route it to one of the big clouds or work with some IoT platforms that are out there, or some mix of all of these things. As a next step, I promised you you'd be hearing from Beray. I want to hand things over to him so he can tell you a bit more about what the Qubitro platform can do to help you out.

Speaker: Beray Bentesen - Founder and CEO - Qubitro 33:47

Hi, everyone. My name is Beray, and I'm the founder of Qubitro. Today I will be covering how to transfer sensor data to cloud platforms, which is Qubitro in this case, and more importantly, how to build dashboards and how to scale these projects as devices are edited or created. On top of that, I will be quickly covering how to access all the device information and device data through RESTful APIs. I’m switching back to the Qubitro portal, where our users can easily monitor their device values and sensor values, and more importantly, they can choose sensor values from different projects. This is a simple experience in most platforms or scenarios: You need to define dashboards specifically for projects. In this case, let’s say you have different cards or devices from different projects so you can easily choose any project, and on top of that, you can also easily choose devices, and then the rest is as simple as just clicking a few buttons and playing with the values so it will be good to go. This is an example dashboard that we prepared from several devices; these devices are connected through MQTT.

These devices are also integrated from The Things Network as well as Notehub for this demonstration. The idea is that you can easily visualize all these values no matter where they are coming from on our dashboard, so this covers the simple monitoring or building a simple dashboard for your IoT devices. Of course, you can customize as you wish. This is just a simple feature, but the idea is scalability. In our case, you don't need to create dashboards for different projects, and you don't need to specifically define templates. It just works. That's the idea. Let's talk more about integrations because more importantly, every project starts with a simple single device. Then of course, the idea is adding more and more devices on top of that. The question is, how is your application going to scale in terms of both experience and infrastructure performance? To integrate Qubitro, we try the simple way. We let our users easily integrate with third-party platforms like Notehub or The Things Network. All users need to do is just copy a single webhook signing key and the project ID. Then they just need to jump to the Notehub user interface and paste the credentials. Why is this so important, why do we try it this way, and how is this related to scalability? It's related with scalability, because I can start with a single Notecard from Blues Wireless. Let's say my scenario is working well, my sensors are up and running. I see the first data on Qubitro and then I want to add more and more devices. In real-life use cases, there are startups and companies that just start with a single device, and then they add more and more devices. Usually, you need to provide different credentials for each device, or you need to configure templates or update templates. Even though there are some solutions, they still require customization. But through this partnership and integration, we were able to offer synchronizing not just for the sensor values, but also for the device information with Qubitro. You activate this route from Notehub up to Qubitro by just providing the project ID and the webhook signing key. We want to enter the project ID because on Qubitro you add your devices to the project. So I’m going back to the Qubitro portal and clicking on Notehub integration. I have one device—actually, this device is located in the United States, in the home of my teammate, so he's publishing some data.

Once I save the route from Notehub to Qubitro, the device appears here automatically. Whether you have one or 100 devices, it doesn't matter. We synchronize the information. You can of course customize your device: simple things like device photo, device name, and device brand. Let me actually jump to the settings. As you see, you can customize everything because you might have different ports or different sensors, and you might need a reminder, like device name. It's all up to you. We just provide simple reminders like Notehub integration, and we choose Custom for brand and model name, because we may not know that. You get everything here. As you see, this is a specific overview for Notehub devices. This is board temperature. This is the voltage RSSI and the sync signal strength as well as the location of the device. These appear automatically right after you start publishing data or building the connection to Qubitro. Then more importantly, sensor values.

This device actually publishes humidity and temperature, for example. And you don't need to configure these keys or values manually. You don't need to build templates. You may also publish different sensor values here from different Notehub devices. It will appear here automatically, you can query time, you can download—it’s all up to you. Then, of course, you can create device-specific charts. If your case includes a few devices, you may want to build specific charts for a low number of devices. If your projects don't need charts for each device, you might need something else, which is another topic of today: APIs. Once we introduced our platform and saw the interaction from developers, we noticed that it was not possible to scale user experience—in this case, developer experience—just through Qubitro Portal or any user interface, because we offer what we do through feedback, but your scenario might need something different. The good news is that Qubitro can be used as an infrastructure for your projects—let's say infrastructure as a service. What I mean is that I have connected devices to MQTT and devices from Notehub and additional different devices, for example, to The Things Network. As you see, I can easily see this scene and other values as well. So going back to the topic, let's say you want to build your own solution, and you are going to add devices continuously. This means that you're going to produce tons of data. IoT use cases mostly produce time series data, so they need to be scaled well. You want to automate this stuff, because you have your devices and sensors and values, and you may want to get this information without touching the user interface. In fact, you just need to touch one single thing: the API key. In this case, you need your API key to work with Qubitro APIs. Why are APIs important? I'm jumping to the APIs. We believe that we can enable developers to build use cases however they like and whatever they like, which could be a mobile application that shows some device sensor values or any other information. There might be a startup that wants to sell solutions using IoT devices. I just pasted my—let's get that again—I'm pasting just my API key here.

As you see, I have project ID and device ID, and I want to get temperature and humidity, the last two values, but I can get any values, for sure. The idea here is we let our users do these actions, take these actions and build products without knowing anything about cloud infrastructure, databases, or scalability, because this involves security and scaling databases, scaling your costs, scaling your backend performance, but more importantly, experience. We just didn't develop REST APIs. We also spent some time on the experience. You can easily get your projects set up through this API call; you can also get an update in your project about your devices or a single device. In fact, you can also get your device data keys—let's say you want to automate some stuff, and you don't know the sensor value coming from devices, so you can also get the information. These are ready for production, and we also provide other documentation specifically designed for Qubitro APIs. You can easily follow and play on the playground without even installing any library on your computer. We wanted to make it that simple. We also offer documentation for hardware developers, where you can easily follow integrations for Notehub, for example, or MQTT. These are the simple reasons for us to build these APIs, because we saw that while there are solutions, they must be focused on user interface. We really believe that it's going to be more like automation and accessing everything through API calls so that you can with your custom solutions, so this is how Qubitro works. On top of this, we believe that we scale well because we spend so much time on actual cloud infrastructure, so you don't need to.

You can connect thousands of devices, as you'll see on my user interface, and you still get the benefits of the scalability, performance, long-term storage, short-term storage, or the other way, hot and cold storage. But we simply remove all those terminologies so you don’t need to know anything. All you need is just to connect working devices. With Notehub integration, you can easily update your devices through Notehub—we call that publisher’s data at Qubitro—for example. You can also easily access your device information and device data, and no matter how frequently you're publishing those data to Qubitro, we don't count the data rate. We don't have limitations for that. We just have different plans for your needs. This is Qubitro, and this is why scalability is important when building IoT solutions. Integration with Notehub and Qubitro proves very solid and very easy to use, but more importantly, it is a scalable experience for both Notehub users and Qubitro users. That's all from me. Thank you for listening, and I'm going back to Rob. Thank you.

Speaker: Rob  46:29

Well, that was great. Thanks, TJ and Beray. Before we turn it over to questions, I did want to mention that about a month or so ago we released our own Feather-compatible microcontroller called the Swan. I used it for my portion of the demo today. The Swan is actually the most extensible Feather-compatible microcontroller available when you pair it with the Swan carrier board. You see here in the bottom corner: You get full access to 55 ports in I/O. It is based on the powerful but power-sipping STM32L4+, running at 120 megahertz with about two MBs of flash and 640KB of SRAM. Swan does support Arduino, C, C++, and circuit Python. The Swan really is a great option for edge computing and tinyML, those low-power machine learning solutions. If you're curious about Swan, head over to dev.blues.io for more info.

All right, time for Q&A. Thank you again, to everybody who attended. Please be sure to visit dev.blues.io for all of our guides, docs, and API references. Just for being here today, I invite you to take 10% off your next Blues Wireless purchase, whatever it may be, with the discount code provided in bitly/blues-qubitro. Speaking of discount codes, use the RR50FORMONTHS code on Qubitro, which is a recurring discount of $50 for 50 users for three months, which covers up to 25 devices monthly on Qubitro. Finally, visit docs.qubitro.com for a variety of Qubitro technical resources. With that, give us just a moment to get everyone on the line here so we can answer some of your questions.