Getting Started with the MING Stack for IoT

Session date: Aug 06, 2024 08:00am (Pacific Time)

Join us for an insightful webinar about the MING Stack, which includes MQTT, InfluxDB, Node-Red, and Grafana. This session will introduce participants to the essential components and collaborative dynamics of the MING Stack and demonstrate how it forms the backbone of IoT applications.

The webinar will also highlight the MING Stack’s adaptability and robustness, showing how it can efficiently handle real-time data processing and visualization to enhance IoT deployments across various industries.

What you’ll learn:

• Overview of the MING Stack: Understand the roles of MQTT, InfluxDB, Node-Red, and Grafana in IoT solutions.
• Advantages of Integrating MING: Discover the benefits of using the MING stack for robust IoT infrastructure.
• Real-World Examples: Explore how companies like Prescient Device and FlowFuse leverage the MING stack to enhance their operations.
• Application Insights: Get tips and strategies for deploying the MING stack effectively in your IoT projects.

View the Presentation

Watch the Webinar

Watch the webinar “Getting Started with the MING Stack for IoT” by filling out the form and clicking on the Watch Webinar button on the right. This will open the recording.

[et_pb_toggle _builder_version=”3.17.6” title=”Transcript” title_font_size=”26” border_width_all=”0px” border_width_bottom=”1px” module_class=”transcript-toggle” closed_toggle_background_color=”rgba(255,255,255,0)”]

Here is an unedited transcript of the webinar “Getting Started with the MING Stack for IoT.” This is provided for those who prefer to read than watch the webinar. Please note that the transcript is raw. We apologize for any transcribing errors.

Speaker:

• Charles Mahler: Technical Marketing Writer, InfluxData

Charles Mahler: 00:00

Trying to think of anything else. I think that’s pretty much it. So, we’ll get into it. All right. So, the agenda, we’re going to obviously go over a quick overview of what it is and of the problems that it solves. Then go into the individual components, go over some kind of production tips, some real-world kind of issues or challenges that you might want to know about ahead of time, how you can fix some solutions, those types of things. And then finally, we’ll look at some real-world case studies for companies who are using the MING Stack or different pieces of it. Because as we’ll go over throughout this webinar, it’s not like a religion where you have to use it exactly as it is. It’s the whole point of it because it’s very flexible and essentially an easy way to get started with an IoT project, but you don’t have to 100% commit to it. That’s kind of the whole point. So, to start off, I want to go into the vision of IoT and the ideal that I think everybody would be striving for. So, this is kind of a meme image, but it’s basically what it could be if humanity got everything right. To do that, to have the flying cars, the self-driving cars, and these cities that run themselves. You need to, obviously, first connect to these devices. You need to be able to collect data from the sensors around the devices on the vehicles. You want to be able to store that and then be able to query it and analyze it efficiently. You’re going to want to have some sort of ability to visualize and look at that data.

Charles Mahler: 01:52

And then once you get that next step, you want to be able to essentially predict based on historical data, if possible, see what’s going to happen, or just based on real-time data, be able to take some action and eventually automate those routine actions. So, a more concrete example in the real world would be just like basic home automation. So, for example, your starting point would be having nothing hooked up. It’s just your house. An issue with that could be that– for example, myself the other day, my power went out. It was like two hours. Luckily, I was here, so it wasn’t an issue. But for example, if you were on vacation or you’re away and you come back and all the food in your fridge is bad, that’s not a good thing. Or it could also be like with security cameras, somebody breaks into your house, you have no clue until you get back. So, the first step is to hook things up so you can do security cameras, basic smart thermometer type of thing, and then you can get an alert, collect that data, you can track how efficient your house is, that sort of thing. And eventually, it would be kind of the automation step where you can, for example, like your thermometer, you can save money, be more efficient by if during these hours, you don’t need to use– you don’t have to have the heater, the air conditioner going, that sort of thing. And you see this kind of trend across all sorts of industries. So, another one would be automobiles. So back in the day, if you got in a crash, nothing happened. You had to kind of get yourself out of it. Then the next stage was like a reactive sort of thing where you had OnStar where it would detect that your airbags went off and they could call emergency services if you needed it.

Charles Mahler: 03:40

