Now, let's have a look at the first version of the original sketch to the original sketch version for
the first iteration of the project.
The sketch is based on the E.S.P and Take Client Library, which you can find here on GitHub at this
location.
So it's a fairly simple and quiddity library.
But what I really like about it is that it's integrated.
It allows you to handle EMCDDA team client requests, but it also handles especially to Wi-Fi, which
means that we don't need to have a separate library for the wi fi bit.
And there's very good documentation here.
And examples, basically, you can get started with the library and subscribe and publish messages to
the Breuker very, very quick with a very small amount of coding.
Can have a look at the examples here as well, especially the what I used.
I started with this example here and then implemented the various features based on this.
As long as you know how to create a client and then subscribe to a topic or published topic, then you
can pretty much do anything you want or need to do with the broker.
And within a sketch, as you can see here.
Start from line 17 and 18, you can interact with more than one topics.
As the project becomes larger, you'll see that I'll be adding more topics here.
So let's take things from beginning.
First, I am creating the entity client here, and instead of having all the various credentials in
the main application file, I've got them in a separate file called E.S.P through to Sigrid's, which
looks like this.
So this we can define your wi fi as a side password and username and password for the brokedown.
Remember that these are the credentials that I created in the previous section when we were setting
up the mosquito illiquidity broker.
And you also need to get your broker's IP address for your Raspberry Pi so you can use this information
here.
And there is it's called Secrets The Page File.
After that, I'm setting up the various pins, as we saw in the previous lecture in the schematic show.
You really quickly here, we've got the thirty two for the transistor and then for the moisture sensor,
in our case, for the potential metal that is connected to GPO 35.
So I used this information right here.
Then I have set up the the two topics.
This is a topic that I am publishing, the soil humidity.
And this topic here, the control topic is where my schedule is, where the data is subscribed to receive
control, ratifications of values from the node red flow that I'll show you in the next lecture.
Now, this line here, this value called soil humidity error range, I've set it here so that the SB
32 will publish to this topic when the change in the detected soil humidity or the value from the consumer
is large enough, because I don't want it to be posting constantly for single digit changes.
So I wanted to have a range.
And when the output from the sensor becomes larger or smaller by 10 units, then we'll send an update
to Node read.
I did this just to really conserve a bit of bandwidth and not to flood my note rate of flow with updates.
All right, so these are a couple of additional variables here, the current soil humidity and then
the last so committed so that the sketch remembers the last value that was sent to it by the note read
Broken because they expected it to client cannot ask the entity broker for an update.
The broker sends updates to the HP 32.
So if the E.S.P 32 needs for some reason to remember the last value sent to it from the broker, they
need to keep it locally.
So that's what this variable is about.
In the setup function, I'm setting up the analog to digital converter by attaching the serial humidity
pin, setting the analog read resolution to 10 bits.
So that gives us a range of zero to one thousand and twenty three for the readings from the soil humidity
pin.
And that is going to be an input.
I'm setting the pump pen to be an output, these two lines to enable debugging messages and the Clippy
Web up data, and that allows us to see debugging messages and information about what is happening with
the requests in the serial monitor.
And you can actually, once you do your testimony, you happy that everything works.
You can just comment that out and not have to see any messages coming through this serial monitor.
I just keep them in until we do a bit of testing later on in this section.
The next function called On Connection Established, is a function that is called by the library when
the entity broker sends an update to a topic that we ask, subscribe to the expected it to be subscribed
so we can see here that we say client subscribed to control topic, which is this topic right here.
And when the new data arrives to this topic from the note read flow, then the broker will forward it
to any subscribed clients, which the ISP thirty two is going to be the subscriber client.
And then when that happens, the library will call the pump control function, which if implemented
further down and pass on the pump state that the note read flow has calculated for the controller.
And let's jump into pump control since we have bumped into it.
Here it is.
So this pump control, it receives the pump state, which is a string.
Pretty much everything in no direct messaging is really about strings, or at least that's how I have
implemented the flow.
It's going to send a string across.
It's going to be either a zero or a one.
And then depending on what it is, if it's a zero, it's going to turn off the pump by calling digital
right on pump and taking that down to low.
And if the pump state is one, then we're turning on the pump by calling digital.
Right.
And sending a high to pump in.
Now, you'll notice here that I am using an array notation, and that's because I've got a string here
sent from my note read a string is an array of characters.
You want to know what the first cell in this array of characters contains.
And that is why I am using the array notation and just passing index zero, because I'm only interested
in the contents of the first cell of this array.
There's other ways to implement this, but I thought I'd go with the string here just to keep things
really simple.
So let's have a look at what is happening inside the loop.
The first thing that is happening inside the loop is to call the loop function on the client object,
and that basically allows us to check for messages from the.
And could it be broken?
Apart from that, I take a reading from the soil to pen to see what is happening with your community
in our prototyping phase that we are at the moment.
I'll be taking readings from the potential metal and then printing out the various values stored in
the variables.
Now this is where publishing data to the end quiddity so your humidity topic takes place.
If the difference between the current humidity and the previous soil humidity is larger than the range
that I've specified earlier and larger than 10, then go ahead and send an update to the market it.
So if this is true, then we use declined to publish function to send an update to the solar humidity
topic, which is.
This topic right here.
And this is the value that we are publishing to this to this topic.
You can see that I'm setting a string value of whatever I read from the soil humidity pin and then updating
the lost soil humidity to be the current soil humidity.
And actually to make this a little bit better, what I'll do is I will replace this with the value of
the current soil humidity and fire, a little thing that makes it better.
All right.
So we've got a delay here and then the whole thing repeats again with calling the client loop.
So that is about it.
With the sketch.
I'm going to compile it and upload it to my sensor.
OK, and had a look at the serial monitor.
All right, so it seems like it's working, there's nothing at the other end to interact with.
So let's continue with the next lecture where we'll set up no direct.