1

SMART PLANT MONITORING

SYSTEM
A Project Report Submitted in Partial Fulfilment of
the Requirements for the Degree of

Bachelor of Technology
In
Computer Science and Engineering
Under the Supervision of
M .r Amitas
Gangwar (Assistant
Professor)
By

Nikhil Goswami (1716410163)

Nitin Kumar (1716410164)
Kashyap
Shikhar (1716410222)
Srivastava (1716410226)
Shivam
Tiwari

Pranveer Singh Institute of Technology, Kanpur

Dr. A.P.J. Abdul Kalam Technical University, Lucknow
(Formerly Uttar Pradesh Technical University)
June, 2021
 i

DECLARATION

I hereby declare that this submission is my own work and that, to the best of my
knowledge and belief. It contains no matter previously published or written by any
other person nor material which to substantial extent has been accepted to the
award of any degree or diploma of the university or other institute of higher
learning except where due acknowledge has been made in the text.

Signature:
Name : Nikhil Goswami
Roll No 1716410163

Signature:
Name : Nitin Kumar Kashayap
Roll No 1716410164

Signature:
Name : Shikhar Srivastava
Roll No 1716410222

Signature:
Name : Shivam Tiwari
Roll No 1716410226
 ii

CERTIFICATE

This is to certify that the project titled “Smart Plant Monitoring System”, which

is submitted by

 Nikhil Goswami (1716410163)

 Nitin Kumar Kashyap (1716410164)

 Shikhar Srivastava (1716410222)

 Shivam Tiwari (1716410226)

in partial fulfilment of the requirement for the award of the degree of Bachelor of

Technology in Computer Science and Engineering to PSIT, Kanpur, affiliated to

Dr. A.P.J. Abdul Kalam Technical University, Lucknow during the academic year

2019-21, is the record of candidate’s own work carried out by him under my

supervision. The matter embodied in this report is original and has not been

submitted for the award of any other degree.

Dr. Vishal Nagar Mr. Amitas Gangwar

(Head of Dept., CSE) (Assistant Professor, Dept. of CSE)

 iii

ACKNOWLEDGEMENT

It gives us a great sense of pleasure to present the report of B.Tech. Project “Smart
Plant Monitoring System” undertaken during B.Tech. Final Year. We owe special debt of
gratitude to our project guide Mr. Amitas Gangwar (Assistant Professor, CSE), PSIT,
Kanpur for his constant support and guide throughout course of our work. His
sincerity, thoroughness and perseverance have been a constant source of inspiration for
us. It is only his cognizant efforts that our endeavors have seen light of the day.
We also do not like to miss the opportunity to acknowledge the contribution of all faculty
members of the department for their kind assistance and cooperation during the
development of our project. Last but not the least, we acknowledge our friends for their
contribution in the completion of the project.

Signature:
Name : Nikhil Goswami
Roll No 1716410163

Signature:
Name : Nitin Kumar Kashayap
Roll No 1716410164

Signature:
Name : Shikhar Srivastava
Roll No 1716410222

Signature:
Name : Shivam Tiwari
Roll No 1716410226
 iv

ABSTRACT

In the IOT based smart plant monitoring system we can monitor and control using

IOT. It is very difficult to control scattered without a remote environment

monitoring system. In recent years, there appeared a canopy remote monitoring

system based on Ethernet. In this project we use different modules such as IOT,

Arduino as controller, Temperature sensor, Moisture sensor, Humidity sensor.

This project uses sensors such as humidity sensor is also given to know about the

atmospheric humidity of that place. By having knowledge of all these one can take

action accordingly. Moisture sensor sense the soil is dry or wet. If soil is dry

automatically water pump will get ON. And the sensor values are given to ADC to

get processed by Arduino controller. The temperature sensor DHT11 senses the

temperature and converts it into an electrical (analog) signal, which is applied to

the micro controller through ADC. The analog signal is converted into digital

format by the analog-to-digital converter (ADC). In this project we are using

dry/wet sensor, humidity sensor and Temperature sensor. In an industry during

certain hazards is will be very difficult to monitor the parameter through wires

and analog devices such as transducers. To overcome this problem, we use

wireless device to monitor the parameters so that we can take certain steps even

in worst case. Few years back the use of wireless device was very less, but due the

rapid development is technology now-a-days we use maximum of our data

transfer through wireless like Wi-Fi, Bluetooth, WI-Max, etc. This project is

designed as a plant monitoring system based on IOT. The soil moisture value,

temperature and humidity values are updated in the internet through IOT module

interfaced to the controller.

 v

TABLE OF CONTENTS

CHAPTER TITLE PAGE NO.

NO.
Title Page i
Declaration ii
Certificate iii
Acknowledgement iv
Abstract v
Table of contents vi
List of Figures vii

1. INTRODUCTION 1
1.1 Problem Statement 2
1.2 Purpose 2
1.3 Existing System 2
1.4 Proposed System 3
3
1.5 Architecture of Proposed System
4
1.6 Working of the proposed System
4
1.7 Prototype of Smart Plant Monitoring System

2. FEASIBILITY STUDY 5
2.1 Technical Feasibility 5
2.2 Operational Feasibility 5
2.3 Economic Feasibility 6

3. REQUIREMENT ELICITATION 7
3.1 Requirement Elicitation 7
3.2 Requirement Analysis 7
3.3 Requirement Gathering 8
 vi

3.4 Analysis Requirement 8

3.5 Functional Requirement 8
3.6 Non-functional Requirement 9
3.7 Recording Requirements 9

4. DESIGNING 10
4.1 Components Used 10
4.1.1 Arduino UNO 10
4.1.2 Temperature and Humidity Sensor 10
4.1.3 Soil Moisture Sensor 11
4.1.4 Light Sensor 11
4.1.5 Voltage Regulator 11
4.1.6 ESP-12F Wi-Fi module 12
4.1.3.1 Relay 12
4.1.3.2 DFD Level-1 13
4.1.4 Use Case Diagram 13
4.1.5 Activity Diagram 15

5. CODING AND IMPLEMENTATION 16

5.1 Approach and Algorithms 16
5.2 Implementation of Algorithm 18
5.2.1 Implementation of Multi-Level Perceptron(MLP) 18
5.2.2 Implementation of Naive Bayes Algorithm 18
5.2.3 Implementation of Support Vector Machine(SVM) 24
5.2.4 Implementation of K-Nearest Neighbor(KNN) 25
5.2.5 Implementation of Decision Tree 28
5.2.6 Implementation of Logistic Regression 30
5.2.7 Implementation of Ensemble Learning 32
5.3 Snapshot of Dataset 35
 v
5.4 Snapshots of Frontend 36