And today, we’re kind of at the predictive stage where it can do basic stuff and a little bit of automated stuff, but keep you in your lane, do emergency braking. If you’re going to rear-end somebody, that sort of thing. And there’s a little bit of self-driving going on. Some are better than others. But the idea would be that you can let your self-driving car, like fleets of them, you don’t even have to worry about it anymore. So not that the MING Stack will get you there, but that is like what I think is the vision. So, what is the MING Stack? Essentially, it is a core set of tools to get started with IoT projects to essentially help you not overthink things. It’s kind of a go-to stack. And this came really just from the community and kind of a collective thing where it’s similar to like you see with web development where you had the LAMP stack, and then you had some of the various acronyms for React.js, like MERN, Mean, some of those. So basically, developers love acronyms. They love simple things, and that’s where this came out of. So, it consists of MQTT, InfluxDB, Node-RED, and Grafana. So, there’s nothing really magical about it.

Charles Mahler: 05:04

And like I said, as we go through this, you’ll see that in some cases, you won’t have to use the entire stack. Other times, you might flip out one component for another, but it’s just kind of a starting point. So, the kind of core benefits, why people, a decent group of IoT developers, and really even beyond that, have consolidated kind of around the stack is, first of all, you can create value upfront because those are all open-source components. You can get started for free. You can roll it out. You don’t have to go through sales or some vendor to get your hands on it. You can just get started with it. And another bonus is that all of them are scalable long-term. So, while it’s really useful for prototyping, it also has the ability to scale up. So, if you take it past the prototype stage, you don’t have to really stress out about that as well.

Charles Mahler: 06:02

Next up is the ability to not only do prototypes and greenfield projects, but the whole concept was around a later point, like the open architecture, which is that you can integrate into existing products or existing projects, existing ecosystems, essentially. So, whether you have a legacy factory or something, the good thing about this is that it supports pretty much any protocol you can imagine. You’ll be able to hook into it as long as it has the ability to communicate over MQTT or really any other commonly used IoT protocol. You’ll be able to plug into that. And then you can make your own dashboards. You can make your own automations with that data. So, it’s built around interconnecting and integrating with existing stuff. The big thing is also increasing productivity. So, you can take advantage of all the work done by these open-source communities. You’ve got plugins in the case of Grafana. And for Node-RED, you’ve got tons of nodes that you can just take out of the box, work with, and usually find whether it’s like an API integration or some sort of other tool, a lot of the times it’s already been built, and you don’t have to do it yourself from scratch. Well, actually, one of our later case studies, we’ll go over a company that essentially has a services kind of like a hosted MING Stack type thing. And they show that for their customers, compared to whatever they’re doing before, they can usually get a product out, like on average, 12 times faster than the kind of traditional route.

Charles Mahler: 07:43

Next up, we have empowering subject matter experts who aren’t necessarily engineers. So, they might not be able to code at a high level, but the Node-RED in combination with these other tools can allow them to get something built. And there’s a lot of benefits to that because, yeah, people who have all the knowledge in their head, they know what they want. They know what would be really useful. But the inability to get access to the data or write code is what slows them down. So, this is something that’s covered in another case study where just setting this up drastically increased the number of people interacting with their data, finding insights just because it made it easier and faster. A big thing for industrial IoT is the potential for vendor lock-in because a lot of times you pay a bunch of money upfront, and you spend a ton of time getting everything set up. And at that point, you are effectively stuck just because it’s such a big sunk cost. And then the vendor has, obviously, leverage over you and you’re in a bad position. So, by using these open-source tools, if you do it right, it can kind of prevent that to some degree or at least reduce the risk of it. Finally, probably, to me, the most important aspect is the open architecture and the flexibility that it gives you in terms of how you do stuff, how you set things up. Like for example, how you do your data processing. You can do it on the device at the Edge. You can do it inside Node-RED in some cases. You can send it to Node-RED, then send it to an external tool to do the heavy lifting, or you can send it to InfluxDB, then pull it out of InfluxDB, do it some other tool. So, it really gives you a lot of flexibility in how you go about things.

Charles Mahler: 09:39

Again, designed to integrate with other systems, and you can switch out these components as needed. If you don’t need a bunch of data visualization, you might not need Grafana. If you want to use some other kind of tool instead of Node-RED, or maybe you do have plenty of engineering resources, and you don’t need the low codes thing, you can flip that out as well. So, it gives you a good base to work with, but you don’t have to stick everything to it. So now we’re going to look at some of the individual components. So first off, we have MQTT. So, it’s a lightweight protocol designed explicitly for IoT. It was created in the ’90s for monitoring oil pipelines, and it became open-sourced. And it’s designed to work in environments where you don’t have or you can’t count on having solid connectivity all the time, and you might not have high bandwidth. So, the good thing is that it has a flexible data model. You can add new topics. You can edit or add additional fields as needed. It supports different levels of– it’s called quality of service. So, depending on your use case, you can do exactly once delivery. You have various levels of guarantees depending on what you’re doing. And it’s very scalable because it uses a pub/sub model where the number of clients, you just connect to the broker, and you can horizontally scale the message brokers. So, it can scale up to many devices as you grow.

