InfluxDB + Kepware: Start Monitoring Industrial Data Quickly

Session date: Feb 08, 2022 08:00am (Pacific Time)

Kepware (a PTC Technology) is the market leader in Industrial Connectivity platforms, and is helping companies bridge the gap between IT and OT. For the past 25 years, Kepware has developed industrial connectivity tools including over 150 industrial drivers, and supporting over 300 protocols — from traditional automation protocols such as OPC UA or OPC DA to more modern IIoT protocols like MQTT or REST. Together with InfluxDB, customers achieve quick time to value, gaining insights from their industrial time-stamped data. Developers are able to collect, process, store and analyze thousands of metrics faster! Join this webinar to learn multiple approaches to sending IIoT data to a time series database.

In this webinar, Kyle Carreau and Jay Clifford dive into:

• How to use Telegraf to send OPC UA and MQTT metrics to InfluxDB
• The new Kepware IoT Gateway Advanced Template features to send data directly to InfluxDB
• Best practices for using InfluxDB + Kepware for industrial automation — stick around for a demo!

Click here for presentation

Watch the Webinar

Watch the webinar “InfluxDB + Kepware: Start Monitoring Industrial Data Quickly” 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 “InfluxDB + Kepware: Start Monitoring Industrial Data Quickly”. 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.

Speakers:

• Caitlin Croft: Customer Marketing Manager, InfluxData
• Jay Clifford: Developer Advocate, InfluxData
• Kyle Carreau: Partner Enablement Engineer, Kepware Products

Caitlin Croft 00:00:04.238 Hello everyone, and welcome to today’s webinar. My name is Caitlin Croft. I’m really excited to see you all here today. Really excited to be joined by Jay and Kyle, who will be talking about using Kepware and InfluxDB. Once again, this session is being recorded and will be made available afterwards. Please use the Q&A function at the bottom of your Zoom screen to ask your questions. And I just want to remind everyone to please be nice to our speakers and our community. We want to make sure that these events are a safe, happy, and fun place for all to learn more about InfluxDB. And without further ado, I’m going to hand things off to Jay and Kyle.

Jay Clifford 00:00:52.534 Brilliant. Fantastic. Thank you so much as always for that, Caitlin. So hello everyone, and welcome to joining us. So I’m quite new at Influx, so I’ve got to give you a quick sort of introduction from me, and then Kyle will obviously share who he is as well. But I’m Jay. I’m a Developer Advocate here at InfluxData. So before Influx, in my past life, I was actually a sales engineer for Industrial IoT solutions, sort of mostly looking at how we can help enable customers into Industry 4.0. My passion is autonomous and vision-based projects, whether that be worker safety or quality inspection on the line. My drive is to make IoT accessible for all. That has always been a drive of mine. It’s such a cool place to be and I want everyone to be part of that movement with us. And my belief is that industrial IoT success belongs to the domain experts. So mostly talking to you guys, I truly believe that the success of this industry belongs to people that actually know what they’re talking about within this industry, whether that be the factory workers, the machine experts, and that’s what we hope to be able to do is enable you guys.

Kyle Carreau 00:02:03.429 Cool. Thanks, Jay. Hey. Hi everyone to the Influx community. I think it’s probably the first time I’m meeting a lot of you. So, Kyle Carreau. I’m from Kepware PTC. Kepware was purchased by PTC in 2016, but still, I guess identify as a Kepwareian. So in the past life before Kepware, I was actually a Rockwell Automation distributor specialist. So I dealt with industrial networking, PLCs, information software, all sorts of things like that. My passion really is for innovation in the space and just for the ecosystem. I love talking to partners, whether Influx or others. And really similar to Jay, kind of taking his thunder here, but to make IoT accessible for all. I think it’s really - you might hear me say it a few times throughout this webinar, but it’s really important to have this ecosystem and to have partners and have experts in the field, whether that be from a technology standpoint or whether that be from a local business standpoint. [Inaudible] are preferred distributors over in Latin America, so I’ll give them a shout-out. And I guess yeah, my general belief, again, is just the success for industrial IoT really comes down to the correct partnerships, both between vendors, the system integrator, and ultimately the end-user. You have to have that healthy ecosystem in order to get these projects off the ground. So, Jay, I think I’m going to turn it back over to you.

Jay Clifford 00:03:33.490 Fantastic. So what is the plan for this webinar? Well, I think me and Kyle plan to get our hands dirty, so it should be quite exciting. So since we have a bit of a mix, we know there’s some Influx’s here. We know that there’s some Kepwareians. I quite like that word, Kyle. That’s my new favorite one.

Kyle Carreau 00:03:52.047 All yours.

Jay Clifford 00:03:51.931 Yeah. [laughter] What we thought we would do is give you a quick, in a nutshell, of Kepware and InfluxDB. We won’t spend too much loitering on these. We have plenty of content of the slides on here, but we’ll give an overview of both to keep everyone happy and on the same page as we go through the demos. Part two, we will give an overview of how we currently integrate Kepware and InfluxDB using Telegraf. So that’s how lots of you might already be using it, or some of you might be starting out. Then Kyle has a great demo, and we’ll be showcasing a brand-new feature in Kepware EX. So really excited to be seeing that. I was buzzing when I first saw it, so looking forward to that. And then finally we’ll discuss the gotchas, and we’ll have question time, too. We like to keep things real here. We both do. We both agreed this. So it’s all-new, and we’re excited for you guys to see how you can work and use this stuff. I’ll pass back to you.

Kyle Carreau 00:04:50.258 Great. All right. Awesome. So I guess just to level set with everybody, I’m going to take a few minutes to talk about Kepware. Jay had mentioned that this call really is a little bit more technical folks, which is good. So I’ll leave the sales slide up. Feel free to read that. But I’ll go through and I’ll kind of do more of a high-level technical overview. So really what Kepware is, we focus exclusively on industrial connectivity. So really what that means is if you have some sort of IoT project or SCADA project or you’re trying to send your industrial data to the cloud for whatever reason, the big challenge there is, how do I connect up to these devices out on the plant floor? And on the plant floor, there’s the challenge of it’s not going to be all from the same vendor. Even if they are all from the same vendor, it’s going to be different models. And even if they’re different models, they might be older legacy equipment. For those of you familiar with Rockwell, it’s pretty common to see a PLC-5 out on the floor with a SLC 500 and a ControlLogix. So the challenge is getting all of that data, collecting it, but then being able to send it off in a correct format. So whether that’s OPC UA or MQTT or, as we’ll see later, via REST. So really, the easy way to think about Kepware is we’re a universal translator. That’s really what we do. We make it easy for connecting up to your field devices in your plant out on the floor, out in the field if you’re like in an oil field or something, and then taking that and then presenting the data in a way where other client software can actually ingest that data and you can do all the fun stuff with it. Another way we like to say it is Kepware by itself is pretty useless. But really, we solve that really hard challenge of “Hey, we’re actually taking this data from one place and putting it to another.”