6. TESTING 37
6.1 Unit Testing 37
6.1.1 Testing Objectives 38
6.1.2 Features to Be Tested 38
6.2 Integration Testing 39
6.2.1 Big-Bang Testing 39
6.2.2 Bottom-Up Testing 39
6.2.3 Top-Down Testing 40
6.3 System Testing 40
6.4 Functional Testing 40
6.4.1 Black Box Testing 41
6.4.2 White Box Testing 42
6.4.2.1 Statement Testing 42
6.4.2.2 Branch Testing 43
6.5 Integration Testing 43
6.6 Acceptance Testing 44

7. FUTURE SCOPE 45

8. CONCLUSION 46

9. REFERENCES 47
 viii

LIST OF FIGURES

1. Architecture of Smart Plant monitoring System...........................................4

2. Requirement Elicitation................................................................................8
3. Flow Chart Diagram...................................................................................12
4. DFD (Level 0)............................................................................................13
5. DFD (Level 1)............................................................................................13
6. Use Case Diagram......................................................................................14
7. Activity Diagram.........................................................................................15
8. Dataset of 1020 nodes.................................................................................35
9. Frontend......................................................................................................36
 1

CHAPTER 1
INTRODUCTION

The internet of things (IoT) is the network of physical objects—devices, vehicles,

buildings and other items embedded with electronics, software, sensors, and
network connectivity that enables these objects to collect and exchange data. The
IoT allows objects to be sensed and controlled remotely across existing network
infrastructure.

Agriculture is the backbone of our country and most of the people depend on
agriculture. The water resource is not used in an effective manner, so the water is
wasted. In order to overcome this irrigation process can be automated. Internet of
Things (IoT) plays an important role in most of the fields. The agriculture is the
area where a lot of improvement is needed because that is one of the essential
needs and a large sector of people is involved in that. The use of Internet of things
in this field will be helpful to reduce the wastage of water. So that the temperature
as well as humidity and light are measured by means of sensors and depend up on
the outcome further processing can be performed. We propose a system that will
capture all the details about the soil and the temperature by means of different
sensors. The sensed information will be sent to the processor and depends up on
the outcome the alert message will be passed and the appropriate amount of water
will be released to the crop.

The IoT devices can also be used in home for monitoring the garden real time.
The Raspberry and Arduino plays an important role in processing the information
that is received from various sensors. The cost of these devices will be affordable.
Much research focus is on finding the effect of these devices in the environment,
if it causes any side effects to the humans. The Raspberry-pi is used wherever a
large amount of processing is required and Arduino in terms of interconnecting
certain hardware devices and performs a little amount of processing. The
installation of the sensors for finding the humidity level is one major factor to
avoid the wastage of water. The next process is to identify the temperature and
whether there is enough amount of light energy. So, in this situation the solution
can be identified by the farmers itself if they are equipped with a system that can
provide the details about the condition of the plant. These set of processes will be
helpful in the growth of the crop.
1.1 Problem Statement:
In the case of traditional irrigation system water saving is not considered. Since,
the water is irrigated directly in the land, plants under go high stress from
variation in soil moisture, therefore plant appearance is reduced. The absence of
automatic controlling of the system result in improper water control system. The
major reason for these limitations is the growth of population which is increasing
at a faster rate. At present there is emerging global water crisis where managing
scarcity of water has become a serious job. This growth can be seen in countries
which have shortage of water resources and are economically poor. So this is the
serious problem in Smart Irrigation System. So we want to design a Smart
Irrigation System which is based on IOT using Arduino microcontroller that
operate automatically by sensing the moisture content of the soil and turn
ON/OFF the pump using relay without the intervention of farmer and hence save
water.

1.2 Purpose:
Smart Plant Monitoring System using IOT Technology: Internet of Things
technology is suitable for the smart plant monitoring system. This is also suitable
to check the soil conditions as well, which may help to start a better growth of
a plant. It may support to control water usage and wastage of water.

1.3 Existing System:

Farming in India is done using the mundane ways. The fact that most of our
farmers lack proper knowledge makes it even more erratic. A large portion of
farming and agricultural activities are based on the predictions, which at times
fail. Farmers have to bear huge losses and at times they end up committing
suicide. Since we know the benefits of proper soil moisture and its quality, air
quality and irrigation, in the growth of crops, such parameters cannot be ignored.
 3

1.4 Proposed System:

The smart plant monitoring system with IOT is practically and financially
sufficient for planning water resources for plantation (group of a plant). Adopting
the automatic water system framework, we can demonstrate that the utilization of
water can be decreased for various plantations (group of plants) usages. The
system framework has an appropriate moisture sensor, humidity and temperature
sensor set in the root zone of the plants. The data will gather from the sensors and
send to the web server (cloud).
The background of chapter highlights the study of IOT in the field of agriculture.
This shows how we can implement the IOT technology to make our planting
smart and reliable with the real time updated data. This chapter also helps the
beginners to implement the IOT technology and learn the basics of this
technology.

1.5 Architecture of the Proposed System:

1.6 Working of the proposed system:
1) When power supply is ON, the input module of three sensors (DHT11,
moisture sensor) start to activate.

2) When sensors get ON it will read the data from soil and from surrounding.

3) According to the values that are detected by sensors motor will turn ON/OFF.

4) If moisture value is below threshold value, then the relay will be activated and
the motor will be turn ON and adequate water will be supplied.

5) If moisture level is high, then it will stop the motor and water supply will also
stop.
6) All the values that are collected from sensor is send via ESP8266 Wi-Fi module
to the cloud server and it is stored in online database.

7) Cloud server will create the pie-chart for the data received by WI-FI module.
8) And, then whole information will show on the Webpage.

1.7 Prototype of the Smart Plant Monitoring System:

 5

Chapter 2
FEASIBILITY STUDY

A feasibility study is a high-level capsule version of the entire Smart plant

monitoring system. The study begins by classifying the problem definition.
Feasibility is to determine if it’s worth doing. Once an acceptance problem
definition has been generated, the analyst develops a logical model of the system.
A search for alternatives is analyzed carefully. There are 3 parts in feasibility
study.

2.1 Technical Feasibility

Evaluating the technical feasibility is the trickiest part of a feasibility study. This is
because, now not too many detailed design of the system, making it difficult to
access issues like performance, costs on (because the kind of technology to be
deployed) etc. Several issues should be considered while doing a technical
analysis. Understand the different technologies involved in the proposed system
before commencing the project we must be very clear about what are the
technologies that are to be required for the development of the new system.

2.2 Operational Feasibility