Charles Mahler: 11:24

Yeah. So next up is InfluxDB. So obviously, it’s a time series database, which makes it ideal for working with most IoT situations where you’re going to be collecting sensor data, event data, stuff that probably has a timestamp attached to it. And what’s going to happen, the benefit of that is you’re going to get– because you have a dedicated tool for it, you’re going to get better performance, you’re going to get cost savings, total cost of ownership is going to be lower because you can use less hardware to get the same or better results in terms of performance. Generally, you can expect like if you’re scaled up to that level, they can handle writes and queries for millions of data points per second. A big thing is the data ingestion performance because usually when you’re working with IoT, especially if you’re monitoring, you’re going to want to be able to query the most recently written data very quickly. So that’s a big kind of factor. And for Node-RED, according to their community survey, InfluxDB is now the most popular database at 44% of their community members said that’s what they go with. MySQL was second at 31%. Another bonus is ecosystem integrations like Node-RED because they have a built-in automatic plugin. You can just pull that in. It also goes for Grafana. Pretty much a large chunk of tools is going to have pre-built integrations. And if they don’t, you can always just use the API or the client libraries and still connect that way.

Charles Mahler: 13:09

Some developer productivity features just basically due to being a dedicated tool for time series data out of the box. You get stuff like retention policies, downsampling. InfluxDB 3.0 has support for SQL and InfluxQL, our older query language. So those come with a variety of built-in kind of functions for working with time series types of queries that you don’t have to write quite as much SQL to get that done. And then, finally, you have open source, which allows you to, again, get started fast. And also, probably the more interesting angle here, which we’ll see a bit later, is it allows you for these pretty cool hybrid architectures where you might combine at the Edge where you need low latency, or you have security requirements where you can’t have stuff in the cloud so you can deploy at the Edge on-prem. And then, in some cases, we have people who send like they’ll downsample it because they don’t need the high granularity on their data after a certain point, and then they send it to the cloud. And so, it goes from monitoring at the Edge to maybe business analytics type stuff where it’s lower granularity, but they can still derive insights from that.

Charles Mahler: 14:27

Finally, I’ll throw that on there. It’s on that diagram as kind of an honorary member because we do have a decent chunk of people who use the MING Stack. They might use Telegraf depending on the situation. I’m just checking the chat. Yeah. Well, I can answer that later. And this is just the 3.0 Data Explorer. So, you’re not going to do much data visualization with it, but it’s good for quick testing just to make sure your data is in the format that you expect, make sure all the stuff is there that comes with InfluxDB. So on to Node-RED. So, it is a low-code, in some cases, no-code programming tool for event-driven applications. So, you can use it for Beyond IoT, but IoT is a big use case. You essentially, something will kick off a flow, and then you can have sequences of these nodes that will act on whatever the input is and take different actions based on how you define it. You’ve got a UI, which I’ll show you a little bit later. But you can, for the most part, drag and drop stuff and build out stuff using pre-built nodes. So, it’s open-sourced in 2013. And I’ve got that chart there of the get up stars, like get up stars aren’t that important. I think the important thing is that it shows that it’s got steady growth, that the community is growing. And also, it’s bigger as the development continues. They just released, I think, in June, version 4.0. So, it’s not like some– you don’t have to worry about it being neglected or abandoned or anything like that.

Charles Mahler: 16:28

The big thing, I think, is that in some cases, it might get designated as kind of a hobby. Like I would do your home automation type stuff, but there are a lot of major companies either embedding it in their products or building on top of it or just creating different integrations so that it exposes their services to Node-RED. And basically, if you look on Google Scholar, whatever, there’s 3,000 research papers that use Node-RED, and usually, an industrial environment is some part of what they’re writing their paper on their research. So, there are serious people using this, and it’s a sustained, and it’s pretty much a mature kind of product. So, for that version 4.0 that I mentioned, it added some pretty interesting features. A lot of them, which are nice, are, like I said, about maturing the product. So, you get some stuff that used to only be in commercial versions of Node-RED. There are some service providers who do that. They’re getting added in. So, you’re getting stuff like the beginning of [inaudible] like multiplayer editing, similar to a Google Doc, or you can make sure that you can see who’s working on the same flow if you have multiple people in the project. You get diff views. So, you can essentially approve changes to a flow, make sure there’s nothing conflicting. So, they continue to add new features that make it more valuable over time. So, these are really the most basic level of the key concepts to know. They’re just kind of the building blocks.

