How Sudokrew Used InfluxDB to Build a Battery Management Solution
Session date: Sep 05, 2018 08:00am (Pacific Time)
Blue Planet Energy sells an energy storage unit that allows residential and commercial buildings equipped with solar panels to store unused solar energy. They tasked Sudokrew with developing a Clean Energy Storage Device Management and Battery intelligence software solution. In this webinar, Spencer Toyama and Tony Gaskell from Sudokrew will share how they were able to leverage InfluxDB to create a solution to gather metrics that help monitor and control the storage units remotely, extending the life of the battery, improving the experience of the user, and offering superior customer service.
Watch the Webinar
Watch the webinar “How Sudokrew Used InfluxDB to Build a Battery Management Solution” by filling out the form and 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 “How Sudokrew Used InfluxDB to Build a Battery Management Solution”. 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
- Tony Gaskell: Developer, Sudokrew
- Spencer Toyama: Co-Founder/Business Development, Sudokrew
Chris Churilo 00:00:00.524 Good morning, everybody. My name is Chris Churilo and I work at InfluxData, and today we are hosting a webinar with a great use case from our friends at Sudokrew in beautiful Honolulu, Hawaii. And I’m just going to go ahead and let them take it away from here.
Spencer Toyama 00:00:18.232 Yeah. Hey. Really excited about this. My name is Spencer. I’m one of the co-founders of Sudokrew. You saw one of my childhood pictures is on there, and I guess they haven’t changed it. And with me today is Tony, one of our lead developers here. Hi, Tony.
Tony Gaskell 00:00:38.335 Hello, everyone.
Spencer Toyama 00:00:39.840 We’re in the same room [laughter]. We are in Hawaii, and Hawaii’s a pretty neat place. I think everyone knows it for the tourism and the beaches and trees, but we’re also really vulnerable to natural disaster. And energy, specifically, is a big issue here. We have a hard time with sustainability. I think we ship in a fair number of oil tankers every day just to keep the lights on, literally keep the lights on. And resiliency is an issue here. We were threatened by a hurricane last week. Was that last week? That was last week, yeah. We got threatened by a hurricane. We seem to get more every year. So resiliency in the energy grid is super important to us, which is why we work on energy apps. Companies like RevoluSun, Blue Planet Energy that we’re talking about today, Blue Planet Foundation, Elemental Excelerator. They’re all companies that we enjoy and value working with, because they’re presenting solutions that are really important to us as an island community, because it’s part of our survival too. So we’ll get to talking about the monitoring software that we built with Blue Planet Energy. The application is fairly widespread, or broad in its scope. There’s an admin portal that can commission devices and dealers and assign those devices to dealers. Dealers have their own portal where they can activate their account, view all the devices that have been assigned to them, and then add project owners, which would be an end customer. Someone who’s using the battery for themselves-has it installed in their home or office. And the project donor-that’s what we’re calling them, that end user-they have access to the dashboard. They can have property on it. They cannot add a tenant. That is a typo or something that I should have taken out. So this is an example of what it looks like to commission users and devices of an admin dashboard. We have a data pipeline set up with eGauge right now. Is that the right term for it, data pipeline? Tony?
Tony Gaskell 00:03:04.636 Yeah.
Spencer Toyama 00:03:05.403 I’m not the technical person, Tony is. So I’m just going to roll over onto him for everything. But right now, we can set up a data logger. Right now we’re using eGauge. Once eGauge is in our system, then we can assign it to people within that system. And why is that important? On the surface, pretty graphs [laughter]. These are mock-ups of some of the graphs that we would create. These are not the final designs, but they’re pretty close to the final designs that we’re [inaudible] together. And I can actually show you some of them in production right now. But we built these apps to create value for all of the stakeholders involved. Transparency is a really important issue, or something that I think a lot of people don’t take into consideration when building their customer relationships. For Blue Planet Energy, this presented an opportunity to create a more harmonious relationship with their customers by providing them with the same data that they see. So Blue Planet Energy can see cycle count, they can see battery output, and things like that that are related to the warranty, to the health of the battery, to the life cycle of the battery. All of these things are important. And so by creating a transparent, I guess, data-or having data at the center of that relationship, where they can talk to the customer openly about the data from their devices, and their batteries. It creates a more-sleep deprivation. What’s the word I’m looking for? A more transparent relationship between them. A more harmonious one. Sorry, I’m repeating myself. But as a group, this app-Blue Planet Energy themselves grew. They’ve been doing a great job, and have deployed water wells in Puerto Rico, so we’re really happy to see some of our software being deployed there to help bring people clean drinking water. But their user base also grew, and then we ran into some scaling issues with a database that we were using to capture the time series data. And Tony’s going to get into some of the scaling, and how we address that with Influx.
Tony Gaskell 00:05:47.222 Thanks. Yeah. So some things that I’m going to cover are what scaling issues we ran into, and how we went about validating whether or not Influx was going to be a good fit for our use case, and also maybe provide some takeaways, if anyone else is looking at trying to move to a time series database themselves. So as part of that, I guess, as Spencer was saying, there were issues that were being reported from all users. That’s ranging from admins and dealers not being able to see devices statuses, end users being not able to see graphs that are-or they’re rendering slowly, or not at all. And on top of that, the issues were inconsistent. We weren’t really able to reproduce those issues. And sometimes it would fix itself, and it was kind of frustrating. So I kind of put together a very simplified version of our system diagram, just to kind of illustrate all the places that we were checking. There could have been issues at the device level, when it would send data to our API. Maybe there could have been issues with our message queues that would move that to the database, or there could have been problems at the application layer, either retrieving that data or rendering it. But overall, the main issue that we saw was, data wasn’t available. And so that kind of pointed us towards looking at the database. And some background on that-the database that we were using was kind of like a black box system. We didn’t have much visibility into it. I think the only thing that we could tell was, is the main process still running? And any sort of error logs that were coming out of it. So at some points, our best bet was to either run a restart script, and kind of hope that the database would either fix itself, or if that didn’t work, we’d have to send an email with some of those error logs that didn’t really make too much sense to us. And while we were doing this, there were a few questions that we were asking ourselves, which was, “What happens if a database doesn’t come back up again?” Or, “What happens if one of the backups that we were relying on failed us?” And these were kind of scary questions that were coming up. And overall, we just kind of felt kind of helpless to the situation.
Tony Gaskell 00:08:52.333 So, again, we’re application developers, not database engineers. So we kind of just turned to Google, and it’s like, “Hey, what [crosstalk] database solutions exists out there?” And it’s not the same thing as RDBMSs, where mainly people would be saying, “Oh, yeah, use Postgres or MySQL or something like that.” We were presented with a list of like 10, 20 different databases that we’d never heard of. Top ten time series databases you should know of. And overall, it was kind of overwhelming, but at least we had some sort of lead towards things that we could check into. But it was apparent that we needed to come up with some criteria for ourselves so that we could kind of pare down our search space. And so some of those requirements that we set for ourselves were: the database had to scale with the devices, and all the registers that were being added to those devices. It needed to support an HTTP API, because that was how we were currently interfacing with the existing database. It needed to support basic aggregation functions, and it would be great if it had a hosted solution. And so after we looked at this, you know, we kind of narrowed down our search to maybe three alternatives. One of them was Elasticsearch, which we only considered it mainly because we had used it on previous projects, but we hadn’t used it as a time series database before. And it didn’t seem like it was going to be-it didn’t seem like the right fit. It wasn’t designed for this. And that kind of narrowed it down to either Prometheus or InfluxDB, and both of those seemed to be very good on all fronts. Both of them had clustering solutions. Both had an HTTP API. Both had aggregation queries. They were both open sourced, and that meant we had some visibility into what the code was doing. But I think in the end, Influx had dedicated hosting, and I think that that was kind of the key for us to kind of go ahead and kind of vet it out.
Tony Gaskell 00:11:16.108 So after we were given the go-ahead, we kind of architected some sort of bench-marking process, and we contacted the Influx support team. They set us up with a trial version of InfluxDB Cloud. We were able to kind of import some of the data from our production database into that instance, and we configured-we used a tool that was built on ApacheBench and Amazon EC2. It’s called Bees With Machine Guns. It’s open sourced. But essentially what it does is, it allows you to spin up a lot of EC2 instances and DDoS your own servers, which was actually very useful for us. And so we felt that this was going to be an accurate simulation of having many devices that weren’t on our local system. Some were out on the Cloud, hitting our servers at a rate that was a lot higher than we were expecting. And these are just some of the performance gains that we got out of those bench-marks. But it was clear to use that Influx was definitely going to be able to support our use case, and any sort of growth, or unexpected growth, even, in the future. And so after this, we were able to go ahead and kind of focus again on the application and the system, being able to convert data from an XML payload that we were getting from eGauge devices into something that Influx could understand. And luckily for us, too, we run full stack JavaScript, and we have a node server. And our nod
e server-we were able to install a package called Influx. It’s really awesome. It handles a lot of the issues that we ran into, or that we would have ran into, regarding things like whether things are quoted correctly, translating from milliseconds to nanoseconds, which is kind of the default setting on Influx. But I think that can be configured so you can handle it on either side. And overall, just kind of looking at the documentation that was on the website and kind of really grokking the key concepts.
Tony Gaskell 00:13:56.114 And in part of doing that, we kind of realized-even though we had a single XML payload that was coming in from eGauge devices, what that really meant was, we needed to translate that into a bunch of data series. And I think that that process was-it wasn’t too bad, considering we have mainly, primarily used just our DBMSs, but there were some gotchas that I think it was good that we caught it by reading the documentation. Just how we should set up our tags, and stuff like that, so that the queries would perform well. And on top of that, there were some questions that we had to ask ourselves while we were configuring the database. Like, “How much data are we expecting to come in?” “How long should we hold onto that data?” Because we don’t want to run into a situation where we’re running out of storage space again. Or, “What format should that be?” “Do we want to keep averages, or do we want to keep a running total?” These were questions that we could actually try to answer ourselves, because we had control over how the data was being handled. And in most of our cases, this was looking into things like retention policies, to know that we’re only going to hold onto our seconds data for maybe an hour before we get rid of it, so that we don’t have millions of points of data that we weren’t going to use anymore. Instead, roll that into minute aggregations that we could hold onto. And I think those were some of the things that we didn’t expect going into this, and kind of transitioning into it. So, again, it gave us a lot of-from here, we have a lot of places that we can go forward with it. There’s a lot of opportunities that are available to us now that we have control over our data. And I think that that was probably one of the most-the best thing that we got out of this so far.
Spencer Toyama 00:16:24.030 Yeah. That was a nice [crosstalk].
Chris Churilo 00:16:25.637 Cool. I have a lot of questions, don’t worry. So let’s back up a bit. I have a question for Spencer first. So maybe you can tell us, who is Blue Planet Energy?
Spencer Toyama 00:16:36.486 Oh, okay. So Blue Planet Energy was started by Henk Rogers. He’s also the founder of Tetris-or, no, distributor of Tetris? But anyway, he has the Tetris copyright, and got really into sustainability a few years ago-or I want to say a little over a decade ago-but started the Blue Planet Foundation, a non-profit. I think he got pretty-what’s the word? Inspired, I guess, to really take on some of these energy issues on his own. So realizing that storage was the big problem to solve in the market, he’s decided to start an energy storage company.
Chris Churilo 00:17:25.340 So maybe you can describe what’s the difference between energy generation and energy storage. Because I think, unless you’re in this world, we don’t think much about it, right? Because I just flip off my light switch. I don’t think about what and where this is created. So [crosstalk].
Spencer Toyama 00:17:38.446 Maybe why is it important? Like, why are we thinking about energy storage right now?
Chris Churilo 00:17:44.050 Sure.
Spencer Toyama 00:17:44.826 Right. So right now, if anyone’s in California-or in Hawaii, we’re having the same issue. It’s that we have intermittent energy that kind of floods the grid, and then you need some energy storage to basically shave off the peak of how much solar energy is coming into the market, or into the grid. So it’s incredibly important for grid stability and grid sustainability, because if you’re not managing the power that’s entering your grid correctly, then it can fry lines, it can fry electronics, and we see that all the time.
Chris Churilo 00:18:31.816 So then what damage-so you’re collecting information about the batteries or these big storage units. So what information is just vital to maintaining these big devices? And I imagine that you must be collecting that data and presenting it in the solution that you’ve built for them.
Spencer Toyama 00:18:50.133 Yeah. Well, the main one is really battery status. Is it holding a charge or not? But also cycle count. They use lithium ion phosphate chemistry, which is probably one of the safest chemistries available. It can last for a really long time. But they do-every battery has a cycle count, so that’s kind of important for everyone to know.
Chris Churilo 00:19:21.061 And then, what’s the-so when you showed those really beautiful mobile graphs-so I assume that these users are going to be the people that actually purchased the storage units, either for commercial or home use. What’s important for them to know? So you kind of-maybe if we could spend just a little bit of time-as a consumer of these products, besides the cycle counts, besides whether it’s holding a charge, what are some of the things that you’re showing us in these graphs? And just describe what other kind of data did you have to collect to be able to make these graphs happen?
Spencer Toyama 00:20:01.332 Yeah. Okay. So most of these are production and consumption numbers, and the amounts stored over time. But that’s why Influx is so important, because it provided the ability to do this. So let’s see. The first one is mostly the amount stored in the battery. Just like your phone battery has that-how much is left in the charge, we have this next one. To the right of it is, I believe, consumption, or how much was used in a 24-hour period. And then we have another storage graph over time. So it’s just taking that-what’s the battery’s status, and then what does that look like cycling through over time, and then giving the user different time increments that they can query from. And then we can also measure usage against production. This is pretty good for homeowners that are trying to have a Net Zero lifestyle. They can see that if their overall production of solar energy or wind energy is better, or greater, and then we give them a 24-hour view of the same thing. So that same line graph wrapped in a 24-hour view. And then finally, on the last one, is usage by device-or not device. These are registers, actually. Registers are individually monitored parts of the-what’s it called? Breaker box, I want to say. So you could measure someone’s washing machine time and dryer time if you have the sensors hooked up correctly. And then homeowners, or whoever, can see-I guess homeowners or project owners-can see pretty deep into the usage, if they have the right sensors hooked up.
Chris Churilo 00:22:15.997 Oh, that’s interesting. So then that way, they can have a very clear view of whatever they’re doing that’s having a positive or negative impact on the energy that they’ve got stored that way.
Spencer Toyama 00:22:26.113 Yeah. Correct. So we’re using eGauge right now as the data logger for this. It’s kind of nice. It’s a utility-grade submeter, and I think you can use it for water as well, but we haven’t tested it with water.
Chris Churilo 00:22:41.566 So then, for the consumers of this mobile app, whether they’re the project managers or the individual, it looks like it’s not a long period of time of data that they’re looking at. Looks like it’s within a 24-hour period.
Spencer Toyama 00:22:57.299 Not necessarily. Actually, let me switch views. This is what actual production looks like. This is not the mobile view. Sorry.
Chris Churilo 00:23:07.908 That’s okay.
Spencer Toyama 00:23:07.979 I can’t bring up the mobile view because I’m on desktop, but this is what the web view looks like. That’s data. All right. Sorry. What was the question?
Chris Churilo 00:23:21.467 Just what’s the typical time span of data that your consumers are looking at? 24-hour? But I see now you can have a month worth of data. And the reason I bring that up is, depending on the time interval, how precise-because I heard Tony talk about nanoseconds. Rendering these graphs with all that data can be difficult. And so then I wanted to just ask a question to Tony. Are you really collecting nanosecond data, and is it feeding into these? And what kind of an impact did it have?
Tony Gaskell 00:23:56.723 Yeah. So for us, no, we are not. I think the smallest value that we go down to is the seconds. So we actually-all the data that comes in is at the second aggregation level. Just some issues that we ran into is just that translation between-so we primarily use JavaScript, especially on the front end. But just being able to translate either-knowing that the number, the integer that’s coming back, is in nanoseconds versus milliseconds really mattered, especially when we were trying to query by date and stuff like that. But no, we’re only using seconds at the smallest measurement value.
Chris Churilo 00:24:42.424 Okay. And then the other question I had is-if we can just look at your architecture diagram a little bit, and I think this will then also-we have a question from one of our attendees. But I think I’d like to dig into this a little bit more. So the devices that you’re talking about are the various sensors that are on the batteries, is that correct?
Tony Gaskell 00:25:04.711 Yeah. It’s an eGauge device that’s talking to the battery that it’s reporting. It’s things like state of charge and cycle count and stuff like that. The eGauge device is also in charge of monitoring other things, like kitchen usage and stuff like that. That’s not directly monitored by the battery.
Chris Churilo 00:25:28.772 Okay. So there’s separate sensors for that one, then.
Tony Gaskell 00:25:31.823 Mm-hmm.
Chris Churilo 00:25:32.414 And so one of the questions that we got from Girish [inaudible] is, are there any reasons why you’re using an XML format for data from the sensors? He says that, “I was thinking that sterilizing and de-sterilizing is resource-consuming for XML as compared to JSON.”
Tony Gaskell 00:25:48.517 Yeah. Totally. I mean, I would prefer if it was in a different format, but that is just how eGauge devices report their information, and so that’s just what we got.
Chris Churilo 00:26:01.829 Okay. Excellent. So you’re pulling that information into the-a [inaudible] set of APIs into InfluxDB and then serving it up into these various applications. And on this particular site, you also mentioned that there are different aggregation requirements for mobile versus desktop. Maybe you can just drill in that a little bit more. Because a lot of us just think, “Hey, what’s the difference?”
Tony Gaskell 00:26:25.976 Sure. Yeah. Okay. That’s a good question. I think, for us, it really matters especially when someone is viewing this on their mobile device. Because when we’re working with time series data, you can get a lot of data really quickly if you’re not careful with the levels that you’re grouping your data by. So on a desktop application, it might be able to handle a day’s worth of data at minute aggregation, because your computer’s powerful enough to render that onto the graph. But when you need it on a mobile device, which-you don’t know what kind of cell network they’re on, or whether they’re on Wi-Fi or not, or on Edge, or something like that. But those devices, it was more performant for us to kind of query the data by, say, 30 minutes or something like that, just to reduce the magnitude of the number of points of data that are coming back, so that the graphs could render quicker.
Chris Churilo 00:27:39.688 And then, while we were looking at the data that you were pulling into InfluxDB, it looked like you were using just a couple of tags. I saw register, unit, serial. Were there other tags that you used, or did you find that was sufficient for the application that you were building? Because it looked like it was something that you already had from the original eGauges.
Tony Gaskell 00:28:05.708 Yeah. So for our use case, it was kind of hard to-well, it wasn’t hard, I guess. But I think the difficulty that we ran into was the devices that are configured don’t have set register names. So that was-it was hard for us to kind of filter out a value if we didn’t know what it was going to be. And so for us, it was just easier to treat each register as an individual series with a single value. Because we are actually not sure what values are going to end up on a production device. So we kind of split apart the entire payload into separate series of data, and from there we query it and aggregate it back together however we need it for our application.
Chris Churilo 00:29:06.332 Okay. And then, so we saw the view of what the individuals or the project managers see. Is there another view that Blue Planet sees, like an aggregated view of all the devices that are out there? And have they gained any kind of insights from your solution that they didn’t have previously, from that aggregated view?
Tony Gaskell 00:29:31.349 I think for us, we’ve primarily used a chronograph for that, which came with InfluxDB Cloud. And we were able to set them up with some templates, and kind of gave them, “Oh, yeah, if you want to find a device, you could just enter in its serial number.” Or something along those lines, so that they didn’t have to-and they could kind of customize what views they wanted to see. I think one great thing that came out of that was just the warranty values that were coming in. We could get the average cycle count across all devices, which wasn’t something that we could do before. And that was really simple, and that one-it’s like 10 or 15 minutes, just playing around with the dashboard. And that was something that was really helpful for them.
Chris Churilo 00:30:32.667 So what is the average lifetime of a unit?
Spencer Toyama 00:30:37.901 I think it’s-oh, man. I think it’s 10 years, but don’t quote me on that.
Chris Churilo 00:30:46.756 So it’s a long time. It’s not like our phones. So it’s something that you expect to be performing for quite some time.
Spencer Toyama 00:30:52.715 Yeah. It’s a while.
Chris Churilo 00:30:54.131 So I imagine having that information is going to be ultimately really important to them, because they want to save on their investment, which I’m sure is pretty costly.
Spencer Toyama 00:31:04.001 Yeah. Well, I mean, the price of batteries are kind of going down over the last few years, at least. But yeah.
Chris Churilo 00:31:14.542 Sure. But it’s not like my phone battery, right [laughter]?
Spencer Toyama 00:31:17.078 No, no, no. I mean, I’m actually not sure how much the units sell for, but I think it’s comparable to the Tesla batteries.
Chris Churilo 00:31:26.747 So have they mentioned to you that they’ve found any other interesting patterns? I know when we’ve talked to some of our other partners that have built battery management solutions, it’s often patterns that they never even thought about that could actually have an impact on their business model.
Spencer Toyama 00:31:50.051 Well, we see-I guess we see a lot of usage patterns in people’s energy habits. That’s interesting, but it doesn’t-I think it’s probably more interesting to the project owners than to us, because-I don’t know. I think it helps them make decisions, but for us, we’re not as concerned about that unless it’s things like cycle count, or if we see something-I don’t know if we see anything really crazy. I don’t think we see anything really-I don’t know. You see anything that interesting? I don’t think so.
Tony Gaskell 00:32:32.874 I mean, I think the general trends that you see are people waking up in the morning, turning on all their appliances, going out to work, and then seeing the batteries charge up over the course of the day when the sun is out, and then slowly going down overnight, and the energy’s being pulled from the battery instead of from the grid. But I mean [crosstalk]-
Spencer Toyama 00:33:01.905 [crosstalk] Yeah. In the energy industry, it’s called the duck curve. And I think something interesting we see that most people don’t is the individuals that make up the duck curve and aggregate. If anyone’s familiar with the duck curve, it’s basically like-yeah. What Tony was explaining. People wake up in the morning-now if I could just Google it real quick so people can see what it looks like. Duck curve. But it’s a really important problem in California right now, where people waking up in the morning, their usage goes up. What is this? Oh, yeah. When people are asleep, right? Usage goes down. And then this increase ramp when people are getting home, it looks like.
Chris Churilo 00:33:54.854 The reason I ask these questions-I know I’ve heard from some of, like I said, our other partners, and they actually had some anomalies against this duck curve where maybe there was an eclipse, or-because their solution is sold in Africa, when there’s a big football game, it ruins the curve, because all of a sudden everyone’s watching TV at whatever time at night. Right? And they see these pretty big spikes. And so that’s why I was just wondering if there were other similar things happening here. We have a couple of questions in the chat. So Aaron asks, “Did you guys analyze the cost of Influx hosting versus hosting on your own? And what things did you take into consideration in making the determination to go with the hosted version?”
Spencer Toyama 00:34:44.220 We did, actually. Right? Oh. Like versus rolling our own? [inaudible] our own hosted version?
Chris Churilo 00:34:53.454 Mm-hmm.
Tony Gaskell 00:34:56.179 I think when it came down to it, it was comparable, but what we got with going with the hosted solution was the dedicated support. And I think that that was worth it for us, in the end, because that allowed us to, again, just focus on the application. And if we did run into any issues, either designing or schema, there was someone that we could reach out to. But I think we did consider going and rolling our own, hosting it on our own instances. Which is also good, because we do have the ability to do that if we have more capacity, I think. But it’s a good option.
Chris Churilo 00:35:49.526 All right, Aaron, hopefully that answered your question. We actually hear that from-it’s interesting. I hear it a lot from development organizations like yours, Tony and Spencer, where the pressure to work on features that are going to benefit your customers or your own projects outweighs dealing with hosting it yourself and managing all that. Second question we have from Karsha is, “What platform do you use for remote device management functionality?”
Tony Gaskell 00:36:21.115 So regarding the eGauge devices, they actually have a built-in dashboard, which is password protected and all of that. So every device that-if we need to connect to it, it does have to have an internet connection, or some way that we can connect to it, mainly through our browsers. But that’s all built into the eGauge devices.
Chris Churilo 00:36:51.206 Excellent. So Karsha, let us know if that answers your question. And I don’t want to monopolize all of the questions. I have a tendency of doing that. So if you do have any questions, please post it in the chat or Q&A. Or if you’re interested in just having a conversation, you can also just raise your hand. We can all go-I can unmute everybody and we can just speak to the guys directly.
Spencer Toyama 00:37:22.182 Hey, everybody.
Chris Churilo 00:37:24.310 So, Tony, one thing that you mentioned when you were talking about looking for a Time Series Database, when you were considering InfluxDB and Prometheus, is, you said that when it came to open source, it was important to you because it gave you visibility into the code. Can you elaborate on that? Why does that matter?
Tony Gaskell 00:37:43.476 Yeah. Sure. For me, personally, I like to understand what’s happening, or at least have the ability to kind of peer into what code is actually running on our systems, because in our case, when we had no visibility, we kind of had to guess a lot of the time. We did have monitoring configured, but there were-either alerts weren’t set to the correct levels, or we thought these were the values, so we wanted the alerts to go off at, and it ended up being different. Like it needed to be set lower, in the case of our storage usage. But not being able to see what’s actually executing on our servers is-I think it’s, I guess, unsettling at some level. But just being able to kind of see what’s happening-even looking on GitHub, active issues that other people are asking. “Is there a feature here that I’m interested in?” And being able to see developers responding to those questions, and either helping out people with their issues, or finding workarounds for that. That’s all very useful for me as a developer, just to kind of have that layer of transparency.
Chris Churilo 00:39:25.065 That’s great. There’s a lot of people in the industrial IOT sector that are still a little bit uncomfortable with open source. But as you articulate so well, that’s one of the beautiful things about open source, is you can-you get so much visibility. You can see the issues that were raised. Nothing’s hidden. You can see the responses back. And the good thing is, with good open source projects, you also see the developers that are working on the project often respond to those issues that are raised. We actually had a customer called tado° in Germany that listed out some issues with the last query two years ago. And when it was fixed, they called it “the miracle of November,” because they weren’t expecting it. But they were really excited when they looked into GitHub to see, oh yeah, they weren’t crazy. Their queries weren’t just faster for no reason. It was because the issues that they raised did get addressed. So any other advice you might give to other developers that we have on the call, if they’re looking to add a time series database to their projects?
Tony Gaskell 00:40:38.794 I think it’s important to understand what your use case is. I don’t think every-I mean, I think Influx worked for us, but maybe another database solution could work for you. And it really just comes down to understanding what your limitations are. Are you only monitoring a single device, or are you monitoring an entire fleet? Those are a lot of design decisions that you need to consider up front, and just kind of thinking of the possibilities that could come out of it. In our case, we were stuck in a place where we couldn’t implement features, because we were limited by something that we didn’t have any control over. But I think, at least for our use case, being able to control that information, and even being able to work around any sort of-what’s the word? Limitations. Just understanding that up front is really important. It’s just understanding, what is your project built for? Where do you think it’s going to go, and do you have that room for flexibility? And to be fair, nothing is ever going to be-nothing is ever constant. Things are always changing. And I think that that’s kind of a good philosophy to live by.
Chris Churilo 00:42:30.233 Excellent. Well, if there are any other questions, feel free to-
Spencer Toyama 00:42:33.890 Well, Aaron had asked some things in chat.
Chris Churilo 00:42:36.307 Oh. Did I miss it? Okay.
Spencer Toyama 00:42:38.013 Yeah. “I was wondering if they are going to start to look into anomaly detection with Kapacitor, and more generally, what are their next steps with the time series data?” That is actually up to our client [laughter], if they want that. I think we’ve talked a little bit about it, but I don’t think there’s anything like plans that we can talk about it right-we can’t talk about any of those plans right now. Next steps in the time series data.
Chris Churilo 00:43:13.253 Well, when you do have the conversations with your customer, and you do v2 of this solution, we’d love to hear about, what are some of those features that they were making to add? I think a lot of us have experienced that once you start having access to the data, then more questions arise, and more things-you just get more curious, and you just want to be able to do a lot more with data. And so we do get a lot of people that are starting to look into Kapacitor for anomaly detection, especially with things like battery management. Which seems to me-on the surface, seems a bit mysterious to me, because I can never understand why it’s not working, or what’s going on. So being able to understand what’s something to be expected, what’s something that’s unusual, is probably going to be helpful for your customers.
Spencer Toyama 00:44:04.045 Yeah. And I think Aaron touches on a point of the rest of the TICK Stack that could have been used, but we actually ended up building a lot of the services that the TICK Stack encompasses. Very lightly, not in any way to the breadth that the TICK Stack covers, but we did have to build a lot of services for the database that we were previously on. So kind of fitting Influx into that was really nice.
Chris Churilo 00:44:38.867 Excellent. And yeah, I mean, that’s, I think, one of the things that we’re super proud of is that you don’t have to use entire stack. In fact, probably a lot of projects probably just InfluxDB and the client libraries. Or you can use everything. It’s completely up to you.
Spencer Toyama 00:44:57.498 Yeah.
Chris Churilo 00:45:00.064 All right, Aaron. If you have any other questions that you want to ask these guys, feel free to do so. I do have a couple other webinars where people are using Kapacitor for anomaly detection or helping them with that. In fact, I would recommend taking a look at the Playtech webinar. And also I will be having a few more from a couple of customers that are very heavy Kapacitor users, so stay tuned for those, and we can all probably learn a bunch from those guys. So we’ll keep the lines open for just a few more minutes. And in kind of wrapping up, just want to remind everybody, this is being recorded, and I will just do a quick edit and then post it before the end of the day, so you can take another listen to it. And if you have any other questions after, just feel free to send me an email, and I’ll forward it to Tony and Spencer, and I’m sure they’d be happy to answer your questions. Or if you even need any kind of help from a development perspective, the Sudokrew dudes are always available to work on some kind of developer engagement. Doesn’t matter to them where it is in the world, right?
Spencer Toyama 00:46:09.763 Yep. We will wake up at 5:00 am to get some things done [laughter].
Chris Churilo 00:46:16.248 All right. Well, it looks like we are done with our questions, and I appreciate everyone’s time today. So thank you so much, and have a great day.
Spencer Toyama 00:46:24.595 Thanks.
Tony Gaskell 00:46:25.307 Thanks for having us.
Spencer Toyama 00:46:26.337 Yeah. Thanks for having us.
Chris Churilo 00:46:26.465 Bye.
Spencer Toyama 00:46:27.581 Bye.
[/et_pb_toggle]
