We aim to create a modular device capable of monitoring the growing environment of plants. Possible applications would be greenhouses, garden stores or even large private/public gardens. The idea is to work with a modular setup, consisting of a central server and various different sensor modules that can be added on demand. This results in a scalable system that allows you to add and (re)move sensors depending on your needs.
This system would consists of three separate parts which will be elaborated on in this document.
Our current plan consists of:
The hardware for this project will be based on an ESP module since these microcontrollers have wifi capabilities, and are compact in size. The ESP32 even contains bluetooth functionality which could be beneficial. All ESP modules currently support mesh capabilities, which could be an interesting feature in the future.
Preferably the device will run on solar energy and contain a small battery to serve as backup. The first prototypes will most likely use a USB powerbank (which is possibly charged using a built-in solar panel). In a later stage this solar panel could be built into the device.
The sensors need to be water-, dust-, and uv-resistant to ensure they can stay outside without worry.
The sensors need to be small and lightweight as to not be a cumbersome process to install and remove.
The sensors need to work wirelessly to prevent the need for running cables.
The server will in early stages be a Raspberry Pi running a database where all the information is stored. Next to this database will run a program where individual devices can connect to as clients. This program (henceforth called the server) will keep track of all connected clients and their status. It will handle all authentications required to communicate in a secure way.
The server should be able to identify which sensor is sending data to it.
The server should be able to accept all the sensor data, and store this in a practical format (either database or file).
The server should be able to communicate the collected sensor data with the user interface through an API, or by sharing a database.
The interface is the place where a user can login to view the collected data. This could be either a webapp running on the same raspberry pi as the server or a mobile application.
A web based application would require the user to use his/her (mobile) device to browse to a website and view all required information. Big advantage of this type of user interface is that the device used to view the UI is almost irrelevant as long as it's a reasonably modern device. A disadvantage is that the site is a central point of information and could significanlty increase the workload of the server if not handled carefully.
Disadvantages:
Advantages:
The user interface has to authenticate a username and password.
The user interface has to allow adding and removing of sensors.
The user interface has to show sensor data in (adjustable) graphs.
The user interface has to allow for setting of notifications in certain circumstances (e.g. pH of sensor X lower than value Y)
mDNS could be used to name the pi and easily find in on the local network (e.g. raspberrypi.local)
tables will be added as headers followed by a short description. Column names will be between square brackets followed by their function
This table tracks the currently known devices and their status, any dew devices will be added to this table.
since the sensors will be spread throughout a certain area, this table keeps track of where they are. Its intended use is either providing an alias in case of individual sensors (e.g. 'passion flower balcony') or coordinates (e.g. in a greenhouse).
will the user use a coordinate system, inidvidual aliases, both, dark mode, etc
this table will hold all users allowed to login to the system.