Kyle Carreau 00:06:43.656 And just to give you an idea, I’m not going to go through all of these for obvious reasons, but we have a lot of drivers. Everything from oil and gas devices to the traditional Siemens and Rockwell’s that you would find on your plant floor. One I would like to call out that is actually relatively new and pretty interesting, actually is our Universal Device Driver. You can see that all the way to the right there. That’s a scriptable driver. So, in other words, we have a lot of drivers and we can connect to virtually anything, but if there’s a weird device out there that sort of talks Modbus or maybe it’s a little bit different or maybe you’re using a barcode scanner or maybe you’re trying to use a Get-Command to some database somewhere, the Universal Device Driver will be able to help you out to do that.

Kyle Carreau 00:07:30.080 So what’s interesting and I think it’s important to kind of again level set here but Kepware was founded 25 years ago. 26 now, I think. Mid-90s. And at the time, the big focus was, “Hey, we’re just trying to get this machine to talk to the HMI.” And that was the challenge and we helped solve that. Throughout the years as data became more important, as ethernet became more relevant on the plant floor, and as the cloud came in and databases came in, it became a lot more complex to kind of get all that data in the place that you need to. So what we’ve seen Kepware be really successful is, if you look on the left there, that’s the traditional ISA-95 model that I think a lot of you are familiar with. But the idea there is, “Hey, if you wanted to get your level zero devices, your PLCs, your sensors, and you wanted to get that data and send it all the way up to the business system, you essentially had to go through each layer. And every time you send data through another layer, that data changed. And so by the time that simple bit or byte from layer zero got to the layer four, it looked completely different. And it’s just very convoluted. So it still works, but it’s maybe not the best. So that’s why with Kepware, again, not inventing any new technology, but really how Kepware is being applied in the field has changed. So we kind of take it now as a what we call an elevator approach. Which is, “Hey, once you get to that level one and you collect data using Kepware, we can now directly send that data to layer two, to layer three, to layer four, depending on what your need is.” But essentially Kepware’s that middle layer that’s collecting all the data from downstream devices and then presenting it in a way to those higher-level applications. So in a nutshell, really, Kepware’s just your industrial connectivity layer. And then Jay, back to you.

Jay Clifford 00:09:29.728 Fantastic. I liked your analogy there, Kyle. I feel like it was always funny when people used to come back and say, “So what did that factory have?” “Siemens.” “Sorry. What control are we talking here? S7-300 or are we talking S5?” Like, “What?” And I think that’s where Kepware comes in to save the day. [laughter] But fantastic. Yeah. So essentially moving on from there is we’re talking about sort of the OT world here and we’re talking about where we’re grabbing that data, collecting that data. But what we want to do is, what we want to look at is where to store it or where to send it next. So we’re looking at that IT layer. And that’s where InfluxData comes in and the InfluxData platform. So Kyle, if you wouldn’t mind clicking twice, I think?

Jay Clifford 00:10:14.092 Fantastic. So the two things out of the TICK Stack we’re going to cover today are Telegraf and InfluxDB. So when I refer to the TICK Stack, back in the old days, the TICK Stack used to be Telegraf, Influx, Chronograf, and Kapacitor. But with Influx V 2.0 being released, we’ve actually combined a lot of those things into InfluxDB V. 2.0. So when I talk about InfluxDB today, we’ll be talking about Influx version 2.0, which combines Kapacitor, Chronograf, and Influx into one bundle. And then we have Telegraf still as a separate, completely open-source agent. So just to highlight here on this diagram, both Telegraf and InfluxDB are completely open-source. We do have enterprise builds and versions, but all the code is up online for you to see. We have people contributing to it as well as our own maintainers. So it’s really a community effort and community-led and driven. So if you want to truck on to the next slide, Kyle?

Jay Clifford 00:11:14.388 So what I like to do is I like to give a dev burger to the platforms that we’re looking at. And so this is sort of my bite-size way of introducing you to InfluxDB without, hopefully, getting bogged down into the details of everything. I have to recommend that we do have an InfluxDB: Getting Started webinar that we always do. If you want more details in these areas, definitely go check that out. But first, let’s start up with setup. So InfluxDB can be hosted in a variety of different ways. We have InfluxDB Cloud, and that’s our SaaS service. So we host that for you on Azure, AWS, and sorry, Google Cloud. And then we have our open source Edge build. So that’s OSS. And that is hosted on Linux, MacOS, Windows, and Docker. Linux, we cover most, if not all, there. So whether it comes from CentOS, Ubuntu, Debian. We pretty much host on most Linux operating systems. And we also support different CPU architectures as well. That includes X68 and also arm builds for people looking at sort of lower-level devices. Whether that be Jetson Nano’s, your Raspberry Pi’s, the works. And personal favorite is I’m glad we dockerize everything. Most people nowadays, if you like deploying via Kubernetes or doing something a little bit more interesting like that, you now have the opportunity to use Influx in those ways.

Jay Clifford 00:12:46.906 So what are some of the features with InfluxDB? Well, so the primary feature is you have a web-based GUI. So that’s where you can do all of your database management, whether you are creating users, creating dashboards, setting up buckets, which we’ll discuss a little later. It’s all approachable to users, as well as developers, but also what I consider builders or just engineers that might not be readily available/ familiar with code or command line. There is a solution to allow you to fully deploy Influx from a GUI solution. Dashboarding. So when we sort of discuss dashboarding, this is a way of visualizing your data. And we have so many different ways of visualizing your data, whether that be from standard line graphs to gauges to mosaics to heat maps. There’s so many ways you can analyze your data, and we’re always adding to our portfolio all the time. One of our best ones is maps, where you can have a look at your geospace data. If you’re familiar with Grafana, it’s a little bit like that. We have functional data scripting, which I will go into a little bit more later into the demo. But that is Flux for anyone who doesn’t know. That’s a functional-based programming language which allows you to build data pipelines. Tasks. You can imagine a little bit like a cron job. It’s just a set piece of work that you can run automation tasks on your data. Most people use that for alerting and manipulation of your data. And then so yes, alerting. So Influx offers the ability to send alerts out based on your data, whether that be through email, through HTTP, MQTT. You can deliver alerts based on something that’s happening in your data. We can have a look, a little bit of that within the demo in the scenario later too.