Proposed project is beneficial only if it can be turned into information systems that
will meet the user’s requirements. Simply stated, this test of feasibility asks if the
system will work when it is developed and installed. Are there major barriers to
Implementation? Here are questions that will help test the operational feasibility
of a project:
a. Is there sufficient support for the project from management from users?
If the proposed system is not highly accurate, there may be resistance.
b. Is a new business method acceptable to the user? If the new method is
actually helping the user, it is welcomed. Otherwise, a problem is there.
c. Has the user been involved in the planning and development of the
project?
d. Early involvement reduces the chances of resistance to the system and in
general and increases the likelihood of successful project. A huge and diverse
dataset surely supports.
e. Since the proposed system was to help take an important decision, our
findings express it to be operationally feasible.

2.3 Economic Feasibility

Economic feasibility attempts to weigh the costs of developing and implementing
a new system, against the benefits that would accrue from having a new system in
place. This feasibility study gives the top management the economic justification
for a new system. A simple economic analysis which gives the actual comparison
of costs and benefits are much more meaningful in this case. There could be
various types of intangible benefits on account of diverse data driven
computation. These could include increased precision leading to customer
satisfaction, improvement in decision making, timeliness of information,
expediting activities, better classification and record keeping, better employee
morale.
 7

CHAPTER 3
REQUIREMENT ELICITATION

3.1 Requirements Elicitation

Requirements elicitation is the practice of collecting the requirements of a system
from users, customers and other stakeholders. The practice is also sometimes
referred to as "requirement gathering".
Requirements elicitation is non-trivial because you can never be sure you get all
requirements from the user and customer by just asking them what the system
should do OR NOT do (for Safety and Reliability). Requirements elicitation
practices include interviews, questionnaires, user observation, workshops and role
playing.
Before requirements can be analyzed, modelled, or specified they must be
gathered through an elicitation process. Requirements elicitation is a part of the
requirements engineering process, usually followed by analysis and specification
of the requirements. Commonly used elicitation processes are the stakeholder
meetings or interviews. For example, an important first meeting could be between
software engineers and customers where they discuss their perspective of the
requirements.

3.2 Requirement analysis

Requirements analysis encompasses those tasks that go into determining the needs
or conditions to meet for a new or altered product or project, taking account of the
possible conflicting of the various analyzing, documenting, validating and
managing software or system requirements.
Requirements analysis is critical to the success or failure of a system or
software project. The requirements should be documented, actionable, measurable,
testable, traceable, related to identified business needs or opportunities, and
defined to a level of detail sufficient for system design.
3.3 Requirement Gathering
Requirements gathering is an essential part of any project and project
management. Understanding fully what a project will deliver is critical to its
success. Requirements gathering sounds like common sense, but surprisingly, it's
an area that is given far too little attention.

3.4 Analysis Requirement

Requirements analysis, also called requirements engineering, is the process of
determining user expectations for a new or modified product. These features,
called requirements, must be quantifiable, relevant and detailed. In software
engineering, such requirements are often called functional specifications.

FIGURE 3.1: REQUIREMENT ELICITATION

Requirement Elicitation is basically divided into 2 categories:

3.5 Functional requirements:

Functional requirement defines a function of product or its component. A function
is described as a set of inputs, the behavior, and outputs.
Functional requirements may be calculations, technical details, data manipulation
and processing and other specific functionality that define what a system is
supposed to accomplish. Behavioral requirements describing all the cases where
the system uses the functional requirements are captured in. Functional
requirements are supported by Software Quality Assurance
 9

(also known as quality requirements), which impose constraints on the design or

implementation (such as performance requirements, security, or reliability).
Generally, functional requirements are expressed in the form "system must do
<requirement>", while non-functional requirements are "system shall be
<requirement>". The plan for implementing functional requirements is detailed in
the system design. The plan for implementing non-functional requirements is
detailed in the system architecture.

3.6 Non-functional requirements

In systems engineering and requirements engineering, a non-functional
requirement is a requirement that specifies criteria that can be used to judge the
operation of a system, rather than specific behaviors. They are contrasted with
functional requirements that define specific behavior or functions. The plan for
implementing functional requirements is detailed in the plan for implementing
non- functional requirements.

3.7 Recording Requirements:

Requirement may be documented in various form, usually including a summary
list and may include a natural language document, use case, user stories or process
specifications.
 10

CHAPTER 4
DESIGNING

In this chapter, the objectives are to learn, develop and furnish the project. To see,
step-wise how things are implemented and put together to bring the project live.
Our edible food items and everything is produced through a system which is
called irrigation system. The main objective is to take the irrigation, a next step
further. The major parameters to be measured, to make it smart is to monitor the
temperature and humidity (presence of rain) and then control the watering
system through the submersible pump. And, all these sensors and pump are
connected through the Arduino UNO. In simple words, on one side, the Arduino
UNO monitors the Temperature and Humidity though the respective sensors. And,
on the other hand Arduino checks the condition and judge if the watering is
necessary or not. The following steps guides through the procedure undertaken to
make Irrigation Smart:
Step1: In this above proposal two different types of sensors (i.e. Temperature&
moisture) are used to detect the required scarcity of water in the soil for proper
undergoing of the process, that is, for proper irrigation.

Step2: Required action by the help of controller (i.e. Arduino UNO) is to be taken
for the deficit of the physical parameters of the soil for a healthy process.

Step3: An autonomous system is implemented here for taking the action by

supplying adequate amount of raw materials (i.e. water) through the pump which
is indeed controlled by the Arduino UNO itself.

Step4: For the exact amount of water in the soil to be measured is to read the
analog output of the Moisture Sensor. According to the measured values the motor
will be switched on or off. Arduino will control all these processes.

Components used:
1. Arduino UNO:

Arduino UNO R3 Front Arduino UNO R3 Back

 11

Overview:
The Arduino Uno is a microcontroller board based on the ATmega328
(datasheet). It has 14 digital input/output pins (of which 6 can be used as PWM
outputs), 6 analog inputs, a 16 MHz ceramic resonator, a USB connection, a
power jack, an ICSP header, and a reset button. It contains everything needed to
support the microcontroller; simply connect it to a computer with a USB cable or
power it with a AC-to-DC adapter or battery to get started.
The Uno differs from all preceding boards in that it does not use the FTDI USB-
to-serial driver chip. Instead, it features the Atmega16U2 (Atmega8U2 up to
version R2) programmed as a USB-to-serial converter. Revision 2 of the Uno
board has a resistor pulling the 8U2 HWB line to ground, making it easier to put
into DFU mode. Revision 3 of the board has the following new features:
 pinout: added SDA and SCL pins that are near to the AREF pin and two other new pins
placed near to the RESET pin, the IOREF that allow the shields to adapt to the voltage
provided from the board. In future, shields will be compatible both with the board that
use the AVR, which operate with 5V and with the Arduino Due that operate with 3.3V.
The second one is a not connected pin, that is reserved for future purposes.
 Stronger RESET circuit.
 At mega 16U2 replace the 8U2.

