LineMetrics uses InfluxDB Cloud to power their IoT platform
In this webinar, Reinhard Nowak, CEO of LineMetrics, shares how they built an end-to-end IoT platform to help businesses gain insights from their products and customers. At the heart of their solution, LineMetrics uses InfluxDB Cloud to gather metrics and events (time series data) from their customers machines with the use of sensors, graph the data in their cloud and send information to their mobile app to allow their customers to watch the sensor data and take the appropriate actions. This end-to-end platform is a complete plug-and-play solution that allows anyone to start gathering useful IoT data about any device without the heavy investment of a traditional IoT platform that also requires the support of an IT staff.
Watch the Webinar
Watch the webinar “Customer Case Study: LineMetrics uses InfluxDB Cloud to power their IoT platform” by clicking on the download 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 “Customer Case Study: LineMetrics uses InfluxDB Cloud to power their IoT platform.” 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: Chris Churilo: Director Product Marketing, InfluxData Reinhard Nowak: CEO, LineMetrics
Reinhard Nowak 00:00.407 Perfect. Thanks for the invitation. And it’s a pleasure to tell you something about LineMetrics, what we are doing, how we ended up in the IoT world, how we ended up using Influx, and I’m really pleased about that. Nice to have you. Greetings from the sunny Austria. And maybe just a little bit about the background of LineMetrics, who we are, what we are doing. So we started LineMetrics about five years ago. And the reason why we did so was, quite a simple case, I first ran background in automotive industry, all these monitoring tools, and what we learned there was that there are monitoring solutions since decades of-a lot of years. But these are all really huge installations, always IT department-driven solutions, etc. And what we found out, or what I saw, was that a lot of people working on the machines, hands-on, they wanted to improve things, therefore, they had demand for more KPIs sensitive data, etc. But they said, “I need to go to my boss and get some budget. I need to start a new project, get to the IT department. It’s all too complex.” And they just ignored the problems and meet the workers’ fee. They did it before and things did not improve. This was a real important lesson where we decided to change things. And so what we ended up with was a solution where we had to focus on the value in front, and we built technology because we had to. And so that’s the reason why we don’t call ourselves something like an IoT platform. I will show you in a second, we are a complete industrial IoT company, but we don’t position ourselves this way. We call ourselves real-time asset monitoring. It means if you are in an industry and you have some physical object, I will show you, in a couple of minutes, we make it really easy for you to monitor things without any IT knowledge, and make things really simple.
Reinhard Nowak 02:25.300 So maybe just one thing about what was the reason why we started the whole thing-there is always a pattern. Or there was a pattern in industry when it was about-when companies were about to acquire sensitive data. On the one hand, they wanted to become more efficient. I’ve a strong background in manufacturing industries, but what I’ve learned is absolutely valid for any kind of industries. So you need data to monitor to make better decisions, to control your decisions, and just acquire the right kind of data. And on the other hand, there’s a-I don’t know if it’s only-I guess it’s a huge topic all around the world and it’s all about new teaching services, digital transformations, whole industries are completely reinventing themselves. And there we see a huge demand in the market. So what we have seen, as I said before, from my opinion, it was really quite complex for a non-technical guy-the man on the machine, the facility manager, etc., project manager in a company-to monitor stuff because it was quite complex, it required IT knowledge, you had to develop stuff because all of that-I was in the IT department, so I can say that if the IT department gets involved, it might get a little bit expensive for the shop floor guys, for example, who just want a few KPIs to solve a problem. And a lot of products out on the field are not that flexible. Just as a small example, if you want to optimize your machines in a manufacturing environment-on the one hand you want performance KPIs like number of downtimes etc. On the other hand, you want energy efficiency data. There are not so many software solutions where you can monitor both and compare them both because, for example, you want the energy consumption a part could use. So there is a lot of things involved.
Reinhard Nowak 04:43.212 And yeah, that’s exactly what we were trying to solve. We wanted to make the whole monitoring so simpler that the customer has not-they can fully focus on the value and don’t have to care about IT. And this requires a complete stack of technology, completely new business model, and that’s what we have built over the last couple of years. There’s just this slide-the reason why I left it there is because what we see is that monitoring and Internet of Things is the basis for all these monitoring, and big data, and analytics, etc. It’s driving all industries. So if I’m talking about-I could not tell you a special industry where we’re making most of the revenue. It’s in most of the industries listed here, we have projects, we have customers, we have partners, etc. because this is a topic which is affecting all the industries, and it’s really popping up and breaking up now. Even in Middle Europe. I think we are a little bit conservative here, but yeah, interesting times.
Reinhard Nowak 05:57.947 So what’s LineMetrics? LineMetrics, as we said, we have strong focus to make monitoring and analytics for our customer really simple. And in order to do that, we say it and maybe it’s [laughter] -in the early days when we founded LineMetrics, there was always the idea. I wanted it to enable some guy on the machine to monitor the KPIs on the machine for $49 a month. The answer’s a service, including all the devices required. So we thought, “It’s quite easy to build a software service through the cloud service. That’s easy. But how does the guy get all the machine data, the sensor data into the cloud?” That’s quite complicated. He needs a program, some kind hardware PLC, etc., PLC with network stuff.” And then we said, “Why don’t we just build hardware as well?” And then we said, “Why don’t we just integrate GSM communication worldwide?” And then we said, “Why don’t we offer this complete stack as a service?” So that’s where we ended up. And after a couple of years, I think our tech is quite impressive. We are still a small team, but I think it’s quite impressive. So on the left-hand side, we have our hardware, the implant gateway. We learned from Cisco that that’s called H Gateway. So that’s embedded, Linux PC, a lot of technology in there. We are trying to calculate as much information near or close to the sensor as possible. Why? Because we provide data as a service. We provide the whole stack as a service, which means it covers the worldwide GSM communication.
Reinhard Nowak 07:40.601 And so we tried to process as many data at the distributed hardware, and send data via GSM, as little data as possible via GSM. Then we extended the hardware to a wireless mesh component. These Sens adapters for industrial sensors, they collect the data from the sensors and send it via a radio network which is built by the LineMetrics box, the machine-to-machine gateway. And the LineMetrics box collects the data, compacts it, derives some things, and then it streams it real-time up to the LineMetrics cloud. And the LineMetrics cloud is really the core of the whole system, we will see in a minute, and we will take a look at the architecture there as well. And then we found out it’s not really all about the sensor data and charting. It’s much more. You need to transfer knowledge to the customer. If there is an alarm, why don’t we also give them a chance to see the solution to this alarm, and guidelines how to fix it a little bit easier? And so we built mobile apps where you can, for example, using QR codes on your physical devices, you just scan them with the LineMetrics app, and you have all the information. You have all the context information of the machine. You have all the values, all the KPI, all the historical data, all the guidelines, documents, etc., all you need at your fingertips. Then we found out, okay-it’s interesting that the data will be or can be processed by existing legacy IT solutions. So of course, we built a lot of open API SDKs and made it easy for customers to store data via the APIs, but also query the data from the APIs and extend our solution. And I think one of the biggest USP is that we tried to make the whole stack as a product, and this means it’s so simple. Currently, we have about 1,000 devices out in the field, and we have not set up-we didn’t do a set up at any customer. The customers are setting up the solution by themselves in a couple of minutes, and connecting sensors, machines, windmills, a lot of different things. And in order to do that, of course, we need to provide a lot of content, a lot of guidelines, and we also partner with a couple of sensor vendors. And we integrated their sensors with all the parameters and datasheets into our database. So, for example, if we want to monitor energy consumption, you just select an energy measurement device for a partner, and then you just say I want the currency, and I want the energy consumption. And on phase one and different phase shifts, etc., you just click them in a wizard, select “Store” and you are good. You have the charts. You have the data.
Reinhard Nowak 10:39.744 So that’s the complete stack we built. Why and what’s the use cases? Why did we do that? As I said before, typical physical assets are manufacturing devices, for example, buildings, tanks, vehicle, windmills. That’s all examples we have monitored, and much, much more. And typical measurement units are energy, for example, parts produced, temperature, machine states, fill levels of tanks, but also, air quality, etc. It’s really, really a weird mix, and what makes it so interesting is that there is a pattern for the use cases, and the benefits and the values the customer has from the data he tracks. So it’s all about-most of the time, it’s just about efficiency, energy efficiency, performance, gains. For example, machine, if you’re talking about buildings, of course there is energy efficiency. For example, we have customers where we monitor the temperature quality at the point of sale, where food is sold to a customer, and the producing company wants to make sure that the food quality is completely monitored until the food is in the hand of the customer.
Reinhard Nowak 12:04.354 And so there are a lot of different use cases, you can read that. And we can talk about some of them in the Q&A afterwards. If you have questions, I would love to hear them. We get asked this all of the time, “Okay, you’re monitoring assets, but what’s different to a lot-there are so many IoT solutions, IoT platforms out there. What makes you different?” And so what we’ve tried to do is we try to be a one-stop shop for our customers. It’s really easy to get the whole solution out of one hand. No need to deal with interfaces, etc. A customer is able to monitor, or if he has a machine or a sensor, or whatever, if he calls us, he has all the devices two days later, and maybe after one or two hours, he has the first data in the system and can start looking at data, optimizing things, etc. So it’s kind of plug-and-play. Of course, there’s always a possibility to get better. We’re working hard on that, but we are-I think for an IoT solution, which is or has been quite complex in the past, we are quite plug-and-play already.
Reinhard Nowak 13:22.943 As I said, it’s really easy to integrate and use. It’s really important because, for example, if you think about energy consumption or energy efficiency consulting, the guys who have all the knowledge about energy efficiency tasks and suggestions, these are not always the guys who have a lot of experience in sensors, but they have absolutely no experience in setting up some kind of server and IT stuff. So even for them, it’s quite simple to get going and don’t spend too much hours in a project at the customer. Of course, augmented phase is really important, keeps the systems extendable. And I think one of the biggest USP is that we are Pay As You Go. So you can rent the whole solution, including the monitoring, the data logging device, the LineMetrics box, worldwide communication, and the cloud service, mobile, everything, up to 10 sensors for 28 a month. So I think that’s a quite cool USP and allows companies to try things and scale up as they need. And we have seen, for companies, that’s really cool.
Reinhard Nowak 14:38.977 So I will go at that really quickly just to give you a short impression. That’s the LineMetrics box. It looks quite simple, but as I said, under the hood there is embedded Linux. There is a lot of hardware we have developed, we have designed. We have quite flexible inputs. We have all this radio communication for the Bieler sensors, we have the sensor added to GSM communication which will be upgraded to IoT shortly. And the cool thing is that you just power up the LineMetrics box using the power supply. One minute later, it’s up and running or you see it online in the web portal, and then you go from there. You just say, “Hey, input one, I need the part counter.” And within three-step result, it’s configured. If you say, “No. Oh, no. I need to track the condition of the machine if it’s running or not.” You just wire up an output of a PLC. You just reset the input three-step result, and you’re good. Same for an industrial sensor. Typically, you see the units there. So typical units are the 0 to 10 volts sensor. It’s really common in the industrial environments. And you just connect it. You just say, “Hey, it’s a temperature zero.” Voltage, it means zero degree. 10 volt means 50 degrees, for example, Celsius or Fahrenheit, or whatever. And you say, “Okay, I want to track it once a second. I want to track it with once a minute.” And you’re safe. And the information is pushed down in real time to the LineMetrics box, and then the data’s collected, and you are good from there. You can also start adding thresholds and manipulate the data, whatever needs to be done there.
Reinhard Nowak 16:25.839 I just saw and it’s like they’re still-the limitation for the European Union, of course, it’s not true anymore. We switched our provider and we built our worldwide communications, flat-rate included. And that’s the measure sensors I talked about. On the one hand, we provide two types of sensors. It’s an outdoor and it’s an indoor temperature and humidity, outdoor temperature. And there is an adapter for the sensor, and if you can see in the second bottom line, there are couple of interfaces. So there are much more interfaces and there we can monitor-or the customer can connect a really broad range of different types of sensors and it makes it really easy for them to connect nearly everything which is in the building, in a manufacturing environment, etc. And what’s so cool, he can extend it. If he needs additional information, he just orders us a new sensor adapter, wires it up. And he has more information and finds out correlations, for example, if there was a quality problem in a machine. He can find out correlations between temperature inside the machine or maybe inside the manufacturing environment, and the quality of the parts. It’s really easy to do.
Reinhard Nowak 17:49.911 At the beginning, I told you that we have a strong focus at assets and that’s a really, really important thing. That’s the following slides where I talk about the architecture. I show you the evolution about how we came to this. I will also call it product market fit. So what we found out, a lot of companies-you can connect whatever device, for example, Raspberry Pi or more complex hardware devices have protocols like MQTT, and you just stream data, and you see some charting. And of course, it helps a lot and it’s really cool, but what we got from our customers is that if you look at the asset, you need much more information. I just found out that the screenshot is German, but in the middle it says [foreign], which means properties. So in this case, one of our customers, Daemon Environment, they’re-one of our customers is in the oil business. So his customer has a lot of tanks. And of course, he wants to add some information, where is the location of the tank? How many liters can he fill into the tank? What’s the oil, for example? What kind of oil is it? And when was the last time it has been refilled? Who is the guy which you can phone up? Etc. And so on the right side, it’s called [foreign], that’s other streams. That’s the sensor data and as you can see, that’s just one of a lot of information available next to an asset. And on the right side, in the middle, it says [foreign], that’s documents. It’s guidelines, for example. It’s electrical drawings of machines. It’s in buildings, you have all this building documents. And you can extend it to the object or to the asset as well. And the cool thing is if you are inside the asset or next to the tank and you scan the QR code with the LineMetrics app, you have all the information you added there. And of course, there are dashboards where you can see all the original sensor data and also the derived data in a clear picture.
Reinhard Nowak 20:13.042 So maybe just a quick view of how we display the data, and that’s something you don’t have to program. You’re configuring stuff and if you want the dashboard, you just do drag and drop and build your KPIs and your widgets. And so all the UI you see here is out of the box and we try to understand which kind of sensor data. There’s a huge difference. For example, how to display energy consumed by temperature. There’s a lot of differences how you-which KPIs you can get out of them. How you visualize them, etc. And so we built a lot of semantics under the hood. We try to understand what has been monitored based on the sensors connected, and we try to show the right statistics, for example. So as you can see here in this picture, again, still German, sorry for that. That’s a CO2. That’s air quality sensor. And you can define areas. Is the air condition good? That screen, is it mm, yeah? You should open the windows and dry this, I guess, everybody fell asleep already. It’s really bad air quality, concentration is low, etc. So all you have to do is-or you can do is define all these areas. And so you get all the statistics, and if you want to get informed, there’s mail or other ways, get some notifications. If there is an area-if the sensor data is in an area or left in the area, you just click at the area and you just say, “Please inform me if this condition is true.” And so we try to make things really simple to get more out of the sensor data, and we’re just about to release huge extensions here, but until end of June. So that’s exactly where Influx comes into place- that we don’t just acquire data, stupid sensor data, we try to get a little bit of information out of the data because there is some semantics. And now with the help of things like Kapacitor, and a little input from the customer, we try to really get information out of the data and provide the maximum value of minimum impact-or input-on the customer side.
Reinhard Nowak 22:35.603 So maybe a little bit about the architecture. Just follow this. Switch these lights here. So how did we start? We started as always. We’re all driven by-I had all this kind of lean thinking from the manufacturing space. So all their systems are built before they’re placed for lean manufacturing. So I’m a huge fan of lean. And when we started in 2012, which is built in so-called MVP, (Minimum Viable Product). So this was the minimum of a product where we could show things to customers and, of course, to investors to raise some money because if you want to build hardware, and mobile, and high availability cloud service, you’ll need a couple of experienced guys which, of course, are not that cheap. So that’s what we did in 2012-it worked out pretty well. And how did we do that? We just set up-we had some experience in Java and Grails framework. And these were the times where I also hacked most of the code. And we stored the data in MySQL database. And of course, what we did is we spent a lot of time. It was 2012, time series, and all these cool projects. And they were not that popular, as they are right now. They were not the big agent [foreign], we just programmed things because we wanted to deliver some values to our customers. And here was the funny thing, we had all of the hardware and it had Wi-Fi. And it was, for example, one of the showstoppers where we learned if we tried to make things simpler, that’s the reason why we did hardware and the cloud service. And then whenever a customer wanted to get the hardware into the local Wi-Fi, they had to call up the IT department. It took a couple of days. Things got complex and everybody was frustrated. So it’s a typical startup phase where we learned a lot of lessons. Really important phase. And one of the most important things we learned, as I said, LineMetrics cloud was always the core of the whole solution. We found out that relational database is absolutely not a good thing to store the process. Billions of sensor data.
Reinhard Nowak 25:24.157 So that’s something we learned pretty earlier. So what did we do? Spent some time, rebuilt the app. Even still, about 10 people in the company, 2 people working on the hardware side, and the protocols, and the firmware. And a couple of Devs in the front and back-end team. And we tried to get into microservices architecture. We kept MySQL for some core data, for example, accounts that were still stored at-‘Who’s our customer?’-that are still stored in MySQL. Did not turn work out well. We utilized MySQL. We have a lot of experienced guys, and everybody knew from the past so we left it then, and we switched to Cassandra for time series data. And it was cool because we could scale, but it was not cool because we’d have to do all the time series stuff, but on our own. And then we started to build the service in Java and as always, the first prototypes were-didn’t take us too long to build the first prototypes. But then, we started to cluster this thing, to make it highly available, to extend the functionality, more customers, more requests from the customers. And that’s when we found out, okay, it doesn’t really work out. At the end, it worked absolutely fine, but we were just about to build some kind of database, and it doesn’t make sense. There are good systems on the market, and on the other side, we did things like made the hardware completely new, make it more intelligent, and that’s the reason why I put it there. We evaluated protocols like MQTT and found out we need to shrink the data by factor, I would say three to five, related to my MQTT. So we started building our own protocols, and this had a huge impact on the way we communicated between distributed devices and highly-available system. Was always a really, really, really-a lot of tough lessons, but really interesting lessons.
Reinhard Nowak 27:40.275 And so the most interesting thing we learned in this phase is that it doesn’t make sense to build a data service at your own, if you think about Cassandra. So the next logical step we said: “Hey, we know how to deal with Cassandra, there’s Druid.” And we tried to put Druid on top of Cassandra, and I can’t tell you how many months we investigated. And at the end, it was too complex, and we couldn’t handle it with a small team. The reason why this was the case-or also was the case-is that we are already evaluating the focus of the assets. So if you think about the properties of the asset, we have a highly dynamic object model. So you can build assets, you can build templates out of the assets, and you can build instances out of the templates, and if you change properties at the template, it has to change all instances, etc. And all the time series data and the derived data has to follow this pattern. And Druid was really complex to handle and had a huge thing. Maybe we just didn’t work it out well, but it didn’t give us the flexibility to add multi-dimensional data to items and to update previous data, which is really important if you think about if there is downtime in the manufacturing environment. Of course, customers want to annotate information. What was the reason for that downtime? Of course, people want to communicate, document things if something went wrong. If there’s a peak in a chart, of course, customers want to add information. What has happened there? Or start a conversation with an expert of another department and ask them for help, etc. So then we had discussions, and we said, “Now, okay. Let’s start time series data for our sensor values,” and drew it, but store all the conversation data and documentations in Cassandra again. And then we ended up in complex data services and layers, and we couldn’t-and then we said, “Hey, we want to make KPIs out of this or annotations as well. I want to have analytics about the reasons downtimes over the last year.” And then we say, “Wow, we have to do all this clearance stuff again.” And then we say that, “Okay, this doesn’t work out.” And we make a dramatic decision in, I think, near 2015 where we said we need to-I think it was middle of 2015 where we said, “Yeah, we need to start once again and build it once again.”
Reinhard Nowak 30:26.572 So that’s where we ended up and now the architecture which is perfect, which is highly stable, which is highly extendable, where we can provide a product which is open and we will go in that direction of a platform. We can extend to system holds on a micro-service level by plugins and applications, but it took us a while to find the right architecture. And so I will show a quick overview of the whole of the components in a second, but what I can say in the lessons we have learned this week, we still have to account data in MySQL. So it also has a really interesting impact on security reasons. So if there is a security leak in MySQL, people find out who is our customer but nothing else. So we use CouchDB, we will switch to another system, to another database, document or chosen database soon, but until now, there’s CouchDB for the dynamic object model. So we are really hoping it can extend our system, and whatever you see, it’s really flexible. And before this inheritance and template engine, etc. that’s built in Couch. And of course, we store tons of time series data in Influx. And this was an absolutely gamechanger in the way we deal with the time series data. And the cool thing is because it takes away so much pain in the older services, and things we have to care about, with all the TICK Script and Kapacitor, and core. The dev team is still 10 or 11 people, and we could gain so much efficiency and speed up the development, and it’s so cool that we can deliver feature requests to the customer much faster than before.
Reinhard Nowak 32:33.770 So this was a really important step. We have RabbitMQ as a message person for microservices and we still have the Elasticsearch, Kibana Stack for the logging. There’s a really important lesson that we have learned if you build such complex distributed system. I think we spend half of the efforts over the last five years, half of the money we spend, we spend in all the back-end services, logging, monitoring, there’s nothing worse than if you have distributed computing and with the LineMetrics box, we do it there. For example, if the hardware goes offline, and think about if this is mounted in windmills. For example, we have one customer which has a lot of installations. It’s the biggest bank in Austria and we have lots of installations inside the bank, so if something goes wrong there. And that’s all about energy efficiency, again, in retail. And if there is a problem with the hardware, I think the guys in the bank can’t just step down and have a look at something. We can’t go there and change things. We can send their partners of us because nobody can step into a bank, go down in the cellar and do things there. That is absolutely not allowed. So if there are problems that our device doesn’t send data, it costs a fortune. It costs really a lot of money, and you have seen our price model is pretty lean. So we had to make things really, really, really reliable. And in order to do that, we need to store a lot of data about the health of our distributed devices. And the first thing, we are really heading in the direction of analytics and always the first thing we do when we-for example, you should try these things like analytics, we do all the evaluation and the tests based on our own data which we acquire from our hardware devices because there is so much information. Yes, I said so far, we started late in Elasticsearch but we are just about to switch to the TICK Stack there and we are evaluating what’s possible there because we see a huge benefit using these things and because the technology is that simple also for the dev guys.
Reinhard Nowak 35:02.549 So maybe that’s a short overview of our architecture. I think I have told you most of the things. Of course, it’s the WebApp and we have switched to PHP. Why? It’s easy to get resources, to get developers. It’s an easy language and it’s also easy to get a lot of experience to developers. We still have the DataService, but it gets more [inaudible]. Why? Because we are able to transfer most of the things into Influx and the database. That’s the place where queries should be and not in the DataService. And of course, we have the Object Service with all the inherent stuff, we have the Couch, MySQL for the account data conflict service because we need to distribute all the configuration to our devices, to external devices. Of course, other hardware vendors can connect to our cloud as well, and also, all the updates, all the device management, etc. is handled there. We have a RestAPI, also highly available. We have the Hardware API, as I told you. It’s a completely optimized protocol. We’ve used [inaudible] there, it’s a completely rare language, here in Austria at least, but it has a lot of benefits if it’s got high availability and efficiency. We will switch to Scala and Akka there. Part of our development team is already building up the first microservices built on Akka and Scala. We have eMQTT under the hood, will be a public eMQTT server for external services. Message Posts necessitate Druid as our core data store for the time series.
Reinhard Nowak 37:01.924 So what’s next? And then I’m done. What’s next? As I told you, we will improve analytics, on the one hand, we will allow the customer to explore historical data, and it will be an iterative mode where we show the customer chartings and he just drag and drops another chart. And we offer, “Hey, how you want. Do you want to make the difference between these two charts, and multiply or whatever, or you want to transform this in completely different type of time series?” and we will use InfluxQL analytic for that. Just about to implement it, and I hope we will release that by the end of June. We will release a lot of KPIs, so if you have-for example, if you have a digital signal, it’s really easy with a couple of mouse clicks to derive the possible on the right KPIs out of that. So for example, if you have a digital signal, if a manufacturing machine, using this example quite often, is running, then it’s really easy to find out how many percentage of my shift isn’t running. What was the biggest-or if it’s not running, okay, it was downtime. How many downtimes? What was the biggest downtime? Average downtime. Then dig deeper with the dimensions, is it an electrical or mechanical fault? What’s the comparison there? So that’s where we use, as I say, InfluxQL and TICK Script quite extensively. And of course, we do one thing also based on a pricing model. We will derive data on-demand, which means you don’t get active alarmings, and so that’s the thing. That’s the cheap pricing model that does the service. And if a customer said, “Hey, I’d like the data in real-time. I would like to get informed, for example, if there is an abnormality, and if there is a pattern recognized etc.” Then we offer a slightly more expensive pricing model per asset, and there we have all the stream processing, windowing, with the continuous query, etc., also built TICK Script. So as I said, we are also evaluating TICK with the complete stack for log monitoring analytics for our internal use. And if it’s simple enough that our service team can find errors and patterns pretty easily, then all these features then will make it into the core application into the cloud service.
Reinhard Nowak 39:54.863 So this was an overview about LineMetrics, what we do, how we do things, and from a technology perspective, how we ended up in this tech we are using today. So I would love to answer some questions. I will switch back to WebEx on the second screen, so I guess you won’t see my screen anymore. Let’s try that.
Chris Churilo 40:24.249 Reinhard, that was really a great presentation and a very thorough overview-
Reinhard Nowak 40:28.848 Thank you.
Chris Churilo 40:29.092 -of what LineMetrics does and what your architecture looks like, etc. And I have to say I do appreciate the amount of engineering work it must have taken for you guys to build something that is so simple that somebody on the shop floor could get their service up and running and start collecting those KPIs without having to use IT. It really says that there’s a lot of engineering work that has to go on behind to make it as simple as that for your customers. So really great job.
Reinhard Nowak 41:02.266 Thank you. It’s great feedback. So I think that’s what we’ve learnt. Sometimes it’s much harder to make things simpler. And so from my perspective-so I’m the guy with the vision. And since Version 2 of the application, I’m not allowed to code anymore and I think the guys locked me out from it [laughter]. So I’m more the vision guy, and I think that’s a really great separation between the teams. I’m really spending a lot of time with our customers, getting a lot of feedback, and trying to have a closed-loop for our dev team. And so it’s really important. As I said, I’m a huge fan of lean, which means we try to keep also our architecture as lean as possible. We have one guy who deals with nearly 100 virtualized servers in our data center in Vienna, and we have one guy who’s in operation for security and operations. So for him, it was really important, also, speaking about Druid and Influx again. It was really important to keep things simple and have a reliable system, where he gets an overview about what’s going on, which is really easy to integrate in all of data systems. Also, of course, we do a lot of monitoring of our internal services as well, so we can provide high availability and rec to some data centers as quickly as possible. And the same is true for the engineering on the backend side. For example, talking about the data services was so crucial for a small team to keep things lean, because it’s always easy to get things started and see a prototype. That’s also what I see with the hardware. A lot of people say, “Hey, it’s pretty easy. I can connect the sensor to Raspberry Pi and wire it up with the ethernet cable or connect it with the [inaudible] stick and see some data.” Yeah, that’s true, but not if you deal with one of the biggest-I mean, our customers are one of the biggest companies in contacting, for example, manufacturing or in food manufacturing, or at least in Austria, we deal with one of the biggest companies there. So of course, we cannot allow for security leaks, downtimes, hardware problems, etc. And that’s what we found out, is this all only works if there’s a really, really, really good team which is really working close together on a clear vision. And the same thing we tell our customers, focus on the value, that’s the same thing which is true for our team. We need to focus on the value, and our value is to provide value to our customer. And I think that’s also a cool technology. It’s a philosophy thing, but it’s also important to deal with the right technologies under the hood.
Chris Churilo 44:02.989 Yeah. Very cool. I also like your approach of looking at the assets. Because when you look at it from that perspective, one, it’s closer to how the customer’s actually going to be looking at it, but two, I think you said it really well that the types of metrics that you’re going to be collecting is going to really vary when you look at an asset. And it’s really kind of the collection of all those different viewpoints is really what’s going to help you to derive what’s actually working or not working for that particular asset. So maybe you can describe to us a scenario where some of the metrics that you collected on a particular asset; some learnings that you had on that or why you came with that approach.
Reinhard Nowak 44:53.648 Okay. So I think there’s one-okay, let me think about what would be a cool thing. So there’s one thing we’ve learned. I would like to take-there’s really common new cases, as I told you at the beginning, digital services. So digital services means there are companies building assets. For example, we have companies which make vehicles in the building industry. Others making assets to dry up hay in the agriculture. If you have grass and hay and you want to dry it up, they have a mobile solution to do that. On the other hand, we deal with a company which does laser cutters. And the other hand, we deal with companies who build complete steel factories. And these companies are starting to think about, not only selling the products, but also connecting them. Making the products connected. And the reason why they do that, are really just such a cool pattern, are four things. The first thing is, they want to optimize their internal service team. Of course, if they knew that things will break, they can optimize for the service guys. Or if the customer calls in that something is broke, they have a, I call it digital twin. They see exactly what’s going on at the machine and give some advice, and things like that. On the second hand, and that’s something we underestimated at the beginning, it’s really cool, it’s customer binding. A lot of companies tell me, “Okay. I built this thing. It cost $500,000. It sold to a company in, let’s say, Brazil, and we have no idea who bought it, who’s the customer, how he’s using the thing.” But if there’s a mobile app where the customer has some insights of his own machine. Why the mobile app? We have direct channel to the end customer. Maybe the machine was sold via a retailer, but he is still-up from this point, he has a direct channel. That’s not only interesting for the sales team of the company, it’s also interesting to teach these end customers, to educate these end customers to provide them more values because you learn if there is a problem because the end customer just didn’t know how to use the machine right, and nobody knew so the machine broke. But if you would know that, you can inform your customer, “Hey, you’re using your machine wrong the whole time. Here’s the guideline. Please read it.” And maybe the customer says, “Oh, okay. I need it in this language and that’s the reason I didn’t read the handbook which you gave me.” And you only learn from a customer if you are in direct contact with the customer.
Reinhard Nowak 48:02.587 So this customer binding is the second really important thing. And therefore, you need to think about the asset. You need to think about the customer. And then you think how you can deal with that. And for example, that’s mobile, that’s a cloud-based system where different stakeholders have different user data and have different values. And so the third thing is that the R&D department of the asset manufacturers is really interesting. So if I sell a machine to Norway, where it’s a little bit-it’s cold or it’s a little bit colder most of the time compared to Spain. The companies have to differentiate if they build this. For example, if you have the lubricants, they have to use different lubricants for different countries because the conditions are different there. But this information comes from their labs. They don’t really know it. They guess it. And more experienced companies have a lot of knowledge there, and most of the time it’s some of the more experienced employees of these companies. But if these things are connected and you have some kind of sensor data, you derive stuff and you don’t do some kind of analytics, you can learn during the usage of your product. And the fourth and really interesting thing is, if you track the data for internal reasons, there is most of the time, and that’s what we have seen with, for example, customers in the point-where we’ve talked about point of safe, for example. You can find out some interesting information out of the data you track for your own, which is really important for your end customers as well and makes him more efficient. And so what a couple of our customers doing is there it’s about benchmarking, it’s about gaining knowledge to provide consulting or monthly reports to their customers so they can become better by using the products of our customers. And so that’s where, here in the lifetime of-let’s say, 20-year asset-the manufacturer of the asset can make more money and do more profits over the 20 years, in comparison to the marching when he sells the asset to the end customers, and that’s really an interesting shift in business models. And that’s what we see. It’s always the last step if customers deal with these things, but that’s the goal of most of the partners we’re working with. But what I wanted to say, sensor data is just-it has to be there, but it’s just because we have to do it, but it’s all about values, customer, business model, etc.
Chris Churilo 51:13.286 Yeah. No, that completely makes sense. We’re just going to keep the lines open for a few more minutes. If anybody has any other questions, please feel free to put it in the chat or in the Q&A. And if you have to leave, just go ahead. But if you do have some questions, feel free to email me your questions so I can make sure that Reinhard gets them because I know he’d love to be able to share a little bit more with all of our attendees, how they built out their solution.
Reinhard Nowak 51:44.241 Perfect.
Chris Churilo 51:44.587 So we’ll just keep the lines open for just a few more minutes.
Reinhard Nowak 51:47.886 There’s a question, and maybe I should treat it before. It says, “What InfluxDB properties did you find more useful in your used case? And would LineMetrics be in a different situation if it had not adopted InfluxDB?” So maybe I can answer the second question, or the second part of the question first. Yes, absolutely. So one of the things we have seen was that-as a startup over the last couple of years-we had to adapt to the market requirements really, really, really fast. And what’s more, you have to code and develop on your own, that’s the way you get. And so what’s really crucial is that we have a database, a Time Series Database, where we can-so if there’s a new customer request, we can do nearly everything having just TICK Script and Influx by default. To be honest, I don’t know if we could have done most of the queries and KPIs and analytics reports or provide the same set of features using Druid. To be honest, I am not an expert in this deep level, but I know for sure that it was so complex and it didn’t fit to our HR system where the customer just clicks a few buttons and it can change things, and add properties, and add new streams, and remove them again, and transform data into something else. So what I know is that it was so complicated, also, to maintain the whole system that it would have taken us much longer, and I will say it wouldn’t get better over time.
Reinhard Nowak 53:44.069 And the second thing was that-what’s really interesting for us is that, next to InfluxDB, we always wanted to use the power of Kapacitor as well. And this was something where we knew there were a lot of different libraries out there, but we wanted to have one system where we know everything fits together and is working out of the box. So again, still same philosophy. We try to communicate to our customer, it’s also inside our team. So I said, I’m pretty sure, to be honest. Yeah, I guess we could have achieved the same, but the pain would have been much, much bigger and less fun. More pain. And so I think it was absolutely the right decision. So I don’t really know what you mean with the Influx-what InfluxDB properties did you find most useful? Okay, maybe the properties. I guess I get it. So what we have seen-what we loved was that the ease of use clearing into time series. This was really crucial. And as I said before, since a couple of years, I’m really trying-the whole team is really trying to gain a deep understanding of time series and semantics between different kinds of time series. So for example, if you have a temperature where data, of course, is enough if you sample it every 50 minutes because temperature doesn’t change that often. Has a completely different characteristic. If I monitor energy consumption once per second because you have a peak, the peak does really hurt the quality of your machines and how much you have to pay for utilities.
Reinhard Nowak 55:48.252 And so there are different-you have to handle these kinds of time series a little different. And so what we have seen over the last couple of years when we built most of this stuff by hand, is that the handling of, for example, granularity in time series if you have two-time series-it just worked out of the box. It was so easy. And nearly every example which is I threw to our dev guys, they showed me the result in a couple of hours, minutes, days-when talking about TICK Script, which got a little bit more complex or took a few hours more to get into the system and how things work. But we didn’t have an example from customers which we couldn’t deal with in a really short timeframe. And that’s what I loved. It’s well-documented and what we have done-during the development phase of our system, of the new version, we used open source. We learned everything was accessible. We learned from the open source and as soon, we went public with the new data center. We switched to enterprise, we had all the clustering because this was really important for us. And we used the clustering and enterprise management frontend for the backend from Influx. And there were some tiny things, but what we provide in our application is-we have an in-app chat. We use intercom for that. So if a customer has a problem with a sensor, he’s missing sensor data or he has a wrong value, he doesn’t know how to use our application. He just clicks the chat button, and one of our teams is available nearly most of the times. Currently we have a response time of six minutes if a customer has a problem. And so again, it’s a philosophy thing. We try to help our customer and that’s what we have seen also the phase of evaluating Influx. There was a community. And also using in the Enterprise solution-we had somebody. If there were questions, we got answers. How to use things. What’s the best architecture? The way how we should implement stuff. And if there were technical problems, there was a quick response from the tech team and ticket system, etc. And these are the tiny, tiny things. If we are responsible for a high-quality to our big customers, we need to rely on stuff which is under the hood. Yeah. I think these were the properties which I love most, and it was a clear decision driven by the dev team that we want to switch to Influx.
Chris Churilo 58:39.542 Oh, that makes sense. Are there any other questions in your chat panel? Because I don’t have any more questions on this end.
Reinhard Nowak 58:47.357 No, me neither. Me neither.
Chris Churilo 58:50.251 Okay. Well, I think, if anybody has any final questions, please feel free to put them in the chat panel or the Q&A section. Reinhard, I really appreciate your time today. I feel like you did such a thorough job there. I wouldn’t expect to have a lot of questions because I feel there was so much detail in here [laughter]. But as I mentioned earlier, if anyone does have any questions and a follow-up, just feel free to shoot me an email.
Reinhard Nowak 59:22.233 Yeah.
Chris Churilo 59:22.352 It’s [email protected] and I’d be happy to forward that off to Reinhard, and I’m sure he’d be happy to answer any of your questions.
Reinhard Nowa
k 59:33.890 Absolutely. Perfect.
Chris Churilo 59:38.640 Okay. Well, like I said, thank you so much, once again, and we really appreciate you as a customer and also sharing with everybody here how you used InfluxDB. So with that, I’m just going to remind everybody, I will post this recording a little bit later today and if there are any other topics that anybody is interested in us having in any of these webinars, please also let me know and we’ll make sure we get those scheduled. So thank you so much Reinhard.
Reinhard Nowak 60:09.925 Thank you.
Chris Churilo 60:10.825 And I hope you have a pleasant evening.
Reinhard Nowak 60:13.848 I will. Thank you [laughter].
Chris Churilo 60:14.930 Thank you.
Reinhard Nowak 60:16.113 Thank you. Bye-bye.
[/et_pb_toggle]