Jay Clifford 00:14:36.142 But yes, to the jury center. What is InfluxDB? So it is a purpose-built time series database. And so what we mean by that is, what is time series data? So in a nutshell, time series data is a value that can be tied to a time value, whether that be interval or event-based data. So a simple example of this could be a temperature sensor, which we’ll go into. I can incrementally look at that data over time and see a change. So it’s built on Go, and it’s designed to deal with high volumes of time series data. So it’s amazing at compression. It’s amazing at dealing with large throughputs of time series data, so you don’t have to worry about sort of standard or relational-based storage where you could fall over without fine-tuning. And where do we see InfluxDB used? Well, it’s kind of crazy. We see it used in quite a few spots. So obviously industrial IoT, which we’ll be discussing today, server morning, geo-temporal data, logistics, fintech, agriculture, and e-commerce. There’s something for everyone in InfluxDB. So yeah, if you want to quickly fire on, Kyle?

Jay Clifford 00:15:48.707 So I’m going to quickly run this one. It’s Telegraf. So Telegraf is our metrics-based agent. So essentially this is how we collect data from the Edge or from other systems and allow you to ingest that into different platforms, whether it be InfluxDB or others. So again, set up. We have it on all the same distributions as InfluxDB and a few other features. So it’s a no-code, configuration-based platform. Over 200-plus plugins, which we’ll get into a few of those. We’ll look at the demo. It’s a minimal memory footprint, so you can run this on your embedded devices. Allows you to transform your data. But at its core, it’s a metrics collector. You are collecting from lots of different sources at the same time and sending that to lots of different places. As I said, it’s built in Go and it’s designed to manipulate metrics data. And then again, its use cases. We use them for a variety of different places, as you’ve seen from InfluxDB itself. Fantastic. So next one on, Kyle?

Jay Clifford 00:16:54.397 So what I wanted to show you is - well, what me and Kyle wanted to do was build out a scenario for you. Sort of a typical scenario that you might see on a factory floor. Maybe you have it now, maybe you might see it on a customer’s site. But let’s sort of paint a picture of a simulated factory. So in this scenario, we have two machines. We have a CNC machine and we have, oh, help me here Kyle, it’s a welding arm, wasn’t it? A robot welding arm [crosstalk] -?

Kyle Carreau 00:17:24.971 I think so, yeah.

Jay Clifford 00:17:26.246 That’s it. And the cool thing about Kepware here is we can take a holistic approach as well and we can have a look at monitoring production lines. We also have three production lines which we’re gathering data from. So in this scenario, which Kyle will go through in the next demo is this data’s being collected into KEPServerEX, which he will show. And in most standard ways of using InfluxDB and KEPServerEX together, you are connecting Telegraf through MQTT or OPC way. So Kyle, if you don’t mind pressing next, I think it should bring up the configurations? Fantastic.

Jay Clifford 00:18:06.413 So as I said before, Telegraf is no - sorry. Telegraf is no-code config-based setup. So as you can see, there’s two ways that we could go about connecting KEPServerEX to Telegraf and then to InfluxDB. So the first way you could go about it is using Telegraf’s input MQTT consumer. And as you can see here, that’s essentially connecting to the IoT gateway endpoint in KEPServerEX. Ingesting the data that’s best for your format. So as Kyle will show later, in terms of formatting, there’s plenty of ways you can format your data. In this approach, I’ve taken a JSON format. I’m pulling the JSON payload directly from KEPServerEX, and then I’m manipulating that data as I see fit within Telegraf. So you can see here with the inputs mqtt_consumerjson_v2 object. There’s a path. I’m disabling keys so I can have my data more succinct and I’m pointing to the correct timestamp. And then the other way you can look at it is, under the hood of KEPServerEX, there’s an OPC UA server. So you can connect directly to Kepware’s OPC UA server and we allow that through our OPC UA input plugin, which, as you can see there, it has all of the standard - it conforms to the OPC UA foundation with the correct security policies and certification, as well as username and password. And then, of course, you define your tags as you can see there. In my personal recommendation, I prefer the IoT gateway way of doing things because it makes things a lot quicker to get up started. But if you want to have that granular control over what tags you’re pulling and how you want to pull those tags from the OPC UA server itself, then yes, definitely have a look at the OPC UA input plugin in Telegraf. And then from there, we send our data directly to InfluxDB through the Telegraf output plugin. So that’s how we currently do things, which works for most people. I would say in terms of architecture here, KEPServerEX belongs on the OT floor, Telegraf’s probably installed on some sort of IT network somewhere, connecting to KEPServer basically through the factory firewall. And then either InfluxDB is on the Edge with Telegraf or is being transmitted into the cloud. But let’s have a look at a new way of doing things. And I’m going to pass it over to Kyle.

Kyle Carreau 00:20:41.948 Awesome. Great. I think at this point, and Jay, correct me if I’m wrong here - oh, yeah. I’ll go through this first and then we’ll - oops. Then we’ll do the actual demo. Yeah. So what we’re doing now, so with the latest release of Kepware, whether that’s [inaudible] or KEPServerEX, version 6.11 we’ve added something into our IoT gateway that we called just variables. So something to add to our advanced template. So essentially what that allows a user to do is go in and actually more or less configure the JSON payload with a little bit more granularity there. And I’ll show all those variables. But essentially what’s going to happen is this string down here is the format that we’re going to be sending directly to InfluxDB. And really, this whole thing came from - if Matt Roy’s on this call, I’m going to shout him out. But it’s this line feed variable which essentially just allows us to do a character or carriage return without some extra goop to it, we’ll say. Not much of a programmer. So you’ll have to forgive me there. But essentially, it allows Influx to now because of that directly consume data from Kepware which we’ll actually be showcasing here in a second, so. Jay, if I miss anything, let me know because I’m going to head off to Kepware now.

Jay Clifford 00:22:01.038 Brilliant. Yeah. So just to sort of help on there a little bit, so the main bridge that we had to cross before is InfluxDB [inaudible] line protocol, which is how we ingest time series data into InfluxDB. And what that template that Kepware have allowed us to create now allows us to ingest line protocol directly. Meaning we can essentially cut the middleman. So as Kyle said and he will show, you no longer need to use Telegraf if you don’t want to.

Kyle Carreau 00:22:31.306 Perfect. Thanks, Jay. Yeah. So what I’m going to show now is actually a demo project of KEPServerEX. And for those new, a few things to keep in mind here. One is when I mentioned and I say the word Kepware, really what I mean is Kepware’s really an ecosystem of services running in the background. So we have our server runtime which is actually doing all the translations. We also have a service that runs our IoT gateway, which we’ll get into in a second here. And then we also have a service running our event log, and then finally a service that’s running what you’re seeing here, which is just the configuration GUI. Really, it’s a longer way of saying this GUI doesn’t have to be up and running for Kepware to be working in the background.