"Uno" means one in Italian and is named to mark the upcoming release of
Arduino 1.0. The Uno and version 1.0 will be the reference versions of Arduino,
moving forward. The Uno is the latest in a series of USB Arduino boards, and the
reference model for the Arduino platform; for a comparison with previous
versions, see the index of Arduino boards.

2. Temperature and Humidity Sensor:

DHT temperature & humidity

sensors.
 12
DHT11 vs DHT22
We have two versions of the DHT sensor, they look a bit similar and have the
same pinout, but have different characteristics. Here are the specifications:
DHT11
 Ultra low cost
 to 5V power and I/O
 2.5mA max current use during conversion (while requesting data)
 Good for 20-80% humidity readings with 5% accuracy
 Good for 0-50°C temperature readings ±2°C accuracy
 No more than 1 Hz sampling rate (once every second)
 Body size 15.5mm x 12mm x 5.5mm
 pins with 0.1" spacing
DHT22
 Low cost
 to 5V power and I/O
 2.5mA max current use during conversion (while requesting data)
 Good for 0-100% humidity readings with 2-5% accuracy
 Good for -40 to 80°C temperature readings ±0.5°C accuracy
 No more than 0.5 Hz sampling rate (once every 2 seconds)
 Body size 15.1mm x 25mm x 7.7mm
 pins with 0.1" spacing
As you can see, the DHT22 is a little more accurate and good over a slightly
larger range. Both use a single digital pin and are 'sluggish' in that you can't query
them more than once every second or two.

3. Soil Moisture Sensor:

A Soil Moisture Sensor is one kind of low-cost electronic sensor that is used to
detect the moisture of the soil. This sensor can measure the volumetric content of
water inside the soil. This sensor is consisting of mainly two parts, one is Sensing
Probes and another one is the Sensor Module. The probes allow the current to
pass through the soil and then it gets the resistance value according to moisture
value in soil. The Sensor Module reads data from the sensor probes and processes
the data and converts it into a digital/analog output. So, the Soil Moisture Sensor
can provide both types of output Digital output (DO) and Analog output(AO).
 13

Soil Moisture Sensor Specifications

Parameter Value
Operating Voltage 3.3V – 5V
Operating Current 15 mA
Comparator chip LM393
Sensitivity Adjustable via Trim pot
Analog output voltage (AO) and Digital switching
Output type voltage (DO)
LED lights indicators Power (red/green) and Output (red/green)
Sensing Probes
Nickel plate on one side.
Module PCB Size 3.2cm x 1.4cm

4. Light Sensor:
A light sensor is a passive sensor that is used to indicate the intensity of the light
by examining the radiant energy that exists in a certain range of frequencies. In
the spectrum of electromagnetic waves, the ranges of frequencies that are used to
detect using a sensor are between infrared to visible and up to ultraviolet. Light
sensors convert the light energy in the form of photons to electrical energy in the
form of electrons. Hence, they are also called as Photo Sensors or Photo Detectors
or Photo Electric Devices.
 14
5. Voltage Regulator:

The MC78XX/LM78XX/MC78XXA series of three terminal positive regulators

are available in the TO-220/D-PAK package and with several fixed output
voltages, making them useful in a wide range of applications. Each type employs
internal current limiting, thermal shut down and safe operating area protection,
making it essentially indestructible. If adequate heat sinking is provided, they can
deliver over 1A output current. Although designed primarily as fixed voltage
regulators, these devices can be used with external components to obtain
adjustable voltages and currents.

Features
• Output Current up to 1A
• Output Voltages of 5, 6, 8, 9, 10, 12, 15, 18, 24V
• Thermal Overload Protection
• Short Circuit Protection
• Output Transistor Safe Operating Area Protection

6. ESP-12F Wi-Fi module:

The ESP-12F is a Wi-Fi module based on ESP8266, with built-in 32Mbit Flash, in
the small SMD22 package. There're also onboard PCB antenna and metal shield.
In short, it's a small form factor and fairly high cost effective Wi-Fi___33
modules.

With the pre-flashed AT firmware, you can control the module through UART AT
commands easily. The module integrates MCU inside, supports other
developments like Lau/Micro python/Arduino to achieve flexible and fast
prototyping, make it easy to integrate the module into IoT applications.
 15

Features

 802.11b/g/n Wi-Fi SOC

 Integrated Ten silica L106 ultra-low-power 32-bit
micro MCU, run at 80 MHz and 160 MHz frequency, supports RTOS
 Built-in 1-ch 10-bit high precision ADC
 Supports UART/GPIO/ADC/PWM/I2C
 SMD22 package
 Integrated Wi-Fi MAC/ BB/RF/PA/LNA
 Supports multi sleep modes, deep sleep current as low
as 20uA
 UART baud rate up to 4Mbps
 Embedded Lip protocol stack
 Supports STA/AP/STA+AP operation mode
 Supports Smart Confit (APP) / Air Kiss (WeChat),
one key networking
 Supports UART local firmware upgrade and/or
remote firmware upgrade (FOTA)
 AT commands for getting started fast
 Supports secondary development, integrated
Windows / Linux environment

7. Relay:
A relay is an electrical switch that uses an electromagnet to move the switch from
the off to on position instead of a person moving the switch. It takes a relatively
small amount of power to turn on a relay but the relay can control something that
draws much more power. Ex: A relay is used to control the air conditioner in your
home. The AC unit probably runs off of 220VAC at around 30A. That's 6600
Watts! The coil that controls the relay may only need a few watts to pull the
contacts together.
 16

8.Motor:

An electric motor converts electrical energy into mechanical motion. The reverse
task, that of converting mechanical motion into electrical energy, is accomplished
by a generator or dynamo. In many cases the two devices differ only in their
application and minor construction details, and some applications use a single
device to fill both roles. For example, traction motors used on locomotives often
perform both tasks if the locomotive is equipped with dynamic brakes.
 17

FLOWCHART OF SMART PLANT

MONITORING SYSTEM
 18

FLOW CHART FOR TEMPERATURE

 19

FLOW CHART FOR LIGHT SENSOR VALUE

 20

FLOW CHART FOR MOISTURE SENSOR

VALUE
 21

CHAPTER 5
CODING AND IMPLEMENTATION
 22

In Computer science an implementation is a realization of a technical specification

or algorithms as a program, software component or other computer system
through computer programming and deployment. Many implementations may
exist for a given specification or standard. For Example, Web browsers contain
implementations of World Wide Web Consortium-recommended specifications
and software development tools contain implementations of programming
languages.
A special case occurs in object-oriented programming, when a concrete class
implements an interface; in this case the concrete class is an implementation of the
interface and it includes methods which are implementations of those methods
specified by the interface. In the Information Technology Industry,
implementation refers to the post –sales process of guiding a client from purchase
to use off the software or hardware that was purchased. This includes
requirements analysis, scope analysis, customizations, systems integrations, user
policies, user training and delivery. These steps are obtained and overseen by a
project manager using project management methodologies. Software
Implementations involve several professionals that are relatively new to the
knowledge based economy such as business analysts, technical analysts, solution
architects, and project managers.

