In the sketch, where we are implementing our automate, I have created a macrodefinition, in which I gave names to all
the states. From the controller’s perspective, these are just digits. However, in order to make it easier for us to write the program, I have named every digit in its own way: the “Standby” state, the
“Watering” state, the “No water” state and the “Send page” state, where we transmit the
information from our web page. I have then created a global variable called STATE, which will store the current state of the system. For starters, I have placed STATE_STANDBY in it, aka 0 – the “Standby” state, which will be the system’s initial state before
it begins operating. I have also created a global variable, which will store information on whether
or not there is water left. That’ll be the true value if there is water, and false if there’s none. I’m not touching upon setup yet, since it doesn’t contain anything which has to do with the operation of the
automaton. Let’s see at once what happens in the main loop. The main loop consists of verifying the current state and the transition from one state to another one. For this purpose, I am using this new control structure called switch. Let’s see how it works. You can communicate an expression to it, which in our case will be a
variable, and examine its various options, which will depend on the value
of this variable. Every case is examined once we’ve looked at what comes after the
“case” key word. Thus, if the STATE variable equals this expression, and in our situation, this is STATE_STANDBY, (meaning that there is 0 value there), we will be performing all the actions listed here. We will look closer at
these actions later. The key word “break” is mentioned at the end, which closes the switch structure. You shouldn’t forget about it, as you might experience some situations when some extra actions happen if you don’t exit the switch structure. So what will be happening in the “Standby” state? For starters, we shall check if there is any water in the container. We don’t have the checkWater function yet, but we will need to define it, for we will need to check whether there is water or not. If there is none, we won’t be able to enter the “Watering” state, as it won’t be available to us. Then, if we receive a request from the network and we have water, the system is going to enter the “Watering” state. Therefore, we will need one more function called webRequest, which will display different options depending on the type of the received request. We were expecting the request of the 1 type, which is a request to start
watering automatically. In the “else if” branch, we can check for requests of other types, i.e. the request to display the data from the web page. If we get the request, we can enter the “Send page” state or
STATE_SENDPAGE regardless of the fact whether there is water or not. Then apart from checking the requests from the network, we are going to
check the state of all sensors. if the checkClimate function displays the true value, i.e. all the conditions for watering are met, and we have water in the container, the system will enter the “Watering”
state. This is our other possibility to enter the “Watering” state. However, if the gotWater variable stores the false value, aka there is no water left, the system will enter the “No water”
state. Where does the gotWater variable take its value from? Let’s imagine that our checkWater function is working with the global variable that we created, and the value will be assigned to all these expressions at the beginning of this “case”. Let’s look further. The case with the “Watering” state is described next. We are simply going to call a function for watering, which we are going to describe later. Its details are not important for us now. After the system has finished watering, the “Finish watering" event takes place, and the system reenters the “Standby”
state. Break again means here that we are exiting the switch structure. Let’s move on. Let’s consider the case when the system is in the “No water” state. In this case, we will need to set off the alarm. This will be described in the “alarm” function. We will also need to check just in case if any user would like to check the weather conditions at this exact moment. Thus, we need to check again if we have a corresponding request. We are going to code digits 1 and 2, which signify different types of replies received from webRequest, in a macrodefinition. Like these ones. These are the webRequest function replies, which, like I said, are equivalent
to digits 1 and 2. You would agree that this looks more comprehensible. If the Internet request asks for weather conditions, the system enters the “Send page” state. If we get no request, we shall check for water again, while the system is in the “No water” state. If water has appeared, i.e. the checkWater function gives us
the true value, the system enters the “Standby” state. The last state called case STATE_SENDPAGE, which is the state of data transmission, will activate the data transmission
function. After this, the system will again enter the “Standby” state. And again we have break at the end. Besides all this, I have written and added a comment to one more key word – default. Since we’ve already got acquainted with the switch structure, we can’t leave this key word behind. It can be used to describe actions which need to be taken if the system has entered none of the intended states. In other words, if all “case” functions did not work. We should not experience this, because we can switch easily between the states and we won’t find ourselves
somewhere in between them. That’s why I’ve added a comment to this “default” function. If this were not the case, we could describe the default behavior of the
system, let’s put it this way. We are now going to extend this code by adding all the functions that we mentioned in the automate sketch. Moreover, it’s easier for us to understand which one should be
returning some values, and which values should be returned in order for the system to function
correctly. Let’s also look at our main diagram, to which I suggest we add a display. This means that we are going to connect one more device, a display, which will be outputting the current state of the watering system. It may come in useful at the debugging stage, since we will be able to see what values the device is processing and in which state it currently is.