Kyle Carreau 00:23:17.686 Next up, what we have here is, as Jay had mentioned, we actually have simulated data. So Kepware does have a simulator driver where we can actually get and simulate a little bit more granularly, some live data here. So we can see some current, maybe some different voltage controls, so on and so forth. So we have a bunch of those here. We decided to go again a little bit more fancy as opposed to just saying, “Hey. Look, I have a counter bit going up to four and back down to one.” So a little bit more enriched data. So essentially all this is simulating is this is how your drivers would connect down to the plant floor. So instead of a simulator driver, this might be, “Hey. I’ve got an Allen Bradley Driver. I’ve got a Siemens driver. “I’ve got a Yokogawa driver. I’m getting data and I’m exposing data through Kepware.

Kyle Carreau 00:24:10.550 Once that’s done, the next step is, well, where does Kepware send that data? As Jay showed before, hey, we can send it - with Influx, we can send it to Telegraf, via OPC UA, or via MQTT. But what we’re going to show now is actually the ability to send it via the REST protocol using our IoT gateway and then having that go directly to Influx. So what I’m going to show here, and this is already kind of pre-done, but if we open up the properties, what we’ll see is a few things. One, we’ll see the URL of our instance of Influx. This was taken directly beforehand. I’m trying to do the no tricks up my sleeve here, but we took this beforehand from Influx, pasted it in. We have the header here, which has our authorization token. I’m sure we’ll blur this out or something, but we have the authorization token in here.

Kyle Carreau 00:25:04.827 And then finally, this is where it becomes very interesting. We have this message format here. So beforehand, we’ve gone in, we’ve selected the advanced template, and then we’ve actually gone in and edited this a little bit. So this is the same sort of format you saw on that slide. So let me really quickly show you all some of the other variables here. I know this is weird opening up the help file, but our documentations actually really, really good. So we’ll go to the IoT gateway help file, we’ll go to data, and then we’ll go to advanced template data. And then here’s all the variables that you can play with and essentially be able to create your own custom payload. So we have tag name, which in Kepware is the nomenclature of channel.device.tag. But now we have new variables, like just tag. So we just get that end part. We have the address of the tag, which is actually the address that is on the physical device that Kepware is hooking up to. So that might look like a Modbus register. We can do a description of the tag. We can also send if that tag is read or write access. And then finally some different ways of sending over time stamps. So a lot of these are pretty new. But again, the most important one here is that line feed variable, which allows us to, essentially, support that line feed protocol.

Kyle Carreau 00:26:24.119 So once that’s done, we’ve got that template in there. What I’ll do is I’m going to add one more line in here, or more data, I guess. And then I’ll hand it over to Jay and we’ll actually be able to see all of this data coming in live into Influx. So really all we’re going to do here is we’re going to right-click on our instance of the IoT gateway agent. We’re going to add new IoT items. And then we’re going to scroll down to, let’s say, line three. We’re going to grab all those tags. We’ll hit apply. We’ll do every scan. This would depend on your application. For this demo, we’re just going to go every scan. But of course, you can set it on data change, which I think is pretty neat. So we’ll do it every second. We’ll click okay. And then we should see that data now being published over to Influx. And then I will say - I guess this is a good plug. While we kind of transition here, I’ll stop sharing, Jay, so you can grab it. But this is the demo file, the template. This is all posted on Influx’s GitHub page. And I just took a little bit of Jay’s thunder, but I’ll let him elaborate a little bit more.

Jay Clifford 00:27:40.594 Not a problem. No, steal as much thunder as you want. We’ll definitely cover that later on as well, so everyone has access to it completely. So what you’re looking at right now is InfluxDB Cloud. But whatever I’m doing in InfluxDB Cloud is completely translatable into InfluxDB OSS. So you’ll always find the cloud a little bit ahead of InfluxDB OSS, and that’s just purely down to our release cycle of the Edge version of InfluxDB. But just about everything that we’re using here is completely usable within the Edge version. So what I’ve got here is our dashboards. And this is where we discussed earlier, where we can visualize our results from our data. So I’ve pre-created a few dashboards. So what I’m going to have a look at is the raw data that Kyle is sending to me.

Jay Clifford 00:28:31.772 So if I jump into here, you can see already that we are dragging in this data from line one, line two, and now from line three as well. That data’s new. That was the data we’ve just added. And we also have our machine data as well from our CNC and our welding robot arm. So, as you can see, we have a variety of ways of visualizing that data and querying that data directly from InfluxDB. What I do want to show you is the schema of this data and the way it comes into Influx, because it sort of leads to a gotcha moment, but also a way of showing off how you can transform your data within InfluxDB as well. So let’s have a look at the production count and waste count for line one.

Jay Clifford 00:29:24.587 So If I hit configuration here and I look at the data browser, so what I’m going to do first is I’m going to open up a new query and if I look at the factory data here and I jump through, so this is showing you that although we have the Flux programming language, which you saw here, you can actually use a visual-based GUI to do your querying. So what you can see here, here is all the tags coming in from - sorry. Here it’s all the Kepware tags, which we consider fields in InfluxDB world, coming into InfluxDB. Now to me, this is where the worlds collide a little, and it’s in a good way. And me and Kyle has discussed this and how we can work together to improve this in the future, but what you can see here is that each tag is coming in as a field with the entire address there. And as Kyle highlighted, there’s ways of snipping that, so you only have basically the name of the tag rather than the full address. But for me, I want the full address because it’s of interest because the full address gives me the full context of where that data’s coming from. And Kyle, hit me with this. Its channel device -

Kyle Carreau 00:30:36.978 Channel device tag.

Jay Clifford 00:30:39.406 Yes. That’s it. So in essence, this gives us basically an ability to drill down into our data and work out exactly where this data’s coming from and allows us to store things more optimally with an InfluxDB as well. So I consider this raw data. And what I would do personally in InfluxDB is I would set a retention policy of about 24 hours on this data. Maybe a little bit longer if you really want to keep that data for longer. But for me, this data is coming in so frequently. And although the schemas valid, it’s an inefficient schema. And so what we’re going to do is we’re going to look to transform that into an efficient schema using InfluxDB. And we can do that using a task, which we discussed earlier. So let me quickly show you what I mean if I jump in and then I’ll show you within InfluxDB.

Jay Clifford 00:31:34.502 So, as before, we discussed line protocol. So line protocol is how data is ingested into InfluxDB. And we can break it out into a measurement; a tag, which is the InfluxDB tag; and a field, which is your value. So a tag is essentially metadata, and a field is your actual changing values. So in this instance, our measurement is Kepware. That’s just our general measurement for encapsulating the data. The tag, the metadata here, is we have an arbitrary tag, say something like factory, that describes a little bit of where the data comes from. And then we have our field. And as you can see our field here is the full path that we outlined from InfluxDB. So that is valid line protocol. Looks okay, but we can do better, which is great. So that’s getting stored within the factory data bucket of InfluxDB.

