How Bevi Uses Data to Give You Less Bottles and More Bubbles
In this webinar, Sean Grundy, Co-founder and CEO and Yvan De Boeck, VP of Engineer at Bevi, will provide an overview of how Bevi makes internet-connected “smart” water coolers that provide still, sparkling, and flavored water on demand. They will then review how they use InfluxData to gather the metrics and events to remotely conduct real-time data analysis that helps them understand how these water coolers are performing. This data enables them to provide proactive maintenance and restocking of the Bevi machines, as well as detecting emerging beverage trends. This showcases how technology can help to eliminate plastic bottles by making the best drinks instantly available using purified tap water and natural ingredients. Bevi has already saved over 10 million bottles and cans from entering the ecosystem.
Watch the Webinar
Watch the webinar “How Bevi Uses Data to Give You Less Bottles and More Bubbles” by filling out the form and clicking on the download button on the right. This will open the recording.
Transcript
Here is an unedited transcript of the webinar “How Bevi Uses Data to Give You Less Bottles and More Bubbles.” 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 - Sean Grundy: Co-founder and CEO, Bevi - Yvan De Boeck: VP of Engineer, Bevi
Chris Churilo 00:00:00.662 That’s going to go over their use case on how they’re using InfluxData with their smart cooler. And please feel free to ask them questions about their implementation. Go ahead and post those into the Q&A or the chat. Or if you’d like to actually talk, just raise your hand, I can definitely unmute you and have you ask your questions that way as well. So with that, I’m just going to hand it over to the guys.
Sean Grundy 00:00:27.541 Hey guys. This is Sean Grundy and Yvan De Boeck from Bevi.
Yvan De Boeck 00:00:31.357 Hello.
Sean Grundy 00:00:32.688 And thanks a lot for taking time to spend your morning with us. We’re excited to share a little more info on how we’re using Influx. It’s been part of our tech stack really from the beginning. I want to start by taking literally like five minutes to give a really quick overview of our product, business model, and technology, just to provide some context for how Influx fits in and why it’s a good strategic choice. And most of the talk will be much more technical and handled by Yvan who’s our VP of Engineering, who actually knows what he’s talking about. So let me take control of the slides here.
Sean Grundy 00:01:16.748 This is the two of us back when we were young men starting this company about four years ago. And Bevi at its core is an environmental company. So we are a smart office water cooler company, but that is honestly a consequence of what our role was starting this. We’re an environmental company that set out to entirely eliminate disposable bottles from the beverage supply chain. So our goal is to take every drink you can only get in a bottle today, whether that’s high quality purified water, sparkling water, vitamin water, fruit infusions, whatever you’re drinking, we want to make it possible to get those same drinks or even better drinks without wasting the disposable container.
Sean Grundy 00:02:11.670 We found that in spite of the massive market for bottled water, in spite of the fact that literally 30 billion plastic bottles end up in a landfill every single year, there is a really strong pull from the millennial generation to have more environmental solutions. What’s interesting is this same generation is often addicted to LaCroix or Polar Seltzer or different sparkling water brands, but when they have the choice, they really prefer environmental solutions and healthy solutions. And we’ve been able to take advantage of that interest and kind of let them guide us, let them teach us what kind of products we should build for them.
Sean Grundy 00:02:56.889 We came up with this product we launched about two years ago. It’s a product called Bevi. Just like the company, it purifies water directly from the tap and then through a touchscreen interface, lets people create different kinds of customized drinks. So anything from regular purified water to sparkling water to cucumber water or coconut water or what have you. Just a wide variety of healthy drinks.
Sean Grundy 00:03:23.370 The touchscreen is important because that’s also a data capture tool, but we’ll talk about that in a few seconds. And at the core of what we’re doing, in addition to saving all the environmental, like plastic waste from not needing disposable containers, we also save a massive amount of fuel. If you think of the beverage supply chain today, it’s a little insane to purify your tap water in a bottling plant, which is how most drinks are made today, including most water brands are really just purified tap water. Mix in that tap water sometimes with maybe like 1% of non-water ingredients, bottle it, and then truck those bottles to someplace where they’re eventually refrigerated and consumed. That’s just not a very efficient system. We have concentrate containers where a single 3-gallon container has enough concentrate to produce 1200 bottles worth of flavored drinks. And that enables us to just have much, much lower shipping costs and use much less fuel than the traditional beverage supply chain. So, that enables us to compete both on sustainability and also on cost.
Sean Grundy 00:04:40.554 You’d initially look at our product and think that we’re a hardware company, which we kind of are. We designed this whole custom system for letting people create personalized drinks where through a touchscreen, they’re setting things like the strength of the flavor and whether or not they want drinks carbonated, but they’re actually controlling pumps and valves inside our system. And we’ve designed this whole system to be able to create drinks using extremely ultra-filtered water and then mixed always to very precise ratios. And we’ve designed them all to come out of a single nozzle without ever having a crossover of one flavor to another. So for the first two years, we really were essentially a hardware company. Yvan joined in our second year and really turned us into a software company.
Sean Grundy 00:05:33.814 We found that software-becoming an internet-connected product, which at the start, we honestly weren’t sure we were going to be, but becoming an internet-connected product was just absolutely essential. To know first of all were machines working, how much were people using them. Very quickly, we realized we needed machines to be connected to handle inventory management. We needed to know exactly when should CO2 or various beverage ingredients be replaced, exactly when should a filter be changed. And this software has actually let us use much higher quality filters that need more frequent changing and much higher quality ingredients. Some of the best flavorings have low shelf lives and you wouldn’t be able to use them in a traditional bottle or a traditional soda fountain. But because we have this software that really accurately measures when everything needs to be replaced, we’ve been able to kind of increase the actual end quality of the beverages and of the service.
Sean Grundy 00:06:40.661 The software is really also the key to collecting an enormous amount of data. Every time someone touches a touchscreen, whether they’re reviewing ingredients or whether they’re changing a setting, we are able to figure out what is popular where and then start correlating like, “Okay, if these people like coconut water, they’d probably also like lemon water.” And that leads to higher revenue. They’re very fast business returns. It first of all makes customers happier. Second of all, increases our revenue. So it’s very useful data to collect. From there, we’re going to kind of-that’s sort of the end of the business talk. If you guys are interested in learning about the business or in getting a product, go to our website, but I don’t want to turn this into a product talk, so hand this over to Yvan.
Yvan De Boeck 00:07:32.505 So let’s go back to the beginning. I joined in September 2014. And before I came on board, the team was relying on contract work to do the software and I was like, “You’re joking, on the firmware, that drives the [inaudible], and an android tablet, which everybody has still an android tablet inside. And so I joined as the only first software engineer and I knew that I would be the only one for quite a while because we were just growing and it’s a hardware company, struggling in the beginning, was very much hardware. And then my first task was to help stabilizing firmware and the android app.
Yvan De Boeck 00:08:17.052 And in the beginning that I joined, we were also starting to roll out actual Bevis that we manually built one by one to customers and we were wondering what our customers doing. Do they like it? Do they use it a lot? And so we started thinking about having a background and visualizing the data, that we did not have yet at that time. But my background is really in enterprise apps like using Java and PostgreSQL. That was my opportunity to shine there, because firmware and android, that was also new for me. I started looking for a Time Series Database and I ran into by a friend of mine, so Sheila who had lunch with me and she had told me about Influx, that that might be something that is great for us. And I looked up a presentation on InfoQ from Paul Dix at the time. And that was also the start of InfluxData I believe.
Yvan De Boeck 00:09:22.837 So the presentation of Paul was more around servers and how data from servers, metrics from servers would be accumulated there, but that was easy translatable in our use case of having all the Bevis connect to the internet. And so the next day, I looked at the examples and I made it work for us. So it was very trivial to start the docker container with an Influx version, hooked up Grafana to that and visualize the data. So Sean went to get a Bevi drink and by the time when he was back on his desk, I could tell him what kind of drink he was drinking. So, that was very impressive and very easy without any frame points. So from then on, that moment on, we continued using Influx.
Yvan De Boeck 00:10:20.976 So the architecture is basically, well, we got all these Bevis in the field and they accumulate events. And events are just written to a log file there. So we’ve got different ways of connecting to the internet. We’ve got the Wi-Fi of our customers in the first place, but we can also do Ethernet or have the seller option. But we don’t rely on always having the internet on. So we write it just to a log file. And then when we got internet and we send these events to the Cloud, and there we’ve got just-we run our service on DigitalOcean. And we’ve got some Docker containers. In the beginning, we had just a single server that costs $20 per month for the first year basically. And so there were not really huge powered or processing needs yet. So InfluxData database, and that’s the only database that we have really. We don’t have anything else. We’ve got another layer, post-processing which is more around data science and Python and that uses CSV file that we get from InfluxData. And our business logic is in Java using Dropwizard, and Grafana certainly in the beginning to visualize the time series that we stored in Influx.
Yvan De Boeck 00:11:52.388 So these events that come from the tablets, how do they look exactly? Every event has four shared properties. One is the unit that it comes from. So, that’s important, we know that because we hit a rest endpoint basically and that rest endpoint, we can identify where it comes from. Then it’s got type and dispense. That’s the most trivial one when they use of dispensers. Then [inaudible] dispense. A timestamp, and that’s a timestamp of the tablets itself. We start everything in UTC. Yeah, the timestamp. So it’s not important really. We don’t rely on the fact that it is completely consistent across units. And so, it doesn’t matter if it’s a couple of seconds off. And so when it is a couple of years off and that happens sometimes, that the time clock of the tablet is wrong. That’s more of an annoying problem. And for us, in the majority of the cases, it works very well. And then we got also a sequence number and that’s just an incremental number that’s consistent within the tablet.
Yvan De Boeck 00:13:06.798 So there again, the sequence number is not across units and it’s something that server doesn’t know about basically. It’s just to keep track of a certain unit. So for instance, one of the cases where we use that is that if get an event and day, we can check whether we got all the events or whether we got to replace some and go back into history. This may be a problem going on with a certain unit. And so these four elements: timestamp, units, sequence, and the type; these are the four common things in every event. And for the rest, it’s just a set of key value pairs. Like for this dispense, you can see the duration of course as the most obvious one. The flavor that we chose. And we got a lot of ways of customizing your drink. We have intensity of the flavor. And can also have still and sparkling. All these things we track and-for instance also, where the user exactly touches, what movement he makes with his fingers. So we can also track that. And there from the beginning, we just try to accumulate as many events as possible. Everywhere that the user clicks, we got some periodic stats events about how the tablet is doing. And we just send it out. We don’t use it all from the beginning, but we can always use it later.
Yvan De Boeck 00:14:31.983 So the scale that we’re talking about is not so big. In fact, we got thousands of machines and thousands of events a day. And that accumulates to kind of to the order of 10 to the seventh events a day. So, that’s not tremendous, we can easily build a couple of factors there for us to create problems. And our biggest size now at the moment is around 100 gigabytes. So as a consequence, we are very pragmatic Influx users. To be honest, straight from the get-go, when this initial proof of concept was working, we did not change a lot about the way that we worked with Influx. Because a simple server could easily have handled our load if-and so when they use only one chart-yeah. And so to be honest, the sort of problems that we had were not related to Influx at all. They were only in other parts. We wanted to add business logic as much as possible in our logical layer, and Influx just worked.
Yvan De Boeck 00:15:48.918 When we look at the writes that come from the tablet, there we want to do it as quickly as possible so that the tablet can just continue to function, and it’s not dependent on anything going on on service side. So we just make connection and then we write to log file and write to Influx and that’s it. And then we’ve got Async processing, but takes over from there. So to decouple whatever influence we’ve got on the extra tablets there. We do have an anti-corruption layer. In the beginning, we were just sending events under everywhere. It was kind of free form. All the advancements, all the key value pads that were there, I mean, we made some added-one of the examples is when there was in a certain version an overflow error because of the [inaudible] code.
Yvan De Boeck 00:16:42.779 Then, we still have [inaudible] in the machines and we communicated to the duration of the drink as an integer, and that’s overflowed at around 30 seconds. So everything that’s longer than 30 seconds, all of a sudden, a negative duration. So, that was something that we, with this anti-corruption layer, we would fix that so that it came properly in Influx there. Later on, we haven’t had these problems too much. That’s still there as just a layer, because of course, when these events are created, that can be those old versions of the software and these ones, they don’t go away. We tried to stick to not rewriting history and just reporting as of this.
Yvan De Boeck 00:17:37.503 I want to say something about Idempotent events. So the UPSERT mechanism, so that when something with the same key exists already in Influx, we use that very heavily. I think because we would re-send events and then we’d write new code because we rely on the fact that we wouldn’t duplicate and count dispensers twice. And so that was very handy to use that. And over time, we just reduced the number of series and columns because that was easier to work with. In the beginning, we would create for every kind of event in all the series and then we would just standardize it. For instance, we got things like an error, which is a series, a warning, and info. And it would often go in these three categories and not in a variety of different series, because then you’ve got to have different queries to write against that. And that was not that easy to work with.
Yvan De Boeck 00:18:46.541 Next, I want to touch on these Derived Streams. As an example, we’ve got a sensor in our Bevis for the CO2. So CO2 is the mechanism that we use to get the sparkling water. And there’s a CO2 tank in there. And then to measure how full it is, we use a load sensor in the machine. And that load sensor reports its measurement in millivolts and that’s a value between 0 and 5,000 millivolts. But every machine has a different-it’s a linear model, but it has different format to derive from the actual weight in pounds. So, what we do is the number that comes or the sensor value that comes back from the tablets is in millivolts and then we’ve got millicup for this machine and for this load, so what is the conversion formula? And we start at Derived Stream and now the series of data that is similar, that has the same entry points, but has also the value in pounds. That’s one example. A more complicated example is users often mix drinks. So they would use sparkling water and then just a little bit of a certain flavor or they would mix certain flavors together. And these are all the different dispensers, but then we would bundle them together as one mixed drink and get more behavioral knowledge of how people actually use the machine. That’s also done prior to Derived Stream.
Yvan De Boeck 00:20:29.824 Having Influx from the get-go was really beneficial in a number of areas. And in software, of course, the most obvious one is that we could track errors and bugs when they were happening. In the field, we would have very fast turnaround times to see what’s going on and if the tablet is well behaving. By extension also, the whole Bevi is-the Bevi, all the people using it and so that was greatly beneficial to see that immediately there.
Yvan De Boeck 00:21:06.103 Our story in that area is that the first generation of Bevis had off the shelf tablet with an actual battery in there. Because we use a very bright screen and we got fancy animations going up, we would lose during the day when the usage is heavy, some of the battery power. So instead of having it fully charged, it would drop down some percentage. Then typically overnight, it would just reload again to 100%. But in the beginning, we ran into situations where that didn’t happen completely, so it didn’t recharge completely to 100%. And some days it would go even deeper down. And then sometimes we lost the battery, we lost a double because the battery went dead.
Sean Grundy 00:21:53.546 So when I think of Christmas 2014, I think of this. The machines, we couldn’t push updates back then. We couldn’t push updates remotely. We had to go machine to machine. So Yvan and I had to visit every single machine and plug into the tablets and try to test different fixes and see what was going on.
Yvan De Boeck 00:22:15.356 Yes. So having this Grafana view on the actual data and even remotely being able to monitor this was greatly beneficial in finding a solution to this fast. Also the hardware could go a lot faster because we have these views on how would machines were actually doing in the field. So with the hardware, we try also to have an incremental process to find out what kind of solutions work, what kind of problems do we have to solve. In the beginning, we tried a lot of different sensors to get more a feeling of how the machines worked in the reality because there’s a big difference between having something in the lab and then having actually used by hundreds of people day in day out.
Yvan De Boeck 00:23:10.566 If you would change the firmware and add a couple of sensors, for instance temperature sensors, then we could easily record it on one machine. In the beginning, all the machines were slightly different from each other exactly for this reason, but then the tablet’s software that handled this series and the Influx mechanism to start these data elements and then the Grafana way of visualizing this, there was no software involved that were derived. So it would just work completely separate from the software team. So the hardware team, they still do that sometimes to add data to our sensors and then visualize and learn from them from production.
Sean Grundy 00:24:00.708 That was great.
Yvan De Boeck 00:24:02.408 Now the best place where we learned was the user experience, like how are people actually interacting with the Bevi. And we did a lot from the beginning, in seeing what kind of interface was best and gave the best results and in a sense both from novice users, users that were completely new to the Bevi, and regular users that [inaudible] couple of times. So we had different UI’s, for instance, one where the flavor was separate as a shot after you dispensed water. And we tried that out, and we just monitored what happened and drew conclusions from there. The attached pic is just the heatmap of where people touch most often.
Sean Grundy 00:25:00.584 And some things we can even really quickly learn here are things like where to put an ingredients button to make sure people are actually noticing it. Like it’s really easy to A/B test and see that people aren’t finding-are more able to find a button in one place than another or that one icon is more appealing than another. So it’s really useful for both graphics as well as just like overall UI or figuring out what to put where.
Yvan De Boeck 00:25:31.140 Yup. So all of these areas that’s more internally from how we use InfluxData to draw conclusions. But our main product is to visualize all the standards of our Bevis for our service people. So our service people have to know when inventory goes low, when the CO2 runs out, any of the flavors or the filter when it’s due for a change, and we provide them all based on the same InfluxData, a view on that.
Yvan De Boeck 00:26:10.125 We call it the Bevi dashboard because we couldn’t come up with a more fancy name yet. It’s responsible for management of Bevis, inventory prediction, usage tracking, flavor tracking as well. So when we launch a new flavor, then we can see immediately if it’s doing well as we thought it was. If it keeps doing well, because often, when we introduce a new flavor, there’s some kind of honeymoon periods where people want to try it out, but we want to see that they actually stick with the flavor and actually continue to use it. So all of these things become very easy with the way that we assemble data and the mechanism that we just can get all the data easily out of Influx. So all the data is persistent in Influx. Also, the one that we use to manage Bevis. So when we’ve got user forms where our service people would enter data of what to replace on a certain date, that’s also kept in Influx.
Yvan De Boeck 00:27:13.593 And the pattern that we use there, we call it a Form Event Pattern. So it’s basically, instead of having a CRUD mechanism where you would just have a service visit as an object and as a grow in the database, we just have single events of field values basically that people change. And we started out as events in time and then we build a snapshot in memory basically by replaying all the events since the beginning of time. So this is the mechanism that we use in a lot of different places, and it’s very helpful for us. So obvious events, we’ve got again the same timestamp, a form ID, which is the service visit, which would typically correspond to a row in the database if you do it in the CRUD way, or field which can be nested, and value which is always in the stream, and we would convert it in the business layer, business logic layer. And we’ve got also the IP and the ID just to link it to a certain person. So we’ve got automatically history of all the events of everything that happened, everything that was added on certain service records, on unit records, the user records, all these different entities which people typically fill in forms to enter data.
Yvan De Boeck 00:28:49.079 So going back to the reads. So while our writes go directly to Influx, most of the reads, they come from a cache layer that sits between Java layer and the database. So because the use cases is that with the Ops people and the business people who want to check on flavors for instance, is that they want to access aggregate information. And we assembled that from InfluxData, but there’s always that startup time from the server. So we’ve got a couple of queries when you go deeper into the screens that come directly from Influx, but then it’s often a very narrow [inaudible] and one or two series that you query. So probably, that’s our biggest problem at this point in time, or the thing that we’ve got to look at very shortly, is that when we start up the server to warm up this cache, it can take some time there.
Yvan De Boeck 00:30:04.770 So lessons learned is that we’re still at an older version of Influx. We’re looking at migrating to the newer ones. So with this [inaudible] of cache, what we saw there was if you’ve got queries that rely on a lot of different columns, then the queries become slower. And so it is easier to just query for multiple data elements, but then a reduced set of columns. So, that’s something that we learned to try to minimize the number of columns and series. And one artifact as well, at the beginning, we had queries that would use regular expressions across series. And that works good in the beginning when you got a couple of machines, but when you got thousands of machines, that becomes too slow. And a general guideline I would say is to standardize on the names that you give series and columns so that’s related to your own codes, to standard naming of classes and methods and fields and so just to create sanity and to keep everything manageable. That’s it from my side and we are hiring.
Sean Grundy 00:31:34.314 Yeah, shameless plug to come work for us. We really do need more great software people who are interested in the IoT world. And yeah, any questions for us? You could either type into the Q&A or I guess just Chris will hook you up if you want to chat.
Chris Churilo 00:31:55.975 So you said you guys are hiring. Are you guys hiring remote as well or just in your locations?
Sean Grundy 00:32:02.375 Just in Boston.
Chris Churilo 00:32:03.652 Just in Boston.
Sean Grundy 00:32:04.307 Yeah. Our headquarter is in Boston. We do operate in about 25 states right now, either direct or through channel partners, but yeah, for all engineering and design roles, everyone is located in Boston.
Chris Churilo 00:32:20.197 Excellent. And I love your lessons learned. I think one of the things when I listen to people with their questions, when we’re trying to troubleshoot, when you don’t stick to a strict naming convention for your code, you can easily get confused. And a lot of times, people get confused between what’s a tag and what’s a field. And then they’re convinced that they set things up a certain way, but really, it’s not how they set up InfluxData, it was actually just how they named things that kind of gets a little bit confusing. So I think that’s a great bit of advice Yvan.
Yvan De Boeck 00:32:55.071 Yup. You’ll mix between [inaudible] or underscores.
Chris Churilo 00:33:02.134 Yeah. Yeah. Absolutely. We actually have a Bevi at InfluxData and I’ll make sure that we take some photos and share that with everybody. And I think when I was listening to you guys talked about the user experience portion of your presentation today, it kind of made me laugh because I do watch how people use that machine in our office. And yeah, we do have people that kind of hold the button for a long time or they just keep pushing it. You guys must get a lot of very interesting data about how people interact with that machine. And the more I think about it, the more I realize that the bottled drinks manufacturers are really missing out on all that great data. I mean, they really don’t have any idea that maybe temperature could have an impact on their products, time of day, combinations. I think you guys would have an advantage.
Sean Grundy 00:34:01.445 Exactly. And we can get information so much faster. One of the things we realized, so beverage companies have started coming to us and they’re interested in providing their beverages. Like tea companies, [inaudible] beverage companies are coming to us and they’re interested in providing their beverages through our platform. In part, because we collect all this information on where, in terms of geographies, industries, demographics, where different drinks are popular. And that’s something that if you’re a traditional beverage company, it’s often very hard to find out because you have to go through distributors who tend to want to hoard that information on their own. And even the distributors have very limited intel. All they really see is what kind of stores or companies are purchasing their products and what are the repurchase rates.
Chris Churilo 00:34:57.130 Yeah. And you guys have also the advantage of starting to have a one-on-one relationship with the actual drinker. Not just the person who bought it, but the person who actually consumed it. Okay. So we do have a question. Let’s see. So I’m going to ask, do you have any data to show the difference that InfluxData made to your service? Any type of before and after figures.
Yvan De Boeck 00:35:34.862 There was no before really. So the most characteristic thing about Influx is that it was so painless to set up and to grow with our needs. So we’re still not at all at limit of how we can use Influx. So I know that from previous experience, if I would have used PostgreSQL, for it then, I would have probably had to make a schema that I would have to migrate with how the data changes, which would be a lot more time-intensive and labor-intensive for software development. Of course, there’s other ways around it. For our use case to how Influx expects data to be organized and retrieved, it was very spot-on.
Chris Churilo 00:36:31.132 Cool. So who uses Influx besides yourself? Do you have all the engineers taking-using it in their code or do you-?
Yvan De Boeck 00:36:42.436 In the beginning, definitely. Now we try to shield them from it and we will just export a lot of data and CSV files that we would use for processing and exports or we would just make Grafana views of certain metrics directly from Influx. That’s how we would use it typically. And some people are directly writing queries, but that’s a minority I think.
Chris Churilo 00:37:10.625 Okay. If anybody else has any questions, please put your questions in either the Q& A or the chat panel. In the meantime, we’ll just continue to chat here and hopefully we can spark some questions out of the audience here. Sometimes you guys are shy, sometimes you’re not. I think it just probably depends on a how much coffee you guys drink this morning. The other thing that we talked about previously is that you guys are working on letting the users know how many bottles that they actually saved. So, what other things are you planning on in your roadmap as far as letting the user know that they’re doing the right thing?
Sean Grundy 00:37:54.301 So we are working on some interesting ways to visualize the plastic bottle savings. That’s actually a request we get a lot. People really want to see as a company or even just collectively as a whole user base like what kind of impact they’re having. Some of the other changes you’ll see from a software UI perspective that Influx will absolutely be a part of are just more and more customization, like there will be more and more ways to customize drinks. Sooner or later, there will be a way for individual users to kind of keep track of their own drinks. So if they have a goal-a lot of customers come to us and they actually want to know how much water they’re drinking. It turns out a surprising number of people have hydration goals where they want to drink three glasses of water a day, or four, or something like that and want to be able to track nutrition and vitamin intake. And we’re working on some ways they can do that in a really seamless and intuitive manner.
Chris Churilo 00:39:08.722 That’s so fascinating to me. I mean here we are collecting data just so that we can track how well this machine is performing. And all of a sudden, it opens up a whole world for you guys.
Sean Grundy 00:39:19.516 Yeah. It’s really fun.
Chris Churilo 00:39:21.147 Yeah. So much is being lost by not doing this.
Sean Grundy 00:39:25.178 That’s one of the things-one of the things that’s been fun for us to see is that we really started focusing on water filtration systems and systems that mix beverages right at the place they’re consumed. We started working on a foreign environmental goal, but we’ve realized that when you’re mixing at the point of use, all of a sudden, it opens up this world of options in terms of letting people customize, in terms of individualized tracking. It opens up this world of options that you can’t get if you’re looking at a refrigerator full of products and just have to pick one of the products out of there. There’s a lot more coming in terms of the variety and distinctness of the drinks that can be created.
Chris Churilo 00:40:16.288 We’ve heard from a number of other customers that are in this kind of IoT space that have also through the data, had some pretty good impact on their hardware design as well. Maybe they all of a sudden realized that the pressure, the water pressure was a lot higher than they expected or certain pumps don’t really work under a certain kind of situations. Have you guys had any of that kind of data influence your hardware design as well?
Sean Grundy 00:40:46.246 Yeah, absolutely. It’s funny. Do people know Redbox, the company that does the DVD kiosks?
Chris Churilo 00:40:54.766 Yeah.
Sean Grundy 00:40:55.914 So a while ago, maybe two, three months ago, I got to sit down with the CEO of Redbox and we were comparing software systems. I was showing him our software system and one of the things he found really cool and no one else has ever found this cool before is that we were tagging-basically, when we have unusual or kind of non-standard components in a machine, like say we’re testing a new kind of valve or a new kind of pump or a new component in the chiller, we’ll tag the machines that have those components. And then when things go wrong, well first off, we can really easily troubleshoot and run tests of, is one inherently more reliable than the other? But then also, when things go wrong, we can go back and look for correlations between certain components being in machines or certain changes in water pressure or certain condition changes. We can go back and correlate those with errors. So it’s really helpful in terms of just ongoing reliability. And it’s funny, it turns out, Redbox had done something similar to that. But again, it’s not that cool or exciting to talk about reliability. But actually, a steady stream of data, like via an IoT platform is extremely useful for your liability. And Tesla does the same thing. Tesla is always tracking what’s going on in its various sub components.
Chris Churilo 00:42:29.652 Yeah. I mean, you can now apply a more scientific approach to troubleshooting or introducing new components, instead of relying humans who are just going to tell stories. They don’t mean to do any harm, but they don’t often really know the cause. Whereas, data in a machine, they’re just reporting it how it is.
Sean Grundy 00:42:50.828 Exactly.
Chris Churilo 00:42:51.497 It’s either going to work or not. So I think it’s pretty cool. You can even probably come up with much more interesting combinations of tests as well because you’re just looking at the data. Is it working or not? I think you guys have a great product. Like I said, we have one at InfluxData and we got it to basically replace all the LaCroix cans that all the guys consume like crazy. And of course, they were skeptical at first because they were such big fans of the product. But definitely, we now have-we’re supposed to finish up the number of cases of cans that we have and the guys-everyone is just kind of abandoned those cans. So now our poor office manager is trying to get us to drink those cans and get rid of them. But I think we kind of got addicted to your machine instead.
Sean Grundy 00:43:46.442 Yeah, we tend to do that. We tend to have an addictive effect. We try.
Chris Churilo 00:43:55.172 So any other plans for the software? Are you going to start to introduce some more complicated algorithms or machine learning to the data Yvan?
Yvan De Boeck 00:44:07.943 Machine learning around flavors for sure. So we still have a lot of possibilities to learn about the introduction of new flavors, see how seasonal flavors are. Maybe time of days plays a role, and geographic location. So we want to have a better handle on how exactly these different parameters have influenced the flavor consumption.
Chris Churilo 00:44:39.202 We have another question that has come in. So Anya asked: “What would you advise another company attempting a similar use case that involves time series data in terms of choosing a time series database?”
Yvan De Boeck 00:44:59.674 It’s a good question. In general, I would try to formulate a problem how it is close to you, how it models your business case and try to see what translations that you’ve got to do to use something like Influx or any other database. So just stick more to how can you model the problem at hand rather than write a certain technology. And then you’ll be able to switch more quickly to another technology if the one that you choose is not that great for your use case I guess.
Chris Churilo 00:45:40.647 All right. We got another question. Thank you. So she says thank you. Okay. All right, we’ll just keep the lines open just for a couple more minutes for anybody that has any questions. You guys are hanging out here, so you must have an interest in this. But if you’re shy and you want to ask your questions later on, feel free just to shoot me an email and I’ll pass it along to every-oh, here we go. Frank Lee asks, “Speaking of Tesla, are you able to turn on new features enabled by software upgrades using hardware already in place?” That’s a great question Frank.
Yvan De Boeck 00:46:16.978 Yeah. So we use feature flags quite extensively, also on the tablets. So whenever we do these A/B tests for instance, it’s just driven by a feature flag. So we only shoot from master, from our good repository, only from master, and then the next version has all this feature flags and we cover different hardware versions of it. So the same machines from the beginning as the latest machines would-we get now a countertop which has basically the same app on it, but it’s a landscape mode versus portrait mode. All these different versions are covered by featured flags. And so we can turn them on or off from remotely by group of machines or by individual machines.
Chris Churilo 00:47:16.944 That was a really great question. Yeah. And I think there’s been quite a bit of debate around that question, especially surrounding Tesla. A little bit of criticism from some people just saying that, “Hey, you can control those updates. What else can you control? And maybe, I don’t want you to control.” Well, cool. So maybe you can share with us in general as a company how much of a positive impact have you guys made on the environment for the world?
Sean Grundy 00:47:52.199 To be honest, it’s really substantial. We calculate the number of-we average 14-ounce servings of beverages saved just because La Croix can or Polar Seltzer can is typically 12 ounces, a water bottles about 16 ounces and we replaced them both. So we put 14 as a kind of a nice rough average. And we are now consistently saving over a million bottles a month. Collectively, definitely, over 10 million since our start. It’s really a massive impact and we see it at every customer side. Like we’ll see just refrigerators that used to be stocked full every single day of cans of seltzer, regular plastic bottles of water, just getting stripped out and replaced with Bevis. And we’ll even have clients take us to storage rooms and show us like rooms that are now empty and say like, “This used to be the water. Like this room was just stacked full of cases of water from Poland Spring. So it’s really exciting. It’s really cool to see just-it’s an amount of plastic savings that’s honestly hard to visualize.
Chris Churilo 00:49:06.228 And then also, I think in one of your sites, you had an anime or a picture of a truck. You guys probably also greatly reduced CO2 emissions.
Sean Grundy 00:49:16.407 By over 80%. Yeah, it’s really a massive difference when-I mean, it literally is that instead of trucking a finished product, all we truck around is the 1% of beverage ingredient that aren’t water. So it’s just a massive reduction in CO2 emissions and it’s just cost of transportation.
Chris Churilo 00:49:41.449 So Frank has another question and he ask, “Are there any plans to build a Bevi API and allow third parties to access data?”
Yvan De Boeck 00:49:50.836 Yes, we got plans. We don’t have a timeline or a fixed deadline there yet, but we got plans of opening it up to individual users as well to see how much they’re using, as well as companies to see the usage of their Bevi. And maybe also customize some aspects of the Bevi interface.
Chris Churilo 00:50:12.858 I know that’s a question my own engineers have been asking and we talked about this a little bit too. They would love to be able to see the data that’s coming into your InfluxDB and since-so they could-it’s an interesting news case and it gives them real-world data to come and play around with. And they promised me they wouldn’t mock around with the machine. But yeah, I mean, what I would like to do so that everybody knows is, if you are a customer of InfluxData and you do have interesting news case, of course I’d love to do webinar or a case study with you. But I’m also starting to build out a little area to showcase some of these cool solutions. And my goal is to be able to even share a dashboard with all of you guys, so you can take a look at-I guess basically, how much water we consume. We also have the sensors from Spiio to water our plants in the office. You can even see how well we’re doing it tending to our internal garden. And then we have some other temperature readings and a couple other sensors. I thought it’d be cool to share with everybody real live data that’s coming into InfluxDB. So you can see that we are also [inaudible] our own technology.
Chris Churilo 00:51:39.244 Well you guys, this was a fascinating conversation. Really appreciate your time today and I really appreciate your advice Yvan. And I’m sure a lot of our customers do as well. And then Frank on your great questions. So if you guys have other questions, feel free to let me know and I’ll pass it on. This is being recorded so I’ll post this to our website as soon as we can and make sure that we get the word out. That here’s a great solution, a great alternative to all that plastic that’s being wasted. So thanks everybody.
Yvan De Boeck 00:52:14.986 Thank you guys. We really appreciate the opportunity.
Chris Churilo 00:52:18.136 And we will see you guys again next time. Thank you.
Sean Grundy 00:52:22.062 2Perfect.
Yvan De Boeck 00:52:22.415 Thank you.