5.1 Arduino programming and connection:

Power
The Arduino Uno can be powered via the USB connection or with an external
power supply. The power source is selected automatically.
External (non-USB) power can come either from an AC-to-DC adapter (wall-
wart) or battery. The adapter can be connected by plugging a 2.1mm center-
positive plug into the board's power jack. Leads from a battery can be inserted in
the God and Vin pin headers of the POWER connector.
The board can operate on an external supply of 6 to 20 volts. If supplied with less
than 7V, however, the 5V pin may supply less than five volts and the board may
be unstable. If using more than 12V, the voltage regulator may overheat and
damage the board. The recommended range is 7 to 12 volts.
The power pins are as follows:
 VIN. The input voltage to the Arduino board when it's using an external power
source (as opposed to 5 volts from the USB connection or other regulated power
source). You can supply voltage through this pin, or, if supplying voltage via
the power jack, access it through this pin.
 23
 5V. This pin outputs a regulated 5V from the regulator on the board. The board
can be supplied with power either from the DC power jack (7 - 12V), the USB
connector (5V), or the VIN pin of the board (7-12V). Supplying voltage via the
5V or 3.3V pins bypasses the regulator, and can damage your board. We don't
advise it.
 3V3. A 3.3-volt supply generated by the on-board regulator. Maximum current
draw is 50 mA.
 GND. Ground pins.

Memory
The ATmega328 has 32 KB (with 0.5 KB used for the bootloader). It also has 2
KB of SRAM and 1 KB of EEPROM (which can be read and written with the
EEPROM library).
Input and Output
Each of the 14 digital pins on the Uno can be used as an input or output, using pin
Mode (), digital Write (), and digital Read () functions. They operate at 5 volts.
Each pin can provide or receive a maximum of 40 mA and has an internal pull-up
resistor (disconnected by default) of 20-50 ohms. In addition, some pins have
specialized functions:
 Serial: 0 (RX) and 1 (TX). Used to receive (RX) and transmit (TX) TTL serial
data. These pins are connected to the corresponding pins of the ATmega8U2
USB-to-TTL Serial chip.
 External Interrupts: 2 and 3. These pins can be configured to trigger an
interrupt on a low value, a rising or falling edge, or a change in value. See the
attach Interrupt () function for details.
 PWM: 3, 5, 6, 9, 10, and 11. Provide 8-bit PWM output with the analog Write
() function.
 SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). These pins support SPI
communication using the SPI library.
 LED: 13. There is a built-in LED connected to digital pin 13. When the pin is
HIGH value, the LED is on, when the pin is LOW, it's off.

 The Uno has 6 analog inputs, labeled A0 through A5, each of which provide 10
bits of resolution (i.e. 1024 different values). By default, they measure from
ground to 5 volts, though is it possible to change the upper end of their range
using the AREF pin and the analog Reference () function. Additionally, some
pins have specialized functionality:
 TWI: A4 or SDA pin and A5 or SCL pin. Support TWI communication using
the Wire library.

 There are a couple of other pins on the board:

 AREF. Reference voltage for the analog inputs. Used with analog Reference ().
 Reset. Bring this line LOW to reset the microcontroller. Typically used to add a
reset button to shields which block the one on the board.

 See also the mapping between Arduino pins and ATmega328 ports. The
mapping for the Atmega8, 168, and 328 is identical.
 Communication
 24
 The Arduino Uno has a number of facilities for communicating with a
computer, another Arduino, or other microcontrollers. The ATmega328
provides UART TTL (5V) serial communication, which is available on digital
pins 0 (RX) and 1 (TX). An ATmega16U2 on the board channels this serial
communication over USB and appears as a virtual com port to software on the
computer. The '16U2 firmware uses the standard USB COM drivers, and no
external driver is needed. However, on Windows, a .in file is required. The
Arduino software includes a serial monitor which allows simple textual data to
be sent to and from the Arduino board. The RX and TX LEDs on the board will
flash when data is being transmitted via the USB-to-serial chip and USB
connection to the computer (but not for serial communication on pins 0 and 1).
 A Software Serial library allows for serial communication on any of the Uno's
digital pins.
 The ATmega328 also supports I2C (TWI) and SPI communication. The
Arduino software includes a Wire library to simplify use of the I2C bus; see the
documentation for details. For SPI communication, use the SPI library.
 Programming
 The Arduino Uno can be programmed with the Arduino software (download).
Select "Arduino Uno from the Tools > Board menu (according to the
microcontroller on your board). For details, see the reference and tutorials.
 The ATmega328 on the Arduino Uno comes preboned with a bootloader that
allows you to upload new code to it without the use of an external hardware
programmer. It communicates using the original STK500 protocol (reference, C
header files).
 You can also bypass the bootloader and program the microcontroller through
the ICSP (In-Circuit Serial Programming) header; see these instructions for
details.
 The ATmega16U2 (or 8U2 in the rev1 and rev2 boards) firmware source code is
available. The ATmega16U2/8U2 is loaded with a DFU bootloader, which can
be activated by:
 On Rev1 boards: connecting the solder jumper on the back of the board (near
the map of Italy) and then resetting the 8U2.
 On Rev2 or later boards: there is a resistor that pulling the 8U2/16U2 HWB line
to ground, making it easier to put into DFU mode.

5.2 Temperature and Humidity connection:

Luckily it is trivial to connect to these sensors, they have fairly long 0.1"-pitch
pins so you can plug them into any
breadboard, per board or similar.
Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins
1. VCC - red wire Connect to 3.3 - 5V power. Sometime 3.3V power isn't
enough in which case try 5V power.
2. Data out - white or yellow wire
3. Not connected
4. Ground - black wire
Simply ignore pin 3, it’s not used. You will want to place a 10 Kohl resistor
between VCC and the data pin, to act as a
medium-strength pull up on the data line. The Arduino has built in pull-ups you
can turn on but they're very weak, about
 25
20-50K.
This diagram shows how we will connect for the testing sketch. Connect data to
pin 2, you can change it later to any

