So, for this talk, we're going to be learning how to build a plant monitoring app with Influx
DB, Python, and Flask with Edge to Cloud Replication being an option onto this project.
So first things first, my name is Zoe Steinkamp, I'm a Developer Advocate for Influx Data,
which means I have a large empathy for developers myself.
I was actually a front-end software engineer for over eight years before I decided that
I wanted to actually be able to listen to people's issues and fix them instead of just
hear them come down from the product team.
So if you guys have any questions, I will be allowing some time for Q&A during this
presentation at the end, but if you want to reach out at any point or you just like to
be friends with people on LinkedIn, this is my QR code.
My name is relatively unique, I'm easy to find.
The overview.
So in this presentation, we're going to be walking through a few different pieces for
this project.
The first thing we're going to be walking through is the IoT hardware setup.
So if you guys are not super familiar with like IoT devices and stuff, not to worry,
I'll break it down and then we can kind of figure it out.
Also all of this is available on GitHub, all this code examples, there's lots of instructions,
this is a very well fleshed out project.
So at the end, I'm going to be linking that as well so you can do it yourself at home
very easily.
We're going to go over the tools that we're going to be using for this project.
We're going to go over a short interview, a short overview of InfluxDB just so that
with people who don't understand how it works, we'll understand how it works in this project.
The data ingestion setup, Flux and SQL, setting up edge data replication and data request
which are kind of comboed together somewhat.
And then finally at the end, the GitHub code base, links to other community links and such
and then Q&A as well.
So setting up your IoT devices.
So this is a handy little diagram to show roughly how this is going to work in real life.
But basically you have a plant and you're going to be monitoring it, you're going to
need some kind of microcontroller to receive this information.
I'll show a haphazard photo in a second of how that's going to look.
But basically from that plant, we're going to get data roughly about, I like to say,
how the plant is feeling.
If it's thirsty or hot or just doesn't like you in particular, it'll let us know.
From there, we put that data into our open source, our OSS instance.
So InfluxDB is available open source so you can just easily download it off GitHub and
get it running locally.
So in that, we're going to go ahead and store our data.
We're going to use a telegraph, that's what that little tiger is, we're going to use a
telegraph agent to get the data inside.
From there, if we want, we can go ahead and use our edge data replication feature to go
ahead and push it to cloud.
And then the idea here is that you can also host this locally, like you can host a little
website with graphs and such.
I'll be showing this as we go and the code is available.
But basically the idea here is that you store your data locally, you use edge data replication
to push it up into the cloud for longer term storage or just to have less data loss.
And then from there, you can pull that data back out to actually start graphing and visualizing
it.
As promised, haphazard photo.
So for this project, you need in no particular order, a plant, preferably alive, those are
the best to monitor, a particle boron microcontroller or another compatible one.
We have the schematics and the details for an Arduino, if that would be your preference.
At least one IoT sensor for your plant and a breadboard with jump wires and terminal
strips.
As promised, this is what the schematics look like.
So basically you can just kind of follow these schematics to the T and that helps you just
get everything set up.
We especially had certain issues with some of our sensors, what's the word, interfering
with other ones.
From that, I have four sensors for my project, those are the four that I just happened to
buy off Amazon, which we do list, so you can, depending on your country, it will change,
but these sensors are like 25 cents a pop, so they're really cheap and easy to get.
I have temperature and humidity, I have light, I have soil and moisture, and I have temperature.
So with all four of these, I can go ahead and hook them up to my breadboard and my microcontroller
and I can start getting some of that data.
So the tools we're going to be using today.
So we are going to be using Flask, which for those of you guys who are not aware is a micro
web framework written in Python.
It's going to be doing some of the heavy lifting for the project, specifically it's going
to be running the local application and allowing us to have some built in routing.
We're going to be using InfluxDB for actually storing the data that we get from our IoT
sensors from our plant.
It comes with an API and tool set that's going to be easy for ingesting and querying that
data back out.
It's highly performance, so we don't have to worry about it running up when it's open
sourced.
It doesn't cost us anything outside of the server we're running on locally, but in general
we want our data to be stored efficiently.
And then it also has obviously our community and ecosystem.
People like me there to help answer questions and come up with these awesome little projects
like monitoring your planted home.
Telegraph is a completely open source ingestion agent.
It has over 300 plus different plugins depending on what you need and desire.
For this project we use the exact D processor plugin to get the data into our open source.
I'm also going to be showing code for what I'll actually I'm going to explain that later.
But basically this is super nice to use.
It has a very wide range of open source plugins supported by sometimes companies, sometimes
community members.
You'll find serious ones like Azure monitoring or AWS monitoring to the more fun ones like
Minecraft or CSGO.
For some reason you do not want to use Telegraph, maybe it just doesn't have a configuration
that works for your device or your project.
A lot of people are just going to go to the client libraries which I'll be showing a code
example on how to use these as well.
And this does live inside the project, so you don't have to worry about like going and
finding it.
We just left it there just in case people want to use it.
So obviously it's got a few different options here.
We're going to be using the Python one because that's the one I've worked in and that's what
the project is written in.
Another thing that I use when I built up this project is the flux extension for VS Code.
It's really nice in that it allows me to write my flux queries and it kind of tells me if
I'm misspelling or writing things wrong.
It's just like any other extension that you're going to get in VS Code.
It highlights things and helps you realize when you're making mistakes.
Finally, we're going to be using plotly for graphing.
It is a completely free and open source graphing library which is always our favorite.
And it's really nice and easy to work with and very colorful which I appreciate.
So a really quick overview.
So for those of you guys who are not quite familiar with it, time series data is a very
specific type of data.
So it's what we're going to be getting from our plant because IoT sensors tend to give
you time series data and the fact that it is metrics regularly intervaled at time.
So what that means is that you want to know at what point the plant got thirsty or you
want to know how many hours a day did it get sunlight.
That's all time series data.
That's data that you want to know about on a time scale.
We normally see these as metrics at regular time intervals.
Occasionally we see things like events.
You can think of things also like the stock exchange or weather conditions as other great
examples of this type of data.
We tend to find these in multiple different applications.
The software infrastructure is probably the most common and most people here would understand
where that comes from.
Obviously for this one we're going to be using IoT data.
So one thing to note is if you had multiple plants at home, you might want to store that
data like you might want to know that you have six orchids and seven aloe veras.
You store that kind of data in a relational.
You'd name them.
You'd say this is the one that lives in the window on the north side of the house.
This is the one that lives in the window on the south.
And by the way, one of my coworkers totally did this.
He has like a hundred plants in his house.
So he organized it in his SQL DB, his relational, because this was a lot of plant data.
But then when he was actually monitoring all of these plants, which I really don't know
how he set this, his house is just full of cords.
It's just cords everywhere.
When he set this up to actually start monitoring all of these, that would be time series data.
So that's going to be all of those timestamp metrics coming in.
So this is kind of how the entire platform looks when it's all put together.
So as you can see, you have your data sources, then you have telegraph in the client libraries
as well as things like native ecosystems, which we're not going to go into today.
And those are the ways of getting the data in.
And from there, you can use Inflex DB to set up things like triggers and alerts, things
like you can get, I have it set up to send me a text, be it Twilio, if my plant needs
some water.
I use it quite often at my job and then promptly ignore the text.
It doesn't work out very well for the plant or me.
But if I actually paid attention, this is very useful to use.
And finally, obviously with these kind of data, what's the data stored once we have
it being used, maybe down-sampling it, we can actually start seeing some results.
Obviously, infrastructure insights isn't quite what this is, but more like plant insights.
So when it comes to data ingestion setup.
So I'm not going to go super in depth on how to set up your microcontroller, because
depending on the one you're using, it's going to be different.
They're all going to be very varied.
You're just going to have to follow the instructions on that one.
If you happen to have an Arduino or a Boron microcontroller, you could probably follow,
I mean, you can follow our directions anyways, but those are probably going to be pretty
easy to set up because we talk about it.
But this is just an example of how the data tends to come in.
So as you can see, I've got my port set up and then I start to get these data results.
So for example, if I remember correctly, this one is the humidity one, this one is the temperature.
As you can see, this is like the first, I'm going to call it the first flush.
So sometimes the data comes in as zeros at first and then it starts to actually give
you values.
One thing to note, and I'm not going to go over it in this presentation, but you can
see it in the GitHub, like in the repository in the code.
We do tend to do a little bit of cleanup on these values.
The data sensors are not exactly friendly in how they send you data, so I'm going to
put it.
So we did have to do a little bit of our own cleanup in Python, which luckily we supply
to you.
So if you're using roughly the same ones, you can go ahead and just use what we have.
But like, for example, our temperature kind of came in a little bit weird and we had to
change it so it actually read in a more human readable way, and we haven't yet fixed the
light one.
So it just looks really strange.
Interesting.
I expected my video to show up.
Well, oh wait, it is up there.
Aha.
Well, let's see, can I get this to work?
Not quite.
Sorry, guys.
Little difficulties.
Well, go figure.
This was working on my own machine, you know, five minutes ago, but that means nothing.
I'm going to try and press, is there like a play button or something on here?
All right, I'm just going to give up.
So basically what this shows is how to set up your bucket in token, which I can actually
probably just pull up.
I'll do it at the end of this presentation.
We're going to do this on the fly.
I'll show it at the end, but basically it just shows you in the UI how you set up your
bucket, which is just your database.
You can pick for how long it wants to have a retention policy.
That's how long you want to store the data.
Maybe you only want to store it for a day.
Maybe you want to store it for 30 days.
You pick that at the beginning.
And then it also gives you the option to do a explicit or implicit schema.
And what that means is implicit just basically builds the schema off what you send us.
So if you start streaming in data, we'll build it for you.
Explicit is you tell us exactly how you want your data to be formatted, and we will reject
any data that doesn't meet that schema.
Obviously in a project like this, which I like to call pretty low risk, like it's not
a big deal if the data is not quite perfect, just do the implicit, make life easy for yourself.
But we give explicit as for more professional projects, I suppose you could say, where it
really does matter that you reject that bad schema data.
The other thing I showed is just how to make a quick token, because obviously you're going
to need a token to actually get your data in and back out, you need those authentications.
One thing to note, we do offer a all access token.
We kind of warn against it, it even has a big warning on the screen saying, please don't
do this, because it allows you full access to all of your buckets, all your databases,
and it allows you to delete them.
So if that tech, whenever falls into the wrong hands, or maybe you make a mistake, or your
coworker makes a mistake, you know, somebody else, that can obviously cause a lot of problems.
We like to call it basically creating your own big red button, you don't need to do that.
So we also give you the option to pick, write and read tokens where you specify which buckets
you want them to have access to.
Again, I'll just show this a little bit later.
And you can do it in the CLI as well, but normally when the video loads, the UI is a
little bit more fun to visually see.
So let's see, there we go.
So for this code example, it's pretty straightforward as to how to actually set this up.
As you can see, we have the influxdbclient.point.
The influxdbclient is already set up in this example.
Basically all you give it is your bucket and your token.
You just basically say, this is where I want my data to go, and I have the authority authorization
to actually do it.
It's very straightforward and easy to set up.
It takes like a second.
But basically once you have all your authentication going, you can actually start sending those
points up to your database.
So with this one, we're calling the point sensor data.
We're setting the user.
It says it's not visually here, but it says Zoey, just as my name.
It's not very special.
Then we have the tag, which is the device ID.
And then finally the sensor name with the value.
So that's going to be something like humidity value 30.
And basically from this, this is running in a Python file script that just is pretty much
running as long as we're getting data.
But basically this is a straightforward way to get it in.
And this is using the Python client library.
This is part of the Telegraph config file.
This file has like, it's computer generated, so you don't need to write 200 lines of code,
but the actual config file is like 200 lines of code.
This is just a small snippet at the end of it that basically says that we're using the
execd processor plugin.
And from here, we're just telling it what measurements and what tagged keys to accept.
Again, inside of the GitHub project, we kind of go a little bit more in depth.
But the big thing is that every Telegraph config file and instructions are slightly different.
So there's no necessary reason for me to show you the execd one when you could be using
a different one for your own project.
But basically, just follow the documentations for this.
It's super simple and it's very well documented.
Well, I guess I shouldn't say that since it's open source.
So some of them are less well documented, but most of them are great.
And this is a table example of the resulting data points.
So as you can see, we have our sensor data with a field of, but this one we have a light
and soil moisture.
We have our value.
And as I told you before, the values kind of come in a little bit weird.
I don't know how soil moisture can be 1,372 point, many zeros and fives, but it can be.
And then finally, the actual timestamp value, which says that obviously this value was from
last year in like, I can't even think September, August, sometime in the early fall.
So flux and sequel.
So I've said this word before and I haven't really explained it.
But basically what flux is, is it is the querying language of influx DB.
So basically what it allows you to do is query for your time series data.
It can do a lot of really awesome things.
It can do things like the alerts, the management, but for right now we're just going to focus
on the querying because that's the most straightforward thing and that's the main thing that you're
going to end up doing.
So in this versioning right here, basically what it's saying is from bucket, which again
is just from database.
Go ahead and give me smart city.
Give me the range.
This is a range of one day.
It's got to start and a stop.
You do not have to give it a range.
You could literally just do from bucket, give me everything.
You normally suggest you try to use a range because obviously, I mean if your bucket only
has like one day of data, it's probably not a big deal, but if it has the past three years
of data, that's going to be a while to come in and that's going to probably crash a lot.
And then you have your filters.
So with this one, what they're saying in more human terms is they're saying give me all
the bicycles that have come through with the neighborhood ID of three.
And what they're doing down here at this aggregate window is they're saying give me the mean for
every one hour.
So because this is one day, this is a one day range, this will return 24 data points.
It will give you the mean amount of bikes that came through every hour in this neighborhood
with the ID of three.
And the one below it is doing the exact same, but it's doing it for the ID neighborhood
of four.
And then finally at the end, it's comparing them and it's getting a difference value.
It's saying how many more bikes go through neighborhood three versus neighborhood four
or vice versa.
And so that's just one of the quick queries that you can do.
The aggregate window is super great, especially for a project like this where you may be,
although your IoT sensors will send you data every single nanosecond, let's get real here.
Your plant, you don't need to know exactly what was happening to it.
It's better to just get an average of how thirsty it is or average amount of light.
You could bring it down even to five minutes.
Like it does not need to be quite as in depth.
And even for this one, they just wanted to know the mean amount of bikes that were coming
through the city in these neighborhoods.
This is how it actually looks like in our project.
So the reason that you're seeing all these empty brackets is this is a reusable query.
So we can say from different types of plant buddy buckets, or we can say different device
IDs or different fields.
So again, the field is going to be things like the humidity, the temperature, the moisture.
And device ID, I actually, for my project at least, it's always the same because I only
have one setup.
But if I had multiple plants with multiple values, I would have the device ID basically
being probably really the plant names, but I could say like Arduino one or Arduino two.
But for this project, it's relatively smaller, so it's just easier.
So change is here.
So this doesn't really matter if you decide to do this project all in the open source.
It won't matter really for you for a while.
But one thing to note is if you do choose to do edge data replication, Influx CB cloud
is now going to be allowing SQL.
So you're going to be able to query your data back out using SQL instead of Flux.
And we're also going to be supporting flight SQL plug-ins, which will allow you to connect
to things like Apache superset and Grafana.
I'm obviously going to be showing plot leaf for this one, but these are going to be options
for you in the future.
So it's just something to keep in mind.
So let's get into edge data replication.
I'm going to leave this up for just one sec.
So normally when I say edge data replication, people kind of think of varying things depending
on your job or depending on where you've heard it said before.
Some people think of a solar panel in the middle of nowhere in the woods.
That's the edge device because it's, I don't know, at the edge of civilization basically.
But an edge device can be something as simple as a cell phone.
It can be an ATM sitting at a bank.
It can be a factory that just happens to have intermittent Wi-Fi because today or this week
got an ice storm and the internet went out.
So an edge device can really be almost, it's more broad than what we normally think of.
It can be almost any device that it's important that it always stays connected, but that doesn't
mean that it will.
Or in the case of some people, it's your work server that happens to be sitting in your
office that goes out because the power went out of the office and now somebody's getting
the phone call at 2 a.m. to go to that office and fix the server.
That's why cloud computing is great.
So basically what edge data replication allows is it allows you to run your InfluxDB OSS instance,
your edge, and basically it has a dispatch queue which holds that data.
So as you can see here, you have your bucket, you have your queue.
There are limits to how much data you can hold.
You can check out the documentation to find out all the nitty-gritty.
But basically from there, if you ever have like, you know, you ever have internet blackouts,
you ever have power loss, you will have that data backed up.
And then when it reconnects, it goes ahead and sends it to the cloud.
Now obviously I would hope that nobody has plants that are so important that they necessarily
need to back up their data.
But I also like doing this because I monitor these plants at conferences, like they come
with me when I'm doing basically what the people outside of this room are doing.
Sometimes I have a plant at our booth where I monitor it and although this conference
has been really great for Wi-Fi, not all of them are so wonderful.
And so it's actually not uncommon for me and my plant to lose Wi-Fi and then I can use
the edge data replication to still push that data up to the cloud once I reconnect.
Or I close my laptop when I go to lunch and then it stops running, also not super great.
But basically this is pretty easy to set up and get going on.
So these are part of the setup instructions that are in this project's read me.
So as you can see, we're running our InfluxDB OSS edge on Docker, so it's a Docker hosted
OSS.
And basically what the command in the second portion does is it just sets it up to be a
edge device.
It's just saying like, hey, do the config create, plant buddy edge, this is going to be where
it's coming from, it's the open source version.
And then the rest of these instructions are basically just for the USB ports and such.
Like I said before, we have some pretty in-depth documentation on how to get this project going.
And then these are the two big commands that you run.
And they're pretty straightforward.
Basically all you need to do is just have all of your information for your OSS, so that's
going to be that bucket that we named before.
You're going to need to create that remote connection.
And then finally you need to do the replication command where you're saying replicate between
the local bucket ID and the remote bucket ID.
So as I said before, I'll show how you actually create the buckets, but for the cloud as well
as the open source is the exact same, you just basically create the bucket, you need
to get the ID for it, and then you're basically just saying, this is my local bucket, this
is my cloud bucket, please make sure the data goes up in that direction.
So data requests and visualizations.
So when we are querying data back out, this is using again the Python client library,
which although Telegraph does have a few output plugins, they're not relevant for this specific
project.
You could check them out if you wanted to send your data to a different way, a different
website or such.
But basically all we're doing here is we are using one of those flux queries, the same
one that I showed from an earlier slide where it's basically just saying, give me the data
for the past roughly day for this bucket with this value.
And from there, you have your params, you have your bucket, your sensor name and your
device ID, which can be submitted, like I said before, it's like a drop down that you
can pick from, and basically once you do the query and you do the open.read, you're going
to receive that data back.
And you can receive this data back in different ways, but we're doing it in a data frame because
that's the easiest for graphing implotly.
This is currently in, what's the word, we're working on it.
So we're currently working on getting this project to be integrated with SQL.
That's going to be my task when I get home tomorrow on Monday or Tuesday whenever my
flight lands.
But basically from here, this is how it's going to be instead executed.
You're basically just going to be using a SQL command and getting a very similar readback.
With this one, we're just getting a, what's the word, like a straight read, we're not
doing it into a data frame, but that is going to be something that we're going to set up
and be an option.
So if you do want to use this in the future, just wait like by the end of the week and
we'll have that project up as a part of the plant buddy repo.
And finally actually graphing the data.
So it's pretty easy to actually graph the data inside of plotly.
So as you can see, we have a few different line graphs, which are set for soil moisture,
air temperature.
And as you can see, we're setting a few, like these are the values that we're setting here,
like the graph default device ID, we're sending in that air temperature, and we're getting
it back in a graph format.
And this is going to be another case where we're going to see if we can get this to work
because I really want this one to work, darn it.
I actually wonder, we're going to try something a little bit weird, see if we can get this
out of the presenter view.
Oh no, escape.
There we go.
Okay, this is not really ideal, but we're just going to have to go with it, I think,
maybe.
Man, it's really just not liking it, huh?
I don't know why, what is this?
Oh well, that's not helpful at all, darn.
One second, I'm going to drag this onto my screen and just see if I can do it.
I guess it just doesn't like the HDMI today.
Check the other Wi-Fi, the dual stack one.
I'm on the FOSDOM one.
Yeah, there's a FOSDOM dual stack, which is IPv4.
Try that one.
This one?
Yes.
You think it's internet?
Not every Google thing likes IPv6.
I'll also refresh this really quick, see if that helps at all.
Yeah, just really, it's so funny that, yeah, it was working before, but now it's just not
liking me.
All right.
Oh, you've got to be kidding me.
All right.
I've got it working.
I think I just actually need to change my share settings.
All right.
We're going to go ahead and change the way this is shared.
Do you know how to change the settings by any chance?
I thought it would just change it, but it didn't, like, just change it to just look
at this.
Just look at this screen.
Oh, I don't think.
No.
Okay.
Hmm.
Fair enough.
Yeah, it's just, like, it's not, all right.
Here we go.
Mirror display.
It's all these new updates.
I never know where anything is anymore.
Okay, so it really is just the display thing, I think.
I think it just doesn't want to work.
There we go.
Okay, cool.
So, I'm so sorry, guys.
I didn't realize it didn't like my share.
Okay, so I'm going to go ahead and full screen this, and we'll just go back to the other
video because why not?
So this is how it actually looks in the end.
So as you can see, it starts to actually make a little bit more sense.
But basically, you can pick your fields.
So this is, like, a graph where you can kind of change it as you desire.
And you could also pick your bucket as well, which I might show in a second here on this
video.
There we go, yeah.
So you could pick one of these many buckets.
Most of these are not relevant to my project.
They're just the buckets I have in my cloud account, or rather, my open source.
And so as you can see, these are the two, I'm going to go back to this part of the video.
These are the two hard-coded graphs.
So as I said before, the original values sometimes come in really weird.
Like, I don't know why the heck humidity went, like, all the way up to 90 and then dropped
all the way back down.
We normally do a first flush of a lot of this data when it first hits because it just kind
of comes in funny.
Or maybe I breathed on it.
Who knows?
They're relatively sensitive.
It really does happen.
But also, we had to do a little bit of exponential smoothing as well.
So like, we smoothed out the soil moisture because it used to look like the air temperature
does.
It used to just, like, kind of jump around like a crazy thing.
The plant did not move between, like, the frigid air to back inside.
It's just these sensors can be a little bit temperamental.
We bought the cheapest ones off Amazon.
We can only expect so much.
If you spend a little more money, you're going to get a nicer setup.
So let me get at a full screen, please.
And I can just not win today.
All right.
Nope.
Now, you just want to play.
Okay.
So these are some of the new visualization options for Flight Sequel.
We're also going to be adding these into the project, so you can check it out.
We already have pretty good integration with Grafana as well.
So if you would prefer to use them for your visualizations instead of Plotly, you're
more than welcome to.
And then these are those further resources I mentioned before.
So this is the try it yourself.
So this is where the actual project lives.
This is the QR code as well as the GitHub.
If you look up Plant Buddy on the Internet, you'll find this.
And then we have a few different versions depending on what you want to do, including
the edge data replication version, which I've mentioned here.
Oh, I almost forgot about the other video.
Let me go back up to it really quick.
I like the videos because it means I don't normally have to jump around super crazily
and go in and out of the Cloud UI.
Too bad it sometimes comes in as like, it's funny, it's set for the high quality, but
it never really is.
I'd go back to Slideshow if you would be so kind.
There we go.
So as I was saying before, the create bucket is pretty straightforward.
You just name it.
And then as you can see, the delete data is set for never or older than a certain amount
of days or time.
And then that advanced configuration is the schema that you can pick.
And then finally, the API tokens, also pretty straightforward.
You can do the read-write, which is what I do suggest.
This all-accent is the big red button that I mentioned earlier.
As you can see, it's got the warning to don't do this.
I do it because I don't care.
I like to live life on the edge, haha.
Horrible jokes.
It's a great specialty of mine.
But if you decide to do this the right way, this is how you would normally do it.
You can pick your buckets for read and write.
And you do need to have read and write if you want to use it in this context.
Because if you just have read, it won't do you any good.
If you don't have, I mean, I guess you could do one, but then your data is stuck inside
and you can't do anything with it.
So you need both.
So that's that video.
So I'm going to go back to the end of this.
It's great.
This thing never escapes.
There we go.
Awesome.
So this is our community Slack.
I'm also going to have a slide next that will have all of the, like it's the one to take
a photo of.
You don't need to take any photos of this one.
But basically you can come join us in our Slack community.
I'm there.
My coworkers are there.
We love to hang out and talk to people and take feedback as well as questions.
It's pretty active.
We get like 100 messages a day.
So we're always busy in there.
And then for getting started yourself, you can obviously head to the Influx community.
It has a lot of projects as well as the Influx code base.
So you can go ahead and download that open source versioning.
And if you want to get started, that's our website, this is also where you're going to
find things like our documentation.
And this is that slide that I promised that kind of has like everything.
It makes it really easy.
So for getting started on cloud, if you would like, the community is both the forums and
Slack.
Slack is our more active community.
Our forums are because we can only pay for such an upgraded amount of Slack history storage.
So we put all of our old questions in the forum, so they are a resource that you can
kind of search through.
And if you don't search through it, that's where I search when I answer questions.
And then we also do have the Influx community as well.
It's basically the one on GitHub where you can find projects that people have worked
on, including ourselves.
Our book, which basically just goes into things like why you want to use it, the documentation,
which I've mentioned multiple times because it really goes in depth on how to get this
project set up and going.
That's where you see things.
They have some of our new stuff as well as just, in general, we like to highlight some
of the projects that people are working on.
And finally, just our university where you can learn more.
It's completely free and go at your own pace.
So now that we've gotten through everything, if anybody has any questions...
Yes?
Yeah, so I'll go ahead... Oh, that's not what I wanted.
No.
It's just taking me back to that stupid drive video.
There we go.
So yeah, so this is that Influx community plant buddy project.
So the master branch.
And then we also have, so for example, down here we talk about the control boards.
So we've got the Arduino or the Boron.
And then we have an entire sensor list.
So for example, if I click on this one, it harasses me for cookies.
It goes into the temperature sensor.
So you can go ahead and learn about all the different sensors that we use for this project.
You can also obviously search them up on the internet and buy them if you desire.
And you can use many different types of sensors, but these just happen to be the four that
we just wanted to end up using.
And like I said before, in this project, we have, yes, the master branch, and then we
also have things like EDR, which is edge data replication, Kafka, and then a few others.
I normally end up in the master branch.
It's kind of like the main versioning of the project.
And yeah, and then in the future, the SQL one that I was telling you about, that's going
to be EDR IOX.
It's still currently being worked on as I speak, actually.
So that one is not to be touched yet, until it's all done.
Yes?
Yeah.
So the question was, how is InfluxDB different than OpenTSB?
Sorry, TSTB, there we go.
So from what I understand, TSTB is also an open source time series database, just like
we are.
I think the biggest difference is going to be how much functionality it comes out of
the box with.
I would obviously have to go to their actual code and check it out a little bit further.
But normally the big thing that's our differentiator is the fact that we can, we actually have
our own visualizations.
We have our own ability with Flux to do things like alerting, like that moisture alerting
that I was talking about before.
And then with the new SQL integration, that will also be very nice for people who want
to query in a language.
Most people are already familiar with querying in when it comes to working with databases.
But to be honest, a lot of time series DBs can be pretty comparable when it actually
comes to the storage.
So it's going to depend somewhat on your project and which one you want to, I suppose, work
with.
A lot of people normally like to, I normally do get told that we have pretty good documentation
and a good community where we're very easy to work with and work through problems.
And that's not always the case with every open source community.
If anybody else has any other questions.
If not, that's totally fine too, because that all gives you guys time to run off to the
next talks or maybe go grab some lunch from the food trucks.
Thank you.