Charles Mahler: 18:13

So yeah, if your nodes, which are essentially supposed to function like a black box, you shouldn’t need to know the internal how it works. You should send an input, get an output. That’s what a well-created node will do. Comes with default nodes. And there’s also, I think, 5,000, close to 5,000 community nodes that you can import into your project. And these nodes make up flows, which are just chains of nodes that you can take input, whether it be an MQTT message, an HTTP request. That’ll be your input, and then you can transform, manipulate that data that is input, and then do something with it at the end. And finally, the input, like I said, they’re called messages. So that is what is passed from node to node until you reach your output. So, this is your Node-RED, kind of like what you will see if you install it and you’re looking at the editor. So, you can see on the left in that sidebar, those are the various kinds of nodes, some of the built-in ones. In the middle, that’s your drag-and-drop workspace. So, this one is just a simple– it’s got an MQTT connection to a broker. Those messages then get sent through a function and then get sent to an InfluxDB account. And then you also have a debug, which you can just use to basically see what the message contains and obviously debug if there’s something your flow is not working as expected, that’s what you used to essentially print out. Did I mess up the format of the message at some point? That’s what’s happening there.

Charles Mahler: 20:01

On the right, you can see you can essentially just have multiple flows that you can switch through. You can deploy them, all that stuff. And at the top, it’s like a basic editor. You can switch between them. So, the different types of nodes, you can kind of categorize them. You have storage where you can output to a database, whether it be InfluxDB, whether it be a file, CSV. You essentially have stuff for outputs or storage. You have utility nodes that can be often just things for common tasks. You also have parsers. So, you input something from a JSON object. You can parse that. And pretty much any format, any file format. There’s going to be some sort of utility for that. You also have a really useful one, which is the exec node, which allows you to call from the command line or essentially treat it like a command line. So, Node-RED is obviously JavaScript, Node.js. But if you want to do some processing, you could call a Python script. You could send that. You could use this node, the exec node, to send the data to some other service and then return it. So, it gives you a lot of freedom that you’re not just restricted to Node-RED when you’re working with these things.

Charles Mahler: 21:21

Yeah, control node. So that’s basically anything you would want to do. From a code perspective, you have conditional switches. You have ways to handle retries, handle failures, error handling. You can rate limit stuff so that a flow within a certain time span maybe only runs so many times. Then you can inject. So, you could create a scheduled task so that something is sent to the flow, like every five minutes or something like that. So basically, anything, any type of situation where you could write in code, you can use these nodes to replicate that effect. Integration nodes are stuff like kind of wrappers around APIs. So, you can do stuff for Twilio and Slack. If you want to send an alert, like some data point comes in, it’s over a threshold, kick off an alert, send an email, text message. Pretty much any popular integration you can imagine. There’s probably a node for it. So, you don’t even have to just import it and start using it. And finally, you have protocol nodes, which can be inputs or outputs. So that’d be like your MQTT, HTTP, OPC UA, webhooks, stuff like that. Or you can take in a message and send it back in the same format, in the same protocol, or you can send it to something else over a different protocol. Finally, we have Grafana, which is really just a data visualization analytics platform that can support multiple data sources. So, beyond the MING Stack and InfluxDB, you can also connect to various other databases and tools. Supports data transformation, and you also have some pretty good alerting functionality.

Charles Mahler: 23:10

So that’s another thing about this where, like I said earlier, you can do data processing in different areas. You can also do alerting in different areas of the stack. So, you can do it. You could do it from Node-RED, or you can allow Grafana to take on that alerting task. So, this is just a Grafana dashboard from another webinar we had on the MING Stack. And this uses one of our– it’s called Plant Buddy, which is basically just got a plant, as you’d expect. And then it has sensors to monitor the temperature, the humidity, the soil moisture percentage, and how much light it’s receiving. So that’s just a basic dashboard there.

Charles Mahler: 23:56