To test the sketch, we'll use an Arduino. You can use any microcontroller that can
do microsecond timing, but since it’s a
little tricky to code it up, we suggest verifying the wiring and sensor work with an
Arduino to start.
Begin by downloading the DHT library from our GitHub repository. To
download, click the DOWNLOADS button in the
top right corner. Rename the uncompressed folder DHT and make sure that it
contains the dht.cpp file and others.
Then drag the DHT folder into the Arduino sketch folder/libraries/ folder. You
may have to create that libraries subfolder
if it doesn’t exist. Restart the IDE. Now load up the Examples->DHT->DHTtester
sketch.
Code:
#include <SoftwareSerial.h>
#include <dht11.h>
dht11 DHT11; // create object of DHT11
#define dhtpin 9 // set the pin to connect to DHT11
const byte rxPin = 3;
const byte txPin = 2;
SoftwareSerial ESP8266(rxPin, txPin);
#define soilPin A0
#define ldrPin A1
#define rlyPin 10
#define rledPin 11
#define gledPin 12
#define bledPin 13
int i = 0, sv = 0, soilv = 0, lv = 0, ldrv = 0;

String A;
String B;
String C;
String D;
String E;
String F;
 26
String TA = "N";
String LA = "N";

This will make the data appear correctly for the correct sensor. Upload the sketch!

You should see the temperature and humidity. You can see changes by breathing
onto the sensor (like you would to
fog up a window) which should increase the humidity.
You can add as many DHT sensors as you line on individual pins, just add new
lines such as
DHT dht2 = DHT(pin, type);
below the declaration for the initial dht object, and you can reference the new dht2
whenever you like.

5.3 Void setup () function:

void setup() {
pinMode(soilPin, INPUT);
pinMode(ldrPin, INPUT);
pinMode(rlyPin, OUTPUT);
pinMode(rledPin, OUTPUT);
pinMode(gledPin, OUTPUT);
pinMode(bledPin, OUTPUT);
digitalWrite(rlyPin, LOW);
digitalWrite(rledPin, LOW);
digitalWrite(gledPin, LOW);
digitalWrite(bledPin, LOW);
Serial.begin(9600);
ESP8266.begin(9600);
}
5.4 Void loop function:
void loop() {
 27
DHT11.read(dhtpin);// initialize the reading
int humidity = DHT11.humidity;// get humidity
delay(100);

soilv = analogRead(soilPin);
delay(100);

sv = 1023 - soilv;

ldrv = analogRead(ldrPin);
delay(100);

lv = 1023 - ldrv;

Serial.print("Temperature:");
Serial.print(getTemp('C'));
Serial.println("C ");
// Serial.print(getTemp('F'));
// Serial.print("F ");
// Serial.print(getTemp('K'));
// Serial.print("K ");
Serial.print("Humidity:");
Serial.print (humidity);
Serial.println("%");
Serial.print("Soil Moisture: ");
Serial.print(sv);
Serial.println();
Serial.print("Light: ");
Serial.println(lv);

if ((getTemp('C')) > 37) {

TA = "A";
}
else {
TA = "N";
}

if (lv < 400) {

LA = "A";
}
else {
LA = "N";
}

if (sv > 0 and sv < 300) {

digitalWrite(rlyPin, HIGH);
digitalWrite(rledPin, HIGH);
digitalWrite(gledPin, LOW);
digitalWrite(bledPin, LOW);
}
 28

if (sv > 300 and sv < 700) {

digitalWrite(rlyPin, LOW);
digitalWrite(rledPin, HIGH);
digitalWrite(gledPin, HIGH);
digitalWrite(bledPin, LOW);
}

if (sv > 700 and sv < 1023) {

digitalWrite(rlyPin, LOW);
digitalWrite(rledPin, HIGH);
digitalWrite(gledPin, HIGH);
digitalWrite(bledPin, HIGH);
}
5.5 IoT update function:
iotupdate(String(getTemp('C')), String(humidity), String(lv), String(sv),
String(TA), String(LA));

// Serial.print("i=");
// Serial.println(i);
// if (i == 20) {
// i = 0;
// for (int n = 0; n < 5; n++) {
// Serial.println("UPDATING DATA");
// iotupdate(String(getTemp('C')), String(humidity), String(sv), String(lv),
String(TA), String(LA));
// delay(3000);
// }
// }
//
// i++;

void connectserver() {
// ESP8266.println("AT");
// delay(1000);
//lcd.clear();
// lcd.setCursor(0, 1);
// lcd.print("ConnectingServer");
Serial.println("connectingserver");
ESP8266.println("AT+CIPMUX=1");
delay(200);
ESP8266.println("AT+CIPSTART=4,\"TCP\",\"www.itechbuilders.com\",80");//
208.91.198.130 192.168.1.19
delay(200);
}

String iotupdate(String A, String B, String C, String D, String E, String F) {

Serial.println("iotupdate");
 29
connectserver();
// lcd.clear();
// lcd.setCursor(0, 1);
// lcd.print("Updating Data...");
String cmd = "GET
/index.php/iot_panel/iot_update/0/2/3/NA/NA/531_532_533_534/" + A + "_"
+ B + "_" + C + "_" + D + "/535_536/" + E + "_" + F + "/20PSITCS022
HTTP/1.1\r\n\Host: www.itechbuilders.com\r\n\r\n\r\n";
ESP8266.println("AT+CIPSEND=4," + String(cmd.length() + 2));
delay(100);
ESP8266.print(cmd);
delay(300);
// Serial.println(cmd);
return "done";
}

float getTemp(char type) {

float temp = (float)DHT11.temperature;//get temp
if (type == 'F')
{
return temp * 1.8 + 32;// convert to fahrenheit
} else if (type == 'K')
{
return temp + 274.15;// convert to Kelvin
} else {
return temp;
}

}
 30

CHAPTER 6
TESTING
Software Testing is an investigation conducted to provide stakeholders with
information about the quality of the product or service under test. Software
Testing can also provide an objective, independent view of the software to allow
the business to appreciate and understand the risks of software implementations.
Test techniques include the process of executing a program or application with the
intent of finding software bugs (errors or other defects), and verifying that the
software product is fit for use.

Software testing involves the execution of a software component or system

component to evaluate one or more properties of interest. In general, these
properties indicate the extent to which the component or system under test:
a. Meets the requirements that guided its design and development.
b. Responds correctly to all kinds of inputs.
c. Perform its functions within an acceptable time.
d. Is sufficiently usable,
e. Can be installed and run in its intended environments, and
f. Achieves the general result its stakeholders desire.
The purpose of testing is to discover errors. Testing is the process of trying to
discover every conceivable fault or weakness in a work product. It provides a way
to check the functionality of components, sub-assemblies, assemblies and/or a
finished product. It is the process of exercising software with the intent of
ensuring that the software system meets its requirements and user expectations
and does not fail in an unacceptable manner. There are various types of tests.
Each test type addresses a specific testing requirement.

6.1 Unit Testing

Unit testing involves the design of test cases that validate that the internal
program logic is functioning properly, and that program input produces valid
 31