Jay Clifford 00:32:30.817 But what I really want to do is I want to be able to drill down into that data and store that data more efficiently in InfluxDB. So I can do that using a task. And what I’m going to do is I’m going to break this string up here, this field string, into three different tags - sorry. Two different tags and then one field. So I am going to split it up into channel, device, and then the actual field name itself. So in this instance, we have the channel equal to bender and then we have the device equal to bender and then we have voltage, which is our field for that. And you’ll see why this is important when I jump back into InfluxDB. So essentially what the task then does is it sends that data into a new bucket, which I’ve called factory data downsample. And as you can see, the line protocol is different. We’ve split it up into Kepware with two additional tags now. So we have the factory tag still but we also have the channel and device tag, along with the - sorry. That was my bad. I should have noticed that on the slide. It should be voltage, not current. [laughter] Sorry. The field hasn’t dramatically changed. But that should be a voltage. And then, of course, the timestamp.

Jay Clifford 00:33:42.271 So let’s have a look at this task within InfluxDB. So if I jump out of here, and I jump into here. Oh, sorry. Wrong task. So here we have our task. So what I’ve done is I’ve set this task schedule to run every hour. So you can imagine that’s a bit like a cron job which runs and iterates through. So if I edit our task, you can see exactly what I’m trying to do here. So this is with Flux, our functional programming language. And you can see that I’ve built a function to get the tags. I basically used a string library, where it means I can split the tags using - well, I mean, most people would note this from JavaScript, if they’ve worked with that, or Python or any sort of standard programming language. String splitting is quite a normal process. And then I can return an array of those splits.

Jay Clifford 00:34:39.835 So what I do from there, is I’ve created a variable called raw machine data. And then I’ve queried from my bucket from an arrange of the last success when this task was run. So every hour this task will run. So I only want to collect the newest data from when that task was run, and that’s the ability that gives you. I then filter for the Kepware measurements. I only want data from that measurement. And then I’m going to aggregate. So what I mean by aggregate is I’m going to essentially take the - so I’m going to - so I’m going to run - I’m going to take the last window of data, so a minute’s worth of data, and I’m going to take the last value from that minute. But you can run different types of aggregation. You could run a mean aggregation. You could run a min or max aggregation on that data. But just for the simplicity, I’m going to take the last value that’s come in from that minute window. And then I’m going to yield that, which just means show the data. And then what I’m going to do is I’m then going to map those new columns to my data, which is that new metadata column, which is the channel, device, and field. And then I’m going to send that data to the new bucket, which is factory data downsample. So I can actually run this task manually, which I’ll do now. And low and behold, the demo gods will be with us. What you can see now is it started, and you can see our task has successfully completed and run.

Jay Clifford 00:36:13.214 So now let’s have a look at how our data has changed in a new dashboard. So if I quickly jump into Kepware machine data here, you can now see I can now split - I can now drill down into my machines at a much sort of more granular level. So we now have our channel, our device, and the factory. So since Kyle’s in the USA, we’ve got the USA factory up and running on his end. So what I can now do is, if I could select channel, I can now go down to welding robot. And if I change welding robot here, we now see the granular data just for the welding robot. And this allows us to store the data more efficiently, build more standard templating with our dashboards, and allows us to query data more efficiently as well.

Jay Clifford 00:37:03.094 So in terms of the dates we have here, I would say in terms of schema, this is where we want our data to be. And so really the architecture is up to you. You could do this re-schema design with Telegraf, the original way of doing it. But if you want to do it the new way, which is connected directly, you can now do this all from within Influx and change the schema on the fly within Influx. What we’re seeing is a lot of people now will run InfluxDB OSS locally. Ingests all the raw data from Kepware there. And then if they want to have a more global coverage for their data, you can actually offload the downsample data from that task to InfluxDB Cloud, and then that gives more people a variety of access to it. So that to() function I used to push it to a bucket, there’s actually a new feature where you could use a remote to() to send that to a completely - to send that to InfluxDB Cloud, allowing you to downsample the data from a much higher level. Yeah. And so that is the feature, and that’s my side of InfluxDB for that part of the demo. So I’ll quickly jump back into our slides. Let me jump here and let me chuck this back on. Does that look okay?

Kyle Carreau 00:38:27.005 Looks great.

Jay Clifford 00:38:28.643 Sweet. Awesome. So some of the gotchas. What I wanted to do was just to go, as me and Kyle were working on this project together, I wanted to sort of cover a few bits and pieces that we noticed while we were putting the demo together just so you’re aware when you have a play yourself. So could you explain quickly, Kyle, what every scan versus data change is?

Kyle Carreau 00:38:50.661 Sure. Yeah. And that’s a great question. So within the Kepware context, especially when you’re using the IoT gateway, there’s sort of a few things going on. So one is there’s the scan of the Kepware driver getting data from the field device. The PLC. That’s one scan. But then separately, the IoT gateway essentially acts as, we’ll call it, an internal client to Kepware, [inaudible]. And then, depending on the next behavior, and I think you kind of saw it when I brought up the IoT gateway, but you have the ability to change of when that data gets published to the cloud or published to somewhere. You can do every scan, which is essentially every time Kepware is reading or rather the IoT gateway is reading that data from the drivers, or you can do it upon data change. So you can set, essentially, to a certain percentage of, “Hey, when that data changes to a certain percent, then publish that data.” Different use cases for both.

Kyle Carreau 00:39:55.795 I would say there’s a lot of variables that go into that. One being is, how stable is your data? How often do you need that data resolution? And honestly, how expensive is that data? And what I mean by that is most cloud companies are making their money not by selling you the platforms, but by the amount of data and the amount of gigs that are being sent out. So what I mean by that is it might behoove you to look at, “Well, hey, I’m trying to monitor a tank level, and I have a really high-end sensor that can get really precise that tank level.” Well, maybe I don’t necessarily care that tank level goes from 90% to 90.002%. Maybe I want to change that where, “Hey, every 2% change, I actually want to send that data.” You can do that. And again, it’s going to depend on all the applications, but it’s figuring out what is best for you. So that’s something to keep in mind there.

Jay Clifford 00:40:56.276 Awesome. Thank you for that, Kyle. Spot on. So another thing that we noticed was debugging. So since we’re dealing with two different platforms here, making sure that we have the right level of engagement to understand what might be going wrong is something we’re still improving on. But the best way to check on debugging to see if there’s a connection problem that you have or a data format issue is you can actually, there’s two ways that I recommend. First of all, I recommend sending your data from IoT gateway to something like Postman. And then you can see what the data format looks like and make sure that the line protocol that’s being generated by the template actually looks like line protocol. I fell danger to that when I was working on getting the connection up and running.