So, your deployment options for the MING Stack, you could obviously just do it all kind of like direct installs. But a lot of people for basic situations, they’ll do Docker. You create your Docker image for each, and there’s tons. You can find quite a few pre-built ones on GitHub. And that works really well at smaller scales. But if you plan on scaling up to a bunch of different devices, that can become a little bit messy. So, some other services as options are Portainer, which has basically like kind of a nice feature set built on top of Docker. And it’s a good option. It has some rule-based access control stuff so that based on your role, like you can’t just delete everything or push out a bat that builds and destroys everything. And then Balena that’s what that diagram is. We’ve done a webinar with them as well, where they essentially are focused on IoT. They support, I think, 70 different devices. So, they make it really easy to deploy on these devices, and they have a lot more device management directly so that you can do way more than you could with just Docker.

Charles Mahler: 25:15

So, if you’re rolling out to a bunch of devices beyond just like a small-scale project, it’s worth looking into those alternatives. So, the main stack in production. So, some of the stuff, like if you’re just doing something like it’s a learning project or a hobby project, you probably won’t run into any of these issues. You might not have to worry about it. But there’s some tips and best practices, basically. So, a big thing at scale is issues kind of like with DevOps, you could call it, where out of the box, there isn’t a ton of great– like you can’t treat it like a normal software project necessarily. Node-RED is adding that stuff. Like In the recent 4.0, they improved a little bit. They still have some work to do. So, the things you have to think about are how do you handle version control? There’s no way, really, by default to do that. So, if you have conflicting changes, people working out at the same time, there’s no great way to deal with that. It can be a challenge if you’re running on multiple devices. Again, like how do you roll out if you have to patch a node version, like how do you roll that out to every device? How do you automate that so you’re not doing a bunch of manual work? And then there’s stuff to consider. Like if you’re in an environment where you can’t really risk downtime, you have to think about your dev environment, like staging, treat it almost like essentially regular software. So how do you kind of build that out?

Charles Mahler: 26:52

Next up is just straight-up scaling. So, the DevOps stuff is really like if you have multiple people working on the project, scaling itself, it’s like high availability. How do you deal with that? How do you horizontally scale? Node.js is single-threaded. So, if you’re doing a ton of data, you need to think about do you put some sort of load balancer in front of it. Do you put some sort of queue in front of it, so it doesn’t get overwhelmed? There are different ways you can also horizontally scale Node-RED, but there’s nothing like out-of-the-box official for doing that. An option, again, is, when possible, really just use Node-RED as like the glue between the different pieces of your project. So don’t use it to do heavy data transformation within Node-RED. Kick that out to a dedicated tool, some sort of stream processing tool, and then you can send it back into Node-RED.

Charles Mahler: 27:49

Oh, and also another option is—a recommendation from Node-RED is you can run each flow in its own runtime. If you don’t need the UI, you can run it basically in headless mode, which saves some resources. And you can create a load balancer and distribute the traffic to multiple instances of Node-RED. Other things are security. So, if you need role-based access control, ways to restrict people, there’s no great way to do that right now. And if Node-RED had a vulnerability, you have to keep that in mind—how are you going to handle that situation? And then just risk of using community nodes as well. When you’re taking on some node that might not have been maintained for months or years, or maybe they even wrote it maliciously, like using those community nodes, there’s always some risk to that depending on how critical your use case is. So, the option is we’ll go over a few of these in these case studies, these potential service providers. And the alternative is, of course, you can try to build some of this stuff yourself.

Charles Mahler: 29:02

So, onto case studies. The first one is Graphite Energy. So, they’re a pretty cool company. They essentially take renewables, which the big issue with them, like solar and wind, is that solar and wind are not– the sun’s not shining at night. Wind isn’t always providing steady energy. So, what they do is they try to take that solar and wind and then basically normalize it. They convert it into heat or steam, and then they can use that to basically do a steady supply of energy. So, they use the majority of the MING Stack. I can’t confirm they use MQTT, but they do use Node-RED, InfluxDB, and Grafana. So before, they had been using MySQL user database. They went from being able to collect one-minute intervals for their data to collecting every second. And they also expanded the number of fields of data they collect from 10 to 100 fields to give them more detail of what’s going on with their machinery.

Charles Mahler: 30:15

So, the effect of that is per device. They went from 15,000 data points per day to 1 million per day per device. And they’re actually faster now than they used to be because they made the switch to a dedicated database. That allows them to make basically more accurate forecasts and better monitoring. And the side effect of that, I had referred to it earlier, is that more of their not only engineers but non-technical people, because– before it took minutes to get a query back, like it’s not fun if you write a bad query, it takes a minute to get it back, or it fails, or whatever. You can’t interactively mess around with the data. So, once they made this switch to InfluxDB, like they just saw more basically engagement where people were interacting with the data much more and getting better insights to resolve that.