outputs. All Decision branches and internal code flow should be validated. It is the
testing of individual software units of the application. It is done after the
completion of an individual unit before integration. This is a structural testing,
that relies on knowledge of its construction and is invasive. Unit tests perform
basic tests at component level and test a specific business process, application,
and/or system configuration. Unit tests ensure that each unique path of a business
process performs accurately to the documented specifications and contains clearly
defined inputs and expected results.
In Computer programming, unit testing is a software testing method by which
individual units of source code, sets of one or more computer program modules
together with associated control data, usage procedures, and operating procedures,
are tested to determine whether they are fit for use.
Unit testing is a software development process in which the smallest testable parts
of an application, called units, are individually and independently scrutinized for
proper operation. Unit testing can be done manually but is often automated.
Unit testing is usually conducted as part of a combined code and unit test phase of
the software lifecycle, although it is not uncommon for coding and unit testing to
be conducted as two distinct phases.
1. Test strategy
2. Approach
Field testing will be performed manually and functional tests will be written in
detail.

6.1.1 Test objectives

1. All field entries must work properly.
2. Pages must be activated from the identified link.
3. The entry screen, messages and responses must not be delayed.

6.1.2 Features to be tested

1. Verify that the entries are of the correct format.
2. No duplicate entries should be allowed.
3. All links should take the user to the correct page.
 32

6.2 Integration Testing

Integration tests are designed to test integrated software components to determine
if they run as one program. Testing is event driven and is more concerned with
the basic outcome of screens or fields. Integration tests demonstrate that although
the components were individually satisfied, as shown by successfully unit testing,
the combination of components is correct and consistent. Integration testing is
specifically aimed at exposing the problems that arise from the combination of
components.
Some different types of integration testing are big-bang, top-down, and bottom-
up, mixed(sandwich)and risky hardest. Other Integration patterns are:
collaboration integration, backbone integration, layer integration, client-server
integration, distributed services integration and high frequency integration.
It is the phase in software testing in which individual software modules are
combined and tested as a group. It occurs after unit testing and before validation
testing.

6.2.1 Big Bang Approach

In the big-bang approach, most of the developed modules are coupled together to
form a complete software system or major part of the system and then used for
integration testing. This method is very effective for saving time in the integration
testing process. However, if the test cases and their results are recorded properly,
the entire integration process will be more complicated and may prevent the
testing team from achieving the goal of integration testing.

6.2.2 Bottom-Up Testing

Bottom-up Testing is an approach to integrated testing where the lowest level
components are tested first, then used to facilitate the testing of higher level
components. The process is repeated until the component at the top of the
hierarchy is tested.
All the bottom or low-level modules, procedures or functions are integrated and
then tested. After the integration testing of lower level integrated modules, the
next level of modules will be formed and can be used for integration testing. This
 33
approach is helpful only when all or most of the modules of the same
development level are ready. This method also helps to determine the levels of
software developed and makes it easier to report testing progress in the form of a
percentage.

6.2.3 Top-Down Testing

Top-down Testing is an approach to integrated testing where the top integrated
modules are tested and the branch of the module is tested step by step until the
end of the related module.

6.3 System Testing

System Testing of software or hardware is testing conducted on a complete,
integrated system to evaluate the system’s compliance with its specified
requirements. System testing falls within the scope of black-box testing, and as
such, should require no knowledge of the inner design of the code or logic.
As a rule, system testing takes, as its input. All of the” integrated” software
components that have passed integration testing and also the software systems
itself integrated with any applicable hardware system(s). The purpose of
integration testing is to detect any inconsistencies between the software units that
are integrated together (called assemblages). Or between any of the assemblages
and the hardware. System Testing is a more limited type of testing; it seeks to
detect defects both within the “inter-assemblages''. And also within the system as
a whole.
System Testing is a level of the software testing where a complete and integrated
software is tested. The purpose of this test is to evaluate the system’s compliance
with the specified requirements. Definition by ISTQB. System testing: The
process of Testing an integrated system to verify that it meets specified.
System testing ensures that the entire integrated software system meets
requirements. It tests a configuration to ensure known and predictable results. An
example of system testing is the configuration oriented system integration test.
System testing is based on process descriptions and flows, emphasizing pre-driven
process links and integration points.

6.4 Functional Testing

 34
Functional tests provide a systematic demonstration that functions tested are
available as specified by the business and technical requirements, system
documentation, and user manuals.

Functional testing is centred on the following items:

Valid Input : identified classes of valid input must be accepted. Invalid
Input : identified classes of invalid input must be rejected.
Functions : identified functions must be exercised.
Output : identified classes of application outputs must be exercised.
Systems/Procedures: interfacing systems or procedures must be invoked.

Organization and preparation of functional tests is focused on requirements, key

functions, or special test cases. In addition, systematic coverage pertaining to
identify business process flows, data fields, predefined processes, and successive
processes must be considered for testing. Before functional testing is complete,
additional tests are identified and the effective value of current tests is
determined.

There are two basic approaches of functional testing:

a. Black box or functional testing.
b. White box testing or structural testing.

6.4.1 Black box testing

Specific knowledge of the application’s code/internal structure and programming
knowledge in general is not required. The tester is aware of what the software is
supposed to do but is not aware of how it does it. For intense, the tester is aware
that a particular input returns a certain, invariable output but is not aware of how
the software produces the output in the first place.
This method is used when knowledge of the specified function that a product has
been designed to perform is known. The concept of black box is used to represent
a system who’s inside workings are not available for inspection. In a black box
the test item is eaten as “Black”, since its logic is unknown is what goes in and
what comes out, or the input and output. In black box testing, we try various
inputs and examine the resulting outputs. The black box testing can also be used
 35
for scenarios based tests. In this test, we verify whether it is taking valid input and
producing resultant output to the user. It is imaginary box testing that hides

internal workings. In our project, valid input is image resultant output well-
structured image should be received.

Black-Box Testing is a method of software testing that examines the

functionality of an application without peering into its internal structures or
workings. This method of tests can be applied virtually to every level of
software testing: unit, integration, system and acceptance. It typically comprises
most if not all higher level testing, but can also embody unit testing.

6.4.2 White box testing

White-Box Testing (also known as clear box testing, glass-box testing, transparent
box testing and structural testing) is a method of testing software that tests
internal structures or workings of an application, as opposed to its functionality
(i.e. black-box testing). In White-box testing an internal perspective of the
system, as well as programming skills, are used to design test cases. The tester
chooses inputs to exercise paths through the code and determine the appropriate
outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit testing(ICT).
White-box testing can be applied at the unit, integration and system levels of the
software testing process. Although traditional testers tended to think of White-
Box testing as being done at the unit level, it is used for integration and system
testing more frequently today. It can test paths within a unit, paths between units
during integration, and between subsystems during a system-level test. Though
this method of test design can uncover many errors or problems, it has the
potential to miss unimplemented parts of the specification or missing
requirements.
White box testing is concerned with testing implementation of the program. The
intent of structural testing is not to exercise all the inputs or outputs but to exercise
the different programming and data structures used in the program. Thus, structure
testing aims to achieve test cases that will force the desired coverage of different
structures. Two types of path testing are:
[1] Statement testing
[2] Branch testing
 36