Jay Clifford 00:41:48.884 The second part is we actually have a monitoring bucket within InfluxDB itself. So any time that a failure occurs, if you get sort of like a 403 error or a 402 in Kepware, then definitely check InfluxDB’s monitoring bucket. Because normally we flag all of the logs in there to allow you to know exactly what’s going wrong. And that leads me to my next point. Probably the biggest gotcha that normally gets everyone at the moment, and this is purely a line protocol thing rather than a Kepware thing is at the moment spaces are a danger when it comes to field names. Because essentially when you create line protocol, we use a special escape character to show that it’s a space. And so at the moment, you can’t use that escape character. So the best way we’ve found around it is actually just within Kepware, making sure that you use an underscore or bringing the letters together and use sort of camel casing just to make sure. But that would probably be the gotcha there is if you’ve got spaces in your tag names, that’s probably leading to an ingest error in InfluxDB.

Jay Clifford 00:42:56.579 And then lastly, but not least, I think we solved a lot of this with talking in the last demo is that tag creation. So you can create a lot on manual tags within Kepware, which is awesome. So those static tags, like those factory tags, all that meta information, all that good stuff can all be generated from within the Kepware template. But if you want to develop some more reactive tagging based on some of those other machine paths that we’ve seen, then yes, you can use tasks to manipulate that data using Flux.

Kyle Carreau 00:43:25.224 Yeah. I will say, just in general for those because it sounds like there are a few folks relatively new to Kepware, and I want to make sure we level set too. One is, I guess, embarrassingly, yeah, that space thing took us a little too long to find out, but we did get around to it. But one of the cool things about Kepware is that when you name a tag within Kepware, that doesn’t actually affect what’s going on in the PLC. So, essentially, when you set up a driver and you create a tag, there’s two fields. There’s the tag name, which is a Kepware object, and additionally, you have to set the address, which is the actual physical address of that device. That might be, again, a 40001 Modbus address. So you can call your tag name in Kepware whatever you want, space or no space. That’s not going to change the address of the device.

Kyle Carreau 00:44:21.057 And what I really want to touch on, though, is the tag creation because I think this comes up a lot with folks who aren’t, I guess, super familiar with the OT space, and it’s worth mentioning. So Kepware does have the ability to connect up to virtually anything out on the plant floor. The problem is you have to know for the most part, and I’m going to Asterix that, but for the most part, you need to know what those tags are. So that might be working with the PLC programmer to have a CSV file with those tags. That might be going to your HMI or SCADA platform and downloading that tag database. That’s another way to do it.

Kyle Carreau 00:44:58.936 We also have a really cool feature in a good portion of our drivers called Automatic Tag Generation, which actually is a service that Kepware runs that will go into the PLC and it will actually just download all those tags. The danger in that is, “Hey, it’s great that you can do that, but you don’t necessarily need all those tags.” So perfect example, in our device lab here we have a bunch of control logics, and a lot of them have 97,000 tags that we can get access to, which is awesome. But really if you’re doing OEE type of stuff, you probably need maybe 100. So it’s a good way where, hey, if you don’t know what you’re looking for, just get everything, and then you can kind of sort it out as you need to. But just wanted to level set on that.

Jay Clifford 00:45:43.225 No. Definitely. No. We had a customer once where we downloaded all their tags, I think, for a yogurt plant, and it was like 11,000 tags. And you were like, “I don’t think we need all these tags.” [laughter] They just want to know how much yogurts been pumped today. [laughter]

Kyle Carreau 00:45:58.228 Yeah. How much yogurt? Is the machine on? Two tags. Yeah. [laughter]

Jay Clifford 00:46:03.086 Brilliant. So I guess we can sort of sum it up. And this is where Kyle stole my thunder a little bit earlier, but I’m excited to announce. So what we really want you to do is basically get your hands on it and get your hands dirty as well. So I’m really excited to announce that, what we’ve done is we’ve created an Influx - sorry, a Kepware template page within the Influx community. And this will provide all the instructions of what we’ve just covered to allow you to start basically get up and running with Kepware and Influx really quickly. And what Kepware’s actually provided is they’ve actually provided the sample simulation factory project which will allow you to load that directly into Kepware and simulate an entire factory. So you can actually just download Kepware, run the trial, use the project, and stream that data directly to InfluxDB to see if it’s a good fit for your project. And you can do that all without needing to have an entire shop floor available to you. Maybe you’re just interested in giving it a go. This is a great way of trying it. And within that repository as well, I’ve also provided my InfluxDB template. And so that allows you to auto-upload that template to InfluxDB OSSS or cloud. And that will allow you to generate all the buckets, those tasks I showed you, and all the dashboards with basically one click of a button. So you don’t have to do any of that configuration yourself. Anything you want to add there?

Kyle Carreau 00:47:35.944 Yeah. I’ll add in as well, I think the obvious thing here, too, is you do need to download Kepware. You can do that off of our website. The only thing we ask is you create something called a My Kepware Account. It’s a way to download and manage all of your licenses. But we do have a free - when you download it, you get the entire product. The entire thing runs on a two-hour demo timer, which can be reset. You just restart the runtime. So really, we just want to make it as easy as possible to get your data up and running. We can talk about pricing; we can talk about the packaging way later. Let’s just get you up and running. Let’s get you what you need. Let’s prove it out and then we’ll go forward from there. If you do need something longer, let’s say in your plan, “Hey, we’ve got this project going, but we actually want to collect 30 days’ worth of data,” let us know. Reach out. More than happy to set you up with a demo license.

Jay Clifford 00:48:31.133 Awesome stuff. Yeah. That was me. That was me resetting the two-hour time license just to get more data into InfluxDB. I was like, “Kyle, we need more data.” [laughter] Fantastic. And I think we’re on to questions. So, Caitlin, have you got any other questions?

Caitlin Croft 00:48:47.831 Oh, we have tons of questions for you guys. You guys are super popular. Full disclosure. I don’t think we will make it through all of the questions. So not to put you guys on the spot, but maybe we can do a follow-up blog or something that addresses all of people’s questions. So the first question that I can find here, and I’m just going with the first one I see here. As far as I know, PTC could run on an on-prem environment, as in the factories. Some production companies choose Windows for Corporation OS vendor lock-in case. In that case, the servers run on Windows OS. What is the performance of InfluxDB on Windows servers? We are working with PTC and the DB preferred is Postgres instead of Influx because of servers on Windows.

