Spiio uses InfluxData to make data-driven decisions to keep the world greener
In this session, Jens-Ole Graulund, CTO from Spiio, shares how they use InfluxData to help power their data analytics service to empower horticulture professionals to understand the performance of their living green wall installations. This service provides their customers with a full digital remote overview of the irrigation development and allows them to make data-based irrigation decisions with unprecedented precision.
Watch the Webinar
Watch the webinar “Spiio uses InfluxData to make data-driven decisions to keep the world greener” 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 “Spiio uses InfluxData to make data-driven decisions to keep the world greener.” 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 Jens-Ole Graulund: CTO, Spiio
Jens-Ole Graulund 00:01.662 Great. Hello, everybody. My name is Jens. I won’t pronounce the last name because that’s very difficult. I’m the CTO at Spiio. It’s a start-up company. We started one and a half years ago but have been doing some work on the universities in the present-later years. I joined C2 at Spiio this January but I have been working with them for some time. But they got some funding here last year and then they had to scale up and we had to write a whole new back-end. So we’ve built almost everything from the beginning in this year and we’re up and running in about two months with everything renewed. Let’s talk not about the technicalities, not so much about the technicalities of Influx products, but more about how we’re using them. But first I’ll tell you about who we are and what we do and why we do it. I’m going to tell a little bit about IoT platform. What it is, how to choose them and why do we use InfluxData. We didn’t do academic selection but we have been working with IoT for sometimes and for myself some years. And I hoped to make an IoT platform myself, as a project, but now we are into something quite new. And then I will say the go-to, how we get our IoT platform with InfluxData and harness the benefits of using InfluxData in this scenario. I’ll also talk about this Spiio Time Series tomorrow. It’s very essential-this data that is so essential to our business and how we use them and especially how we use them in a InfluxData context. Because InfluxData, in the start, we just saw it as a Time Series Database. But when we tried to use it more and more, we found out that both Chronograf and Kapacitor and even Telegraf are a very good fit into our architecture. And we get a lot of benefits out of this. And I will show you this in this presentation too. And then finally, I’ll talk something about the future and what we are working on at the moment because this is not just about tech. It’s not about IoT and data. But it’s also very important to combine or connect the data and the people. And it’s working on the data and providing the data.
Jens-Ole Graulund 03:12.369 We’ve got a mission statement here that says we’re working in the greenery field. We are making a device called a sensor, a Spiio sensor that is measuring plant data. And what we want to do is to improve the service of the plants that is really taking off all over the world. What we want to do is get data from the plants into our platform and we want to also gather knowledge on weather data, irrigation circuits and all these things to make a decision of how the plant is doing and how to give a good condition for all your plants. So what is all this about? Why are we doing this? What we see is that people are flowing to the cities all over the world, traveling into the cities. And then the problem is that-well, where do you come from? You come from nature. You really miss the balance of air, sound, light, and freshness. That’s like all of you, when you take a walk in the forest or by the beach and everything, you get the-stress level is reduced, and so on. So, that’s a trend that we see all over the world. Even in the single home. So what we are seeing is a trend where nature moves to the city.
Jens-Ole Graulund 04:55.434 And here’s a picture I just found a week ago. It’s a project in China. In Shanghai with an American architect where they’re building this whole city with nature embedded in the houses and the environments. And maybe it’s a future work with the Chinese are going very green and clean tech at the moment and no wonder. But they are really investing in this case. This might seem a little bit futuristic, but it just shows where we are going with the cities. We are starting a little bit smaller. Our target, at the moment, is green walls but also office plants and all of the enterprise environments. Here’s a little picture of a very small installation we have in San Francisco, and it’s very easy to maintain, but in fact, you really don’t know how is this all doing. So here’s another one in San Francisco that is much, much bigger. And again, here you see very beautiful wall, but maintenance, that’s a problem. Maintenance of these installations and plants in the city is very cumbersome, and you spend a lot of money of maintaining these walls and especially the problem is that you really don’t know how they are performing. So that’s why we-here’s another wall and here we’re installing our sensors on this wall. In this wall, we have 50 sensors measuring data. And the wall is irrigated in different zones, different schedules, and so on, just to make it the best possible performance. But in that problem, they didn’t know exactly. They could see, they could feel, but they really don’t know the performance of the wall. And here’s another picture, the first installing the sensors on this wall, and here you see how it’s working. And you see a laptop and here it is-what we are doing here is we are installing sensor and we are registering where they are placed on the wall when we install them.
Jens-Ole Graulund 07:38.676 Now, before we started all this, we had to find out how do we make this platform that we want to drive our IoT platform. So we did some research and we had some experience to try the cloud platforms, other databases, and we made our own platforms so we know how to make our own databases in MongoDB. But we were not quite satisfied. So last year we found InfluxDB and we tried it out. We installed it and it was performing very well. And that’s really a good perspective. So at that time, we just saw it as a time series. That’s also, at the moment coming every day, new solutions to our platforms. AWS Greengrass, Azure IoT, IBM BlueMix, ThingWorx, and so on, a wealth of other platforms. And that’s really great, but how to choose which one do you want to do? There can be several options. And it’s not easy to build it yourself. We have tried to do that, but we do spent too much time, we’re not clever enough, and that’s not our core business. So what we wanted to do-we tried to find the best ingredients and then make your own recipe from these ingredients, or components, or services-you make your own IoT platform. And I think that’s the case in everything you choose here. You have to mix together to fit in this. There’s no one that fits all. And even if you select one, there’s a lot of options that you have to select. Just over here I found this-just to tell you, there’s a lot to find out. I don’t want to show all the video just like the-there’s a lot of discussion about what to choose and what is the best and so on.
Jens-Ole Graulund 10:20.861 What is the characteristics of an IoT platform here? You can try to slice it into this kind of context. You have device connectivity & security, data processing analytics. You have moving data, and some streaming. You have presentation, and you have integration. That’s a lot of [inaudible] that provides solutions for all of these in one page. Many of them use Apache Kafka, Storm, Spark, and several databases to obtain this platform. What we had chosen on that sphere is to use InfluxData both at data processing analytics-we use Chronograf as presentation and InfluxData also is some kind of integration engine for us, especially for Kapacitor and for queuing data out of the platform. The data gathering or ingestion-we’re using the ElectricImp platform, a special IoT platform for devices and that’s connecting the device to the cloud. Yeah. Just to mind-why we choose InfluxData and we had a lot of other options here. So I went to a website who taught you how to use InfluxData with Kafka. And we also read about it, and then we read down the list. And we saw that here you see InfluxDB setup with Docker. Okay. Have a run. Then we read a little bit more-so Kafka is set up with Broker, Zookeeper, Connect, and Kafka REST Proxy, and then we said we don’t want to go this way. Because we don’t need it, but some might need it, and that would be a good solution.”
Jens-Ole Graulund 12:39.533 What we also want to do is to have our own platform because we don’t think that the general platform solves all of our problems. What is especially for everyone is that, to describe the devices, the people, the organization around the platform-that’s very hard to put into a general platform where you have some restrictions. So sometimes, in this modeling integration into the business may be the hard work when you’re working on IoT solutions. Yeah. So what did we do? We pulled in not only the InfluxData platform. We dockerized everything, we’re using Docker Cloud / Swarm to handle all of our setup and DevOps work-and continuous integration, continuous development directly from our development platform. We have been using microservices architecture, of course, and we are hosting everything on Amazon but we have also tried to do it on other solutions. But we thought that Amazon was-we had for the security, we had a better means to control this on Amazon. But we could run on other platforms; Azure, or Google Cloud, or whatever. We have here is a picture from Docker Cloud. What we see here is our database. We’ve got the InfluxData. We got Kapacitor running and we have Mongo database for our device management. And for data ingestion, we don’t have Kafka. We have RabbitMQ. I’ll talk about this a little bit later.
Jens-Ole Graulund 14:45.988 All the backup of the database, the Influx database and restoring is also done in Docker containers or Docker services. And then we have a Docker Cron Service that starts in given times. We also have the influx-seed, which often only I run once. But we want to have everything dockerized. So we don’t want to go into any machines that operate from the entire cloud directly. From this platform, we are running services and we have notifications coming from post Kapacitor and getting our data for when we get backup and all these sorts of things. And then finally we have microservices. This is just some of the microservices. We have several other services running and they’re just dockerized sort of micro services. The data collection or ingesting of data is done by-we have our device sensor that is connected to the ElectricImp Cloud. They provide all the security for us. Not all, but the connection here from the sensor in the field or in the green wall is connected to the cloud. And that’s very nice layout-solving that problem for us. From the cloud, we are accessing our cloud. This is the Spiio cloud and we’ve got an API gateway, that-connects the EelectricImp cloud, connecting to it and sending data into it, into our platform. From this gateway, we are pushing data into RabbitMQ and that’s mainly because when we had to-we can stream to other interests or consumers, but we can also store the data. In fact, we could store data directly from the gateway to the Influx database, but we would like to have some kind of buffering here. This is very simple, you just receive the data, push it to the message store. This is very simple and we want to keep it simple, just to avoid any problems when collecting the data.
Jens-Ole Graulund 17:38.245 Yeah. You could have an alternative here, like we mentioned before like Kafka, or NATS, or you could also put it directly into Influx database. We also got platform monitoring. We have the Influx TICK stack running all over. And we have Telegraf running on every node in Amazon. Of course, they’re dockerized. And for login, we have the Elasticsearch stack. We have node monitoring. Telegraf running on every node, pushing data to InfluxDB and the Chronograf here, to see what is going on in the system on every node. Yeah. And here we can see Influx database on this system. This is just provided from InfluxData, all the way around. Very simple setup but especially when you’re using Docker. You’re getting this almost free out of the box. And, of course, we have Docker Kapacitor alarm set up to monitor this system. And see, we had a simple thing that just pushes Telegraf to all our services, where we call it a node monitor, and this is pushing to Influx database. And, of course, we have separated our Influx [inaudible] database and sensor data, to keep them separate. So they’re completely separated. Oh, just wanted to mention, we all worked on this analysis so we can see on the gateway when points arrive to our system. And, again, we have these Docker logs, the container logs there. It’s very simple. It’s just a [inaudible] that we have running on every node in the system. So it’s a really easy setup.
Jens-Ole Graulund 20:00.161 This was in a platform. Now, we’re going into the time series and see what are we collecting. So we got sensor data retrieved. Okay. Here we are, and the sensor takes these data once an hour, and every fifth hour send it to our database, or to our cloud platform. So there is a buffering on the sensors. We have a retention period on our Influx database that is-in fact, we really don’t know, but our data is very slow on the long term, forecast or historic. It’s very easy to see how the data of the plants evolves during a season or year. And so, at the moment we just keep all data in the database. Yeah, and that’s because we have very, very slow prints. This is not real time. This is something- that’s nothing happening suddenly on these things. It’s something that happens-we can see trends in the latest days, or weeks, or months, or years, or even a year, yes. So it’s not a data-intensive system. You have very few points, but we have long queries of data analytics that should be possible because there’s-for instance, we want to see how there’s a difference between this year and the last year, or between this or between this quarter-things are changing very slowly. We have only one database. We don’t need several databases. In fact, we started out having a database from every sensor and that was not quite the best we should do and what is recommended, but that was when-yeah, a naive implementation. And we didn’t get much out of the data when implementing this because query was-yeah, you can query every sensor, but you couldn’t query the set of sensors or other things.
Jens-Ole Graulund 22:42.105 We have two measurements again. We have one call “unassigned”, and that all of our sensor data is running into. And then we have a pound sign and letter sensor that is not assigned to an installation or you start running on the customer side. We use it if you have some malfunctioning sensors when they are pulled off the production or the assigned sensor data, then we move to the unassigned. And then we will set a new sensor in the customer installation. But we also used the unassigned database of instruments when we are-during factory test and the delivery test and so on. We have very few fields we’ve got on-that the sensor is collecting. We’ve got the moisture, temperature, light, battery. And there’s very few data, but you can get a lot of information. And, sometimes, it’s a surprise to see what you can find out with very few data. But when you can analyze it and you compare it with all our data and you find valuable information. We want to go into offices too. So here, we add some more feeds or sensor data-we’re talking about sound/noise, air quality, signal strength. And that’s where we will be able to get a lot of information about an office environment. And we that this very, very, very important to give customers, to their very interesting application.
Jens-Ole Graulund 24:42.954 Okay, this is something. Here it is. A typical model of green wall and this is where we are focusing at the moment. And we have a model we have zoning and sectioning our installations. So we have zones and typically a zone is an irrigation zones. So on this wall is Zone One, Zone Two, and Zone Three is where the waters is-can be controlled separately, into different schedules. And then we have also separation inside the zones so we can credit it to each zone. And we have the spots that we put on the installation. So what is interesting here is it’s not the single sensor that is essential. There’s one here, and there’s one here, and one here, and then it gives up some data, but that’s not interesting. Because what is interesting is the swarm of data that comes from this zone, and this zone, and this zone-and even the whole wall is interesting. So what we’re interested in is to see how’s the wall performing, how’s the zone performing, and how’s the section performing. It’s not the single sensor that is essential. So it’s an aggregation of sensors that is essential. And less important when we model the database in Influx because you want it drill down into zone, section, and spots. And we also want to have additional tags on the data because we want to-for example, the system here is a tag on the [inaudible] data. And it’ll tell us how is this built. Some of the system is built with soil, and some is built with rock wall. And so we want to compare the installation from one customer to another customer. And then we can find out what kind of system is performing best. Maybe also there are environmental factors. Is this outside or inside? Maybe inside the installation is good with this and this, this. But outside, it’s not working very good.
Jens-Ole Graulund 27:21.990 So that’s the kind of analytics that we’re doing. We’re building tags into Influx, so we can get all these analytics data. What is interesting too, is having all the data and metadata tags on these that we hopefully can do some security filtering, for example, who wants to retrieve from an installation they’ve got at home or they’ve got a supplier. And then we hope-I heard that Influx was getting that kind of security into InfluxDB. So we were not allowed to retrieve data from our other suppliers. Yeah. What is also interesting is that you can use techs and so on to generate Kapacitor notification. So you could have, for example, the moisture levels could never exceed 70%. And that is for all installations everywhere. And then you could just make Kapacitor-I mean, moisture should not exceed 70%. But by using tags like, for example, okay, from this kind of system, the moisture might not exceed 50% for example. Then you can use the tags here and in the Kapacitor Tick script or Kapacitor notifications to make special notification for this kind of problem. And that’s why my point is, like you making the metadata. My metadata isn’t tags, and you should really take care when you’re doing this, and see how you’re going to analyze-and what kind of notification you want to make. Design those carefully because if you’re doing it, you get a lot out of the box from Influx.
Jens-Ole Graulund 30:05.524 Here’s the tags that we are using. We have an installation-zone, section, spot, supplier, and system. And so please note that we have no sensor, or sensor ID, or the device. You’ve got spot on the installation, and this spot is in the section and in the zone, and then in installation. And it’s related to an owner, and the system, and the supplier. So it’s a logical model, but it’s not a physical model we have built into Influx. When adding these tags is-the future of this is that you can now do a lot of analytics. We can do it ourselves in our application but you can also use a Chronograf as we do here, to get a lot of graph. This is very not so interesting, this one. But the point is modeling techs is essential group by analytics. It’s out of the box, if you make these carefully and well-done. We can drill it down. Here we have group by section and group by spots and we have selected a installation here. And now you can see all the sensors here on this. If you take this away and only group by section, you’ll be able to see it by section. So that way you can drill down, all the way down. From the installation to the zone, to the section, to various parts.
Jens-Ole Graulund 32:05.316 So yeah, less tags. Metadata is powerful. Analytics if modeled correct and carefully, and you can also make event detection that can be scoped by tags, and that’s also very important. And I guess when I’m saying all this, you have to know where we’re coming from-situations where we have one database, one sensor-one database for one sensor. Now we have one database and many sensors, but we don’t have sensors, we have tags. We have a lot of the installation [inaudible]. Yeah. Here you see just an example from our system. We have a company here. We see all moisture and temperature [inaudible] low green wall here at this place. And we see the moisture figures here, and we see every day they are watering or irrigating the system. We got the temperature. And here we have [inaudible] around the zones. So here we’ve got every zone, and we can see it separated into zones. So if there are some zones that are a little bit high, and some are low. So you’re going to see maybe this zone has been watered or irrigated too much. So we had to hesitate with the watering here. And maybe this is too little and we have to give it a little bit more water. So the zones here is the irrigation zones. So we can see where they should be placed, and we can correct it. And even you can go into each section and see how-within the zones, see maybe that is-maybe there’s no proper-there’s a problem with the zone but it might be a special place in the zone. So here we can see by sections. And we really have one here that is very, very strange that we have to dig into and see what is happening. And even if you are very, very interested and want to drill down to the sensors, you can get the sensor picture and you can see all the sensor and what they are sending. Yeah.
Jens-Ole Graulund 34:54.461 So this is what we’ve got with the Influx database, and Kapacitor, and Telegraf, and Chronograf, out of box. Very easy to operate and install. And now we are going to make the apps, to take the value out of what we’ve here in the last months. We want to generate, for example, new time series based on the data we received. One example looks like we got the detected irrigation time, we can find out. So we can generate new data from the data we’ve got. We can do this with continuous queries for Kapacitor or whatever. We have not selected quite yet. We want to add more into anomalies status reports. Now what we want to do is that we have a problem because sometimes we see something, an anomaly, but we don’t know why it has happened. So we want to fill the gap between all the graphs that you saw in the former slide and find out what’s happened. The problem is that you’re looking at all these graphs and data-raises more questions than answers. Why is this happening? We don’t know. We can call the customer, or the customer can take a car out to the site and see what is happening, but there might be something that triggers this. We’ve got it with Kapacitor. So, okay, that’s fine. You can get it an alert that the moisture is okay and now it’s critical and okay. We’ve got a lot of these, but the problem is why is this happening? What’s the reason? Who should be called to find out what is the problem here?
Jens-Ole Graulund 37:01.445 So every time you see this we have question marks, question marks, question marks. And then we went into, as I call it, detective mode. What is happening and what should we do? What we need is some kind of context, so what we will do is try to make an application that we can enter-use the data in a structured way. So a standard Facebook-like thing that the-from Kapacitor we will push data into this feed and the user can also feed data with the visual inspection or change in irrigation times and so on. So for every installation, you have got to have a timeline of what is happening and who, and people communicating and what is being said about this installation. And this gives us a context about the data. So I said that we want people and sensors to communicate and share information, and the reason we want to do that is to find out what happened when something goes wrong.
Jens-Ole Graulund 38:15.285 This is just an example of what we’re going to do. We’re just starting with some prototypes at the moment. But we want to combine these data that you saw in the last slides. And you can see everything is moved. But there is something here, that’s happening. What happened here? I don’t know, but something happened. And if you have this data from the plant technicians or the people using the system or operating this system in a timeline, you could almost say the time series stuff, user data connected to this graph. Then you will have some context of what happened here. So maybe there was a plant technician out here that just screwed up a little bit for the water, and then came back later and screwed down. So yeah, that’s what we want to do here. So context to data is very essential and I guess that’s not a special case for us but for everyone. Now what we want to do is to discover new data in the former slides. In fact, as you see here, you can see the irrigation pattern here. So we want to, in fact, make an irrigation data series. So we want to make either a continuous series in InfluxDB or maybe Kapacitor and make new time series. And that’s why we can, for example, make a new present irrigation patterns in our application based on time series database. So that’s what we’re going to do now. Yeah. That’s all I had to tell you.
Jens-Ole Graulund 40:21.526 We can use and we use InfluxData to power an IoT platform as the central piece in our solution. And what I also want to, with this presentation, is to tell you that, in fact, this is much more than just the time series data. It’s a sort of data processing, streaming, analytics, and certification that you get in this box. And, in fact, we started using InfluxDB just as a downtime series database. Putting data in and querying it out and presenting in our graphs. But the more we delved into it, we found out that we could use it for processing and [inaudible] notification. And what we did was we carefully model our case around this with the tags, especially since it gives us a lot of out-of-the-box functionality. Yeah. That’s what I got, so I want to say thank you, and if you got any question, then please you’re welcome.
Chris Churilo 41:38.094 Wow, Jens. That was very informative. That was a lot of details there, and it was pretty cool to see all those graphs. You guys really did a good job of architecting it so we can see all the way down to the zones, or the sensor levels. That was, I think, really nicely done. We’re going to keep the lines open for a few minutes because we have some questions. And, Jens, I’m just going to read the questions out loud so we can have them recorded. So Seri asked you, can you give some figures about your Influx data? Like the size of your Influx database.
Jens-Ole Graulund 42:21.127 Yeah. I can do it, but we are not that big yet. In fact, I don’t know. Really, I can’t give you any figures. I can only tell you that we have 15 installations out there, and they are running from 2 sensors, and the biggest is 50 sensors. So we are not-I can give you the sizes but I don’t think you will get anything out of it. But we did some performance testing before we started and we have what we call a “canon” that can simulate pressure on our system, both on the RabbitMQ and on the Influx database. And really I don’t think we have any problem with performance at the moment and in the foreseeable future because our solution use is not data-intensive. What is interesting for us is the capability of making analytics out of the data. And it’s not real-time tech. So, yeah, I couldn’t give you any figures, but I could give you some talk.
Chris Churilo 43:44.711 So, Seri, hopefully that answers your question. And I’ll keep the lines open for few more minutes. Please feel free to ask your questions. And if you don’t remember your question or want to think about it a little bit more, feel free to send Jens an email directly, or you can send it to me and we can definitely forward the questions to him. Don’t be shy, this is a great opportunity to talk to someone that’s using all components of the TICK stack and so if you have any questions-I know we have always a lot of questions about how to use Kapacitor. This is a perfect opportunity to post your question. All right. We have another question from Seri. So what’s the number of users that are using Chronograf concurrently?
Jens-Ole Graulund 44:43.141 In fact, at the moment, we are only using Chronograf internally. We are using Chronograf internally for the [inaudible]. And then we are doing the analytics. We have apps for our customers out there. They have the graphs, and then all the information they can see themselves. But we have not got this tuned down for facilities and time perspectives like we get on Chronograf. And, in fact, we have a little problem. We would like to give some of our customers Chronograf, or some specialized customers, because this is not a tool for the plant technicians. They don’t want to use it. Maybe they could, but they don’t want to sit down and look at data. I guess, we have some security problems because you can’t hide and you can’t separate the data from one customer to another. So that’s a problem with the InfluxDB at the moment. I know that they are going to solve this problem, but at the moment we’re not able to get in to answer for our customers. Yeah.
Chris Churilo 46:13.375 All right. We have another question from Seri. So he would like to know, how many notifications from Kapacitor daily?
Jens-Ole Graulund 46:22.205 Oh [laughter]. I don’t have the numbers but I think we get too much because-yeah. That’s also the thing when you’re using all these-it’s no problem where from the IoT operations perspective because you know if the CPU is hitting 80, 90 percent we have a problem. It’s not easy in our system. We have only have been running this data for two months so we have to take more data into the system to be able to find out where should the levels for notification be? At the moment, we get too much false positive notifications. So we want to limit this if possible. But, yeah, I don’t have accounts on how many we get now. Even if I had it, I don’t think it would be very informative because we are a start-up. And we just start this platform with 10 or 15 installations on it at the moment, so it’s not stress test at all. Sorry. But, yeah, that’s the-
Chris Churilo 47:58.408 So, Jens, if you could give advice to somebody that might be considering building their own IoT platform today, what advice would you give them?
Jens-Ole Graulund 48:12.511 Oh boy. Yeah. I would advise them to start up simple and quickly and find out what kind of data do you need. And maybe that would be going by IBM Bluemix or some of these off-the-shelf IoT platforms. But my point is that you can, I guess, more quickly, go with the Influx suite of products and build it very quickly, and up and running fast. We have done several investigations about using Elasticsearch, OpenTSDB, and all of the reading of documents. And you can read and read and read. Sometimes you have to take a decision, and we did that. We’re very happy about that. Yeah. So yeah, start out simple. And it’s is very important that-I find important that-we have a development environment, where you can sit and develop with Influx database and all the servers locally. I’m totally isolated and when we are finished, we are doing some progress with it. It’s exactly the same environment, almost exactly the same environment that we are using in Docker Cloud. As a technician, I would also take that into consideration. That’s having an effective development environment. Yeah. And I really feel we have a super-effective development environment at the moment that we build up here. And I’m developing something now, and I have Influx and everything running locally on my database and I can debug. You can see all the logs and everything. That might be a problem, if you go into-make something on the cloud platform because that’s not easy to develop on there, or in local and in cloud. Yeah.
Chris Churilo 50:52.176 Well, I think that’s [crosstalk].
Jens-Ole Graulund 50:52.875 [crosstalk] That’s my points.
Chris Churilo 50:57.583 Well, I think it’s very sound advice, Jens. Keep it simple is definitely the right way to go.
Jens-Ole Graulund 51:04.663 Yeah. And I think we’d keep it too simple at the start [laughter]. But that’s the way we are and that’s all right.
Chris Churilo 51:19.949 Well, excellent. So we are almost at the top of the hour and I’m going to shut down the session and just end it here. But I want to remind everybody if you have any other questions, feel free to let me know or you can contact Jens directly yourself. I do want to-
Jens-Ole Graulund 51:35.827 Welcome to contact me at any instant.
Chris Churilo 51:42.128 And I do want to thank you, Jens. I think this was an amazing presentation, so detailed, so informative. I know we already got a number of questions earlier for the recording because there are a lot of people that want to be able to take a look at this presentation, at their own time. And I really do appreciate your time and I will be chatting with you again, I’m sure. And everyone else on the phone, just look for the email today that has this and if you have any questions on InfluxData, any of the components of the TICK Stack, don’t forget to go to our community site. You can put your questions there, and we can make sure that we get them answered as quickly as possible. So thanks for participating, everybody, and thanks especially to our speaker. And I hope everyone has a pleasant evening.
Jens-Ole Graulund 52:37.115 Yeah. Thank you.
Chris Churilo 52:38.806 Thank you. Bye-bye.
Jens-Ole Graulund 52:40.373 Bye-bye.
[/et_pb_toggle]