Charles Mahler: 31:12

So, this is like a diagram of their architecture. They basically have three different kinds of tiers. So, at the Edge, they’re using Node-RED. That’s how they collect and pre-process the data. They then have an OSS instance of InfluxDB. They do some data transformation stuff, and that’s where they do their performance monitoring with that really high granularity. They then have their operations team, which takes in that data or monitors that data that’s coming in from each site where they have those edge devices deployed. And then finally, they do some downsampling, and they store it in the cloud. And that’s where they do business forecasting type stuff, try to see they’ll look at which site is solar doing better than wind. That’s how they kind of use that to steer company investments, like which one is basically generating the better return, performing best. And this is just an example of what their customers need. They’re manufacturing customers. They need a steady supply. There are slight dips, but they need a pretty steady supply. And if you relied on solar, obviously, that’s not going to get the job done. And this is a digital twin they built. So, they were able to– using this higher granularity data, essentially, they created what’s called digital Twin, and it allows them to not only replay past events to see what happened, but they can actually do simulations and projections where they’re within 5% accuracy. And so, they can adjust some parameters, adjust some different things, see what will happen, and then they can implement it. And over time, they found that there are usually these forecasts based on this digital twin are within 5% of their simulations. So, it’s become a pretty reliable thing for them.

Charles Mahler: 33:03

Next up, we have ADLINK. So basically, they’re a company that specializes in helping where they’re like a service provider helps companies do IoT, Edge computing, that sort of thing. So, in this case, they’re working with a company or an aerospace company that was having issues with outages. And each time that would happen, it would cost them like $100,000 per breakdown of this machine because it would stall the whole line. And because they didn’t have any predictive ability, they’d have to call the specialist who would repair it. They’d have to order the parts if they didn’t have them on hand. And because it broke in multiple ways, they didn’t know exactly which part to order. So, the shows that move from trying to go from reactive where it’s already happened, and then you have to react to it to, “Okay, we know at some point there’s a high probability of this happening.” And so, what they used is Node-RED was used for gluing the sensors and all this stuff together. And then they visualized it with Grafana. And InfluxDB was used at the Edge to store that data. And a big part of the success for this was, again, being able to store higher granularity data makes studying these correlations of what was happening when things broke down. It allowed them to be more accurate, to get a more accurate assessment.

Charles Mahler: 34:25

And InfluxDB, again, being able to be open-source and deployed on-prem for like an aerospace company that they didn’t have to worry about. It’s like security concerns. So, the machine in this case that broke down was a testing chamber that tested the heat and cold. The airplane parts, they’d have to test them under different conditions to make sure they worked properly before they could deliver them. So, they tracked temperature in the machine. And the interesting thing is actually a factor they found that correlated with these breakdowns was not the machine itself, but the water pressure that was sent to the machine. So, they tracked the water coming through the pipe into the machine, and they found that that would help predict when these breakdowns would happen. And this is just a more detailed architecture of what they built. So, they’re using Raspberry Pis. They had Node-RED, Grafana dashboards, and then InfluxDB to help handle all that. And they sent, again, a common like this hybrid architecture where you send stuff back to the cloud.

Charles Mahler: 35:37

All right, so Prescient Devices. So, this is one of those companies that is essentially kind of like a hosted MING Stack, hosted enterprise-ready, Node-RED type of thing. So, they have different components. They have edge-to-cloud, and they have, basically, through their working with customers compared to the traditional route, in their words I can’t confirm what they’re comparing it to, but they say that they are able to deploy stuff 12 times faster. So, some use cases that they’ve done are predictive maintenance for CNC machines on the Edge, where they deployed machine learning models to the Edge with InfluxDB there to store the data. And they’re able to then use also the historical used InfluxDB Cloud for historical data storage as well. So, they’re able to kind of predict when these CNC machines need to be fixed. And they also built and scaled out, which we’ll see a little bit later how they do it. They scaled basically from the prototype to hundreds of different sites in two months. So that goes into, again, I think some of these like the previous one, an aerospace company, the one before that, like a big renewables company. It’s like you can use Node-RED and these other tools for tasks that require scale and tasks that are very serious business and not just like a toy project.

Charles Mahler: 37:12