Jay Clifford 00:49:45.659 So to answer that, essentially, we run the same testing between Linux and Windows on InfluxDB. I think we can provide metrics on how well InfluxDB performs in different platforms. So I can definitely follow up with our product management on that and see what we can release on that note. But you have to understand it’s the same architecture and the same way of how we store data on disk as how we would on Linux and on everything else as well. So we always recommend you use something like an SSD. You can use an HDD drive. But it makes things vastly more efficient and faster when storing data o

n Windows that way. It’s all based on a go binary, so it’s all based on that same technology. So your efficiency is there no matter what you’re using it on. And Influx is designed to run on embedded devices. Sorry. I say embedded. On lightweight devices, like IT gateways. So you shouldn’t have a problem running it on a Windows-based server.

Caitlin Croft 00:50:48.714 Cool. How does Kepware manage Modbus protocol connections? What is the difference between Telegraf and Kepware? Does inputs.modbus work well, like Kepware?

Kyle Carreau 00:50:59.840 So it sounds like it’s a split one here. So, Jay, I’ll take the first part. So I guess that’s sort of a loaded question. There’s a bunch of different ways I could answer that. Brian Gilmore, thank you for the shout out, I’ll just say what you said there. Loud and proud Kepware is the option for Modbus. Use it. It sounds like Influx has basic support, which is awesome, but it’s not 30 years mature. And quite honestly, we see that with a lot of our partners, whether that’s Rockwell, whether that’s Ignition, whether that’s Influx. Where even those partners are like, “Hey, we’ve got these drivers, but go use Kepware.” And I hope I’m not stepping out of line there, but ours is very, very rock solid. And there’s a lot of different ways to optimize that. We actually have a whole sort of documentation around optimizing your project. So if you need a specific performance, whether that’s scan rates or the amount of data going in at a certain rate, we can absolutely help out with that. We have a lot of granular controls we can use with the driver. Give it a shot yourself and I think that’s the best way to do it. And I will say this is going to help answer another question. That Modbus driver is available on our Linux product, which is also dockerized or containerized, which I think was another question in there.

Caitlin Croft 00:52:15.941 Cool. Jay, did you have anything to add in there?

Kyle Carreau 00:52:21.103 Well, no, and I have to agree with Kyle on that. We look at the separation of products here, and Kepware is designed to deliver in that space. And for me, coming from my sort of automation days as a sales engineer, I would always feel more comfortable with a product that with that 30 years birth of experience dealing and delivering with those machines, even sort of making sure those tags are available. Telegraf is great for prototyping for Modbus and collecting that data, maybe from one or two machines that you know the tag structure of or the address structure of Modbus. But you have a much more diverse support when it comes to Kepware. And that’s what you’re paying for essentially is that hardened diverse support from Kepware when it comes to Modbus.

Jay Clifford 00:53:07.428 And it goes back to the ecosystem, right? I mean, it’s let’s get the best of breed. And Kepware is all about the drivers. And I can tell just from this, Jay, I probably understood 70% of what you were talking about. Anything downstream I got you, but anything above [crosstalk]. I’m aware of what’s going on, but I’m not the expert.

Caitlin Croft 00:53:26.608 Okay. Cool. Someone else is saying our use case would be to hold thousands of measurements in InfluxDB for the life of an asset. Is InfluxDB tested to hold data for that long? What are the constraints in HDD space on the host?

Jay Clifford 00:53:46.254 So if you plan to hold data for an entire lifetime device, the short answer is yes. That obviously depends on how big your disk drive is, how much you’re storing here. But it really depends on, you have to be careful with schema as well if you can build out an appropriate schema, and you can follow the advice within our docs here to build a proper schema. So first of all, when you say measurements there, it would probably be a few measurements, maybe a measurement per device, and then you could split it up into tags and then fields. And you also have to worry a little bit about cardinality as well. But I won’t get into those subjects now. I think that’s too deep for this call. But just have a look at the schema best-fit design and that will show you how well we can optimize storage of that data. And reach out to us in the community with basically some more information with regards to your machines and how many tags you’re looking and the type of data you want to store, and I can work through it with you. We have a bunch of other DevRels in the development team. We can look through your data and give you some great advice on that.

Caitlin Croft 00:54:53.320 Cool. Let’s see. Does the MQTT consumer support Sparkplug payloads or just string ones?

Jay Clifford 00:55:06.552 I would have to check up on that. So we base our MQTT input plugging on basically a standard Go library from MQTT. I think we support version 3.1 of MQTT. I know Sam Dillard and everyone is going to crucify me in the chat, so maybe they’ll be able to answer it, so. But you should be able to pull in either JSON string value data and serialize that directly into Telegraf, but I don’t know directly off the top of my head about Spark in that regard.

Caitlin Croft 00:55:44.912 What’s your experience on OPC UA handling high-frequency data streams like vibration data?

Kyle Carreau 00:55:54.430 I guess that’s for me. I would say personally, not a ton specific to vibration data. But what’s really good is that our application engineering team, similar to Jay and myself, but probably a little bit more Jay’s speed, but they’re really, really smart and they’ve got years and years of experience doing just Kepware. So I would say, especially in the UA space, which has traditionally been very industrial, I’m sure we’ve handled it before. I have very little doubt about the performance of Kepware. So I would say if it is something that you want to discuss further, I can probably drop an email in the chat. We’re probably better off in a follow-up email. Caitlin, I can give a generic email to send that right to our application engineers.

Caitlin Croft 00:56:40.701 Yeah. And if you guys have follow-up questions for Kyle and Jay, everyone should have my email address. You guys can always email me directly and I can move Kyle and Jay in. Jay, Kyle, do you have a little bit more time? I know we’re right at the top of the hour, but thinking just since there’s still lots of people and I’d love to get more of these questions answered.

Kyle Carreau 00:57:02.835 Yeah. I can stick around.

Jay Clifford 00:57:04.001 Yeah.

Caitlin Croft 00:57:04.483 Cool. So this is kind of an interesting question. What type of departments do you typically see adopt your product?

Kyle Carreau 00:57:12.467 Is that for Kepware or is that for Influx?

Caitlin Croft 00:57:15.793 It does not say. I think it might be interesting to kind of highlight both.

Kyle Carreau 00:57:19.462 Sure. I can start with Kepware. Yeah. So departments, that’s interesting. I would say, in general, it’d be more the OT space. The operations technology space. Where within that we’re found all over. I mean, automotive, food and bev, life sciences. We have a lot of power utility drivers. We’ve got a lot of oil and gas drivers. Essentially, anywhere where you need to get industrial data, you’re most likely going to find us. I think we did, and no one’s here to correct me, but I think it’s 70,000 plus installations of Kepware that we know about worldwide. So we’re used just about everywhere. And what’s been interesting, especially with doing webinars like this, we’re finding that a lot more folks in the IT or IoT side of the fence are actually starting to discover and use Kepware more now.