6.4.2.1 Statement Testing
Statement coverage is a white box technique which involves the execution of all
the statements at least once in the source code. It is a metric, which is used to
calculate and measure the number of statements in the source code which have
been executed. Using

this technique, we can check what the source code is expected to do and what it
should not. It can also be used to check the quality of the code and the flow of
different paths in the program. The main drawback of this technique is that we
cannot test the false condition in it.
The main idea of statement testing coverage is to test every statement in the
object’s method by executing it at least once. However, realistically, it is
impossible to test a program on every single input, so you never can be sure that a
program will not fail on some input.
6.4.2.1 Branch Testing
The main idea behind branch testing coverage is to perform enough tests to ensure
that every branch alternative has been executed at least once under some test. As
in statement testing coverage, it is unfeasible to fully test any program of
considerable size.
Branch Coverage is a testing method, which aims to ensure that each one of the
possible branches from each decision point is executed at least once and thereby
ensuring that all reachable code is executed.
That is, every branch taken each way, true and false. It helps in validating all the
branches in the code making sure that no branch leads to abnormal behaviour of
the application.

6.5 Integration Testing

Integration Testing (sometimes called integration and testing, abbreviated I&T) is
the phase in software testing in which individual software modules are combined
and tested as a group. It occurs after unit testing and before validation testing.
Integration testing takes as its input modules that have been unit tested, groups
them in larger aggregates, applies tests defined in an integration tests plan to those
aggregates, and delivers as its output the integrated system ready for system
testing.
 37
Software integration testing is the incremental integration testing of two or more
integrated software components on a single platform to produce failures caused by
interface defects.
The task of the integration test is to check that components or software
applications, ex. components in a software system or one step up software
applications at the company level - interact without error.

Test Results: All the test cases mentioned above passed successfully. No defects
encountered.

6.6 Acceptance Testing

User Acceptance Testing is a critical phase of any project and requires significant
participation by the end user. It also ensures that the system meets the functional
requirements.
In engineering and its various sub disciplines, acceptance testing is a test
conducted to determine if the requirements of a specification or contract are met.
It may involve chemical tests, physical tests, or performance tests.
In systems engineering it may involve black-box testing performed on a system
(for example: a piece of software, lots of manufactured mechanical parts or
batches of chemical products) prior to its delivery.
In software testing the ISTQB defines acceptance as: formal testing with respect
to user needs, requirements, and business processes conducted to determine
whether a system satisfies the acceptance criteria and to enable the user,
customers or other authorized entity to determine whether or not to accept the
system. Acceptance testing is also known as user acceptance testing(UAT), end–
user testing, operational acceptance testing(OAT) or field (acceptance) testing.
A smoke test may be used as an acceptance test prior to introducing a build of
software to the main testing process.

Test Results: All the test cases mentioned above passed successfully. No defects
encountered.
 38

TESTING RESULTS
 39
1. Soil Moisture Sensor Value:
(a) In case there is no water in the plant the soil moisture sensor value will be
between 0 to 300 and the red LED will be on and relay and the pump will be on .
It is shown below:
 40

(b) In case there is water up to level one in the plant the soil moisture sensor value
will be between 300 to 700 and the red LED as well as green LED will be on and
relay will be off. It is shown below:
 41

(c) In case there is water up to level two in the plant the soil moisture sensor value
will be between 700 to 1023 and the red LED, green LED and blue LED will be
on and relay as well as pump will be off. It is shown below:
 42

2. Temperature and Humidity Sensor value: Above room temperature

it will show temperature alert.
 43

2. Light Sensor value: If the light value is greater than 400, it shows day
time:

If the light value is less than 400, it will show night time and will give us a light
alert:
 44

CHAPTER 7
FUTURE SCOPE

The future scope of this project can be comprehended in many aspects such as
to add camera module to detect whether the plants are getting enough resources
and whether they are growing without any resistances. Camera module clicks
picture and send it through mail. Our project can be improvised by using a
sensor to note the soil ph value such that usage of unnecessary Fertilizers can
be reduced. A water meter can be installed to estimate the amount of water used
for irrigation and thus giving a cost estimation. Further, it also reduces the
investment of farmers. In addition to the excess cost of water, labour is becoming
more and more expensive. The proposed irrigation system will be very efficient
in areas like house gardens, office premises, buildings etc. where watering plants
at regular interval matters. This system also presents a smart drip irrigation
system to water plants using devices like raspberry pi, Arduino microcontrollers.
This type of agriculture application of Internet of things in the real world
environment is necessary to know the effect of the environment on such system.
So is always better to know the risks beforehand.
 45

CHAPTER 8
CONCLUSION
By completing this project, a smart irrigation system has been implemented
using Arduino UNO module. It is an automated system and beneficial for
mankind. This project proposes a design for smart home garden irrigation
system that implements ready-to-use, energy-efficient, and cost effective devices.

1. The implemented system is integrated with multi-sensors such as soil

moisture sensors, humidity and temperature sensors.
2. This proposed system managed to reduce cost, minimize waste water,
and reduce physical human interface.
3. The entire system is monitored and controlled by the power full credit
card sized microcomputer called Arduino UNO.
4. The system is capable of automatic watering of plants depending upon
certain parameters.
 46

REFERENCES

[1] Y.G. Gawali, D.S. Chaudhuri, H.C. Chaudhuri, “Review paper on Automated
irrigation system using WSN”, IJARECE Volume 5, Issue 6, June 2016.

[2] A. Joshi, L. Ali, “Survey on auto irrigation system”, IEEE Catalog Number
CFP17D81- POD, March 2017.

[3] T.J. Kaczmarski, SSRG International Journal of Electronics and

Communication Engineering. March 2017.

[4] D. Rane, P.R. Indurkar, “Review paper on Automatic irrigation system using
RF module”, IJAICT vol 1, Issue 9, January 2015.

[5] B.K. Chate.J.G. Rana,” Smart irrigation system using Raspberry pi”, IRJET,
vol 3 issue 5, May 2016.

[6] B.H. Fouchal, O. Zytoune, D. Aboutajdine, “Drip Irrigation System using

Wireless Sensor Networks”, Volume 44, Issue 4, July 2018.

[7] Gutiérrez, Francisco Villa-Medina et al. “Automated Irrigation System Using

a Wireless Sensor Network and GPRS Module”, IEEE 63(1):166-176, January
2014.
48