So, this is the architecture they have in the cloud, this designer, they call it. So that’s where you have your Node-RED user interface, where you build your stuff. They use InfluxDB in the cloud there too and Grafana. So that’s where customers can also create their own Grafana dashboards to display the data they’re getting back from the Edge. And they have a lot of those features in their cloud product that I mentioned where stuff that makes it easier to have DevOps type stuff where you can roll out or you can do a rollback if something breaks when you play it to the Edge. They have a lot of features for that type of stuff. So just from a kind of maturity perspective for stuff where you need those features, they’ve obviously built those out. So, at the Edge, they only use the Node-RED runtime. So, it’s like headless mode where they don’t want to waste resources for a UI they don’t need. So that’s how they do that at the Edge. They’re using, again, Influx. A common pattern is InfluxDB OSS at the Edge because it’s easy to deploy, easy to store that data at high granularity before you send it back with some downsampling.

Charles Mahler: 38:25

And finally, Node-RED is used to integrate with the sensors and other devices at the Edge, and that they have the ability to roll out, for example, TensorFlow, like machine learning models. So, they can do stuff like computer vision to look for anomalies, whether it’s like checking products, checking maybe you could even probably run like a security camera and look for stuff that’s not supposed to be there. In some cases, they do audio machine learning models. So, there’s a use case not for Prescient specifically, but a similar situation you could do with this is like in the Amazon Rainforest, they deployed machine learning models to basically detect illegal logging activity. So, they trained it to recognize the sound from a distance of a chainsaw taking down trees. So that’s the type of thing you can do with these Edge deployments when you put these machine learning models at the Edge. And finally, they have some custom nodes that make it a little more seamless, like you really don’t even have to think about. You can set them up so that basically, it’ll seamlessly send or do whatever you want between Edge and Cloud, and it really streamlines. If you try to do it like bare bones, Node-RED, it’d be pretty tough. But that is essentially a feature that they also have built into it.

Charles Mahler: 39:49

So next up, we have Loft Orbital. So, they are kind of Uber for space. They are satellite as a service. Basically, the most extreme Edge computing use case. And basically, what they do is you rideshare on there, and if you don’t have the money for your own satellite, obviously, they allow multiple like you buy a little bit of space, however much you need for your experiment. And then they allow you to send your data, whatever you’re collecting, back down to Earth. So, this is their architecture where they use Grafana for not only their internal dashboards, but they expose dashboards to their clients, their customers. I include this one, actually, because it’s a good example of not having to use the entirety of the MING Stack. So, they use Telegraf, our agent that has tons of collectors, and it can also do a little bit of data processing. Obviously, it doesn’t have the nice drag-and-drop user interface. But in their case, they went with Telegraf. And they also went with– because a Node-RED they obviously didn’t use in the first place, but they needed heavier stream processing because they had a lot like a high volume of data. So, they used Kapacitor, which is another older InfluxData tool. And then, once they do all that, they use InfluxDB Cloud, which makes that data available to their customers through that Grafana dashboard that they expose. And they went with InfluxDB because they were pretty similar to a lot of places like Graphite Energy earlier, where they were using a relational database, and they were just struggling to scale. And they knew with their growth rate they were going to run into major problems. They just made the switch at that time. So that’s pretty much it for this.

Charles Mahler: 41:40

We have some time for questions and answers. It doesn’t have to be about the MING Stack if you want to ask about any other IoT topic or InfluxDB specifically. Otherwise, we can call it a day. I did see earlier, so there’s a question about any ideas to why the low uptake of InfluxDB with Node-RED? Must be Node is old. And I said, “Oh, disregard.” I think there is. I don’t know if they support– I think there’s support for 2.0, and there’s obviously 1.8 support. I don’t know which one is the most popular version. And I don’t know if they support 3.0 yet, InfluxDB 3.0 is pretty much standard SQL, so I’d imagine. I haven’t tested it out, actually, but I’d imagine you could probably use some of the other just standard SQL outputs to query InfluxDB. We have a question. Is there any more material on your website to learn more about this?

Charles Mahler: 42:51