Jay Clifford 00:58:15.649 Yeah. And I would tag on is that’s the interesting thing about the ecosystem. You have us that sits there as system integrators, or, sorry, in my old days which take Influx and take Kepware together and piece it together as part of their own platform themselves and sell it and resell it on as their own solutions for customers. So it’s kind of crazy. I see us a lot as Lego and people are just building us as part of a Lego sort of tower solution that best fits solving a customer’s problem on site. So sometimes we don’t always see the end customer. We see those integration partners that are delivering to the end customer. But yeah, just on that note, from influx’s point of view, our primary space that we like to be in is obviously within IoT. Industrial IoT. We see a lot within the DevOps community as well. Sort of server monitoring, especially. Looking after those pipelines and looking after metrics collection there.

Jay Clifford 00:59:14.892 But we also have lots of really interesting use cases when it comes even just down to sort of geodata. We’ve definitely seen people monitoring say, I don’t know, sort of bird flocks over time where it comes from different spaces. We’re quite heavily within the eCommerce and the fintech space as well. So this is where the whole idea of the TICK Stack came about because you can analyze a lot of your financial data there. And then, of course, even random stuff like farming. People use it to look at crop growth and all that good stuff there. So, yeah, we’re spread far and wide, a lot like Kepware is as well. And most people that pick up Kepware or Influx, I’d say, are the builders who we’re talking to now, which is awesome.

Caitlin Croft 01:00:04.127 Yeah. Also, interestingly, I love getting to meet community members and seeing what they do with InfluxDB and other technologies like Kepware. And the thing that’s interesting, talking about typical use cases, is there’s a ton of people who start using InfluxDB at home by simply monitoring their nest or monitoring their gardens. And then they end up going, “Hey, this is cool.” And then they start using it at work, and then you never know what they do for work. So there’s so many other typical DevOps use cases, but then lots of IoT and especially industrial IoT, so. All right. I think Kyle, this is going to be a question for you. I’m sure Jay will want to chime in. But there’s a few questions around, how would you compare InfluxDB to the standard industrial historians like OSI Pi, Aspen 21, or process historians from Siemens? And there was another question around why InfluxDB instead of a relational database?

Kyle Carreau 01:01:08.744 Sure. I can take a tackle of that a little bit. And again, this is more my personal experience. OSI Pi, AspenTech, all those are in fact historians, which of course, is just OSI Pi under the hood. They’re great. I mean, they do well, and they do the job of what they need to do. Their issue, though, is that they have to be on site. They’re very heavy. And they can sometimes be a bear to work with. And that’s at no fault to anybody. I think that just, at the time, that was the best technology we had. It was a big bear. It wasn’t very flexible, and it was hard to kind of do stuff. Moving forward, at least my very limited interaction with the Influx database, it’s really flexible. It’s really easy. The cloud-based thing makes it really awesome. I know there’s a lot of folks that are sort of hesitant to that for a number of reasons, I’m sure. But I found it to be really easy to work with. And then you’ve got a great team supporting the product behind it as well. So that’s been my limited experience. I can’t necessarily talk to the technical specs anything more than that, but from a high level, that’s sort of my viewpoint of it.

Jay Clifford 01:02:24.601 Yeah. And no, I fully agree on that. When you look at OSI Pi and those types of historians from back in the day, we call it the time to automate Influx. Those takes a lot of expertise and a lot of training to get up and running, and normally take a lot of hand cranking from the company itself. What we really drive for at Influx is for people to be really autonomous and approachable to the platform, and go, “Okay. With a few clicks, I can get up and running and see my data,” which I’ve seen here. And again, especially dealing with InfluxDB OSSS - sorry - it allows you to get up and started for free. I mean, you can do a proof of concept, get going quickly and scale fast, and then come talk to us about an enterprise-looking solution if you wanted to.

Jay Clifford 01:03:15.305 But that’s the idea. I think the industry now it’s a lot of solutions fail because people have to invest heavily at the start on lots of big, heavy historians and everything else like that, and it’s not quite worked out for them. So this is where the power of open source comes in and lets people play quickly, scale fast, and drive forward. To answer the other question there about why not use a relational database, what I’ve found in the past is you can store time series data within a relational database. You can do it. With Telegraf ourselves, we don’t shy away from sending data to other historians. I mean, you can use SQL output plugin. I think we also have some from AWS there as well, like Firebase and stuff like that. So we don’t shy away from sending data.

Jay Clifford 01:04:08.237 We know there’s a variety of other databases out there, but we’re designed from the ground up to deal with high-frequency volumes of data and compress that data in an efficient manner, where a relational database just doesn’t have that ability. And that’s based on schema design, how that data’s stored on disk. I really highly recommend; we have these videos called Meet the Developers. And there’s one called TSM or something like that which is basically about our TSM storage engine. Go check out that. It’s really great. One of our great software managers there talking about how we store data on disk and how we’re more efficient than relational databases in that way. So I highly recommend go check out the video for more info.

Caitlin Croft 01:04:49.926 And those videos are available on YouTube, so if you want to check it out, go find the InfluxData YouTube channel. I will also say, and this kind of goes into one of the previous questions, a lot of times when people start out collecting their time series data with a time series database, they don’t know what they need, so they end up collecting a ton of data at very high frequency. Someone was asking about data retention. And yeah, you do want to keep your data for a while to have that historical insight, but part of our platform also has something called Flux, which is a querying and scripting language. So you can downsample the data and definitely shrink it down once you kind of have that historical set of data already available to you. So a lot of people will start collecting their timestamp data at very granular intervals, and then over time, they realize they don’t need it at that level. So obviously, you can reset the intervals and of course, downsample the data that you already have just to free up memory, so.

Caitlin Croft 01:05:57.453 All right. I think we’re going to stop there. I know there’s still a ton of questions, but I want to be cognizant of the time. And I know there’s been a lot of questions here, so we’ll try to answer them in a blog or something. So I really appreciate everyone joining today. Thank you, Kyle and Jay, for joining me today and presenting your knowledge of Kepware and InfluxDB. And also, we have - in case you guys hadn’t seen - Brian Gilmore whose part of the InfluxData team, he’s our PM for IoT, he’s been in the chat answering people’s questions. So thank you to Brian as well. Really appreciate you all sticking around. This webinar will be available for replay later today or tomorrow and the slides will also be made available. So I know a lot of people wanted to review that, so. Thank you, everyone and I hope you have a good day.

Kyle Carreau 01:07:02.665 Yep. Thanks, everyone. Thanks for having me, Influx.

Jay Clifford 01:07:04.394 Thanks very much, guys.

Caitlin Croft 01:07:05.997 Thanks.

Jay Clifford 01:07:06.079 [crosstalk].

[/et_pb_toggle]