I think we have a few blog posts, and I’ll have them send them out with– actually, I’ll get the link first. But we have quite a few webinars with various IoT companies that touch on this, even if the webinar isn’t entirely dedicated to the topic. Usually, they cover it. Yeah, a lot of them touch on it at some point, kind of the same concepts we’re talking about here. I’ll post this in chat. So, you can scroll through. You’ll see the webinars at the top. And you can look through, and you’ll see a lot of– we had a recent one about upgrading building management with smart Edge panels. So, there’s quite a bit of Edge computing and stuff like that. Let’s see. In stack, connect to PLC hardware. Yeah, essentially, depends what protocol they’re talking to. I know Node-RED supports serial. It has the input for that. And then, obviously it has OPC UA, MQTT, a lot of different things. Let’s see. What is the recommended reporting tool? Grafana has this feature only in Enterprise. I guess if you want to give some more context in this regard to reporting and what feature you’re talking about that’s only in Enterprise, I can try to help. Otherwise, Grafana is definitely not– obviously it’s part of the MING Stack, but you can use any other data visualization tool you’re comfortable with, too, that communicates over whatever integrations. It’s InfluxDB 3 Cloud only. At the moment, it is. And trust me, we’ve all gotten tired of saying that, but there is an OSS coming. We just don’t know the time yet. But yeah, I’m just tired of saying that as you. We all want to see– we all want to see OSS 3.0.

Charles Mahler: 45:13

Where do you recommend OP CUA translation to MQTT? I suppose it depends on, again, it always comes down to kind of your situation and what you have set up. So that’s kind of, I guess, would come down to what scale you’re at. If you have a lot of data points, you probably don’t want to do that conversion in Node-RED just because it could kind of choke it. Otherwise, that’d be a situation where you might want to use Telegraf. You could also, again, like you said, do it at the Edge. But really, that’s kind of the point, or the good thing about this is that you can kind of go crazy with how you do things. You can do it anywhere early. It’s a flexible kind of architecture. You have other visualization tools other than Grafana that you recommend? I mean, you could pretty much go with any of the popular ones. I suppose you could probably hook up to like– Google has Looker now. I think that’s what it’s called. Then you have Power BI, you have Superset. I’d imagine any of those would work pretty easily. For InfluxDB, we have some tutorials, I think, on Apache Superset and a few other data visualization tools beyond Grafana. So, you can go and probably just Google them. It’s like an InfluxDB Superset. And I think they’re in our docs too. So yeah, it’s definitely not a requirement by any means.

Charles Mahler: 46:59

Any plans after final light capabilities? I’m assuming you mean basic data visualization. Right now, I think we have– I don’t know. There’s 2.0 and InfluxDB 2.0 definitely has quite some pretty decent data visualization stuff. 3.0 is a little more cut down, but you can do the basics. I mentioned capacitors are an older solution. No, it’s definitely being maintained. I probably shouldn’t have said it that way. But yeah. What can you recommend with regard to retention policies and cross DP aggregation? Let’s see. So graduate retention policies and cross DB aggregation, for example, at a higher level of retention or older data kicking over to SQL. Yeah, I suppose you mean– yeah, I assume that would be fine if you’re interpreting it right. You’re basically saying if you’re going to lower the granularity quite a bit, like if you’re downsample it to a significant degree, that’s probably fine. If you’re cutting it way back, so it’s not like an overwhelming amount of data, that’s probably fine to use a relational database. Although InfluxDB 3.0 supports SQL now, so I don’t know if it’s strictly you just want to use SQL. So that would kind of solve the problem. But yeah, I mean, I always use the tool that works best. So, if you don’t need– if you’re okay with a general-purpose database, like if you don’t have the data throughput that requires like a time series database, go for it. Like If you’re more comfortable with it and you don’t have that performance requirement. Let’s see. Checking the chat.

Charles Mahler: 49:00

Are there any features in Influx to operate remote when one might be intermittent or just use MQTT? We do have an Edge data replication feature, which will buffer data. So, if you’re using an OSS instance, you can enable that, and you can check the docs for more info. But it will kind of buffer it. So, if connections are intermittent, it will hold that data, and then it’ll send it to InfluxDB Cloud or another InfluxDB instance. So that’s an option there if you don’t want to use MQTT. Best practices to download and store archiving data from InfluxDB? I noticed that downloading CSV may not be the best case for big amounts of data points. I’m trying to think. That might be a question. Hopefully, you can still see my slides. If you go to our Slack channel, there’ll probably be some community members who could give you the best. They’ve probably tried every possible alternative and every option. So that might be a good question for the Slack. We also have our devrels beyond just the community. Our developer advocates will be in there, so they can probably help you out. All right. That’s all the questions. So, I guess if anybody else will give you 30 seconds to throw one last question out there. Otherwise, we’ll call it a day. All right. I think we’re good. So be on the lookout. We’ll be sending out that email with the recording and various other resources. Thanks for sticking around, and I hope everybody has a good day.

[/et_pb_toggle]