Note: With my final year of undergraduate study started, and my proclivity to take far too many credits, I’ll be taking a break from writing blog posts until I graduate this spring
Note 2.0: The project has advanced and evolved further than this post goes into. To see current progress, visit the repo at: https://github.com/ColbyLeclerc/AGM-API
How can you grow a better crop without knowing your plant’s environment?
My friends and I have an indoor mini greenhouse, were we, obviously, grow plants. Two very important metrics are temperature and humidity. Keeping these metrics within a specific range, allows for better nutrient absorption.
Given the importance of these metrics, I was surprised to see many of my friends used a manual temperature/humidity monitor. That means, they only know if the greenhouse is within the needed range at small windows of time throughout the day – when they check them.
What happens at night? When the lights turn on? Turn off? Unless you’re physically present to read the metrics during this time, who knows what the humidity and temperature is.
Thus, comes an IoT (“Internet of Things” (Or just embedded systems) ) solution!
Using a few cheap parts, we can create a continuous monitoring system to allow us to capture the data about the environment. Then, we can graph the data and look for trends.
For the first prototype, I’ll have a temperature/humidity sensor within the greenhouse, and outside the greenhouse. This way, we can compare both the ambient and internal temperature/humidity metrics.
Below is the list of items I’ll be using (Note, these are affiliate links to the products I used):
- 1x Rasberry Pi B+
- 2x DHT 22 Temperature/Humidity sensor
- Wires and Resistors (from past projects)
- Old laptop/computer to act as the local server
An older Rasberry Pi will work, however I chose the B+ because of the integrated WiFi chip and Bluetooth chip. For older Rasberry Pi’s, you would either need a USB WiFi card, or use a physical Ethernet connection.
About a year ago I used a similar setup, except I had an Arduino Uno to read the sensor data, and the Rasberry Pi was used to transmit data.
For the server, I have an old laptop running Linux, or a Rasberry Pi (2011,12 model). I’ll probably try having the database and server run on the Rasberry Pi, given that we’re only collecting data on two sensors, thus a small work load.
The alternative is to use the laptop as the HTTP server to accept the data requests from the Rasberry Pi. This gives us much more power, and it would be easier to configure and mess around with if anything goes wrong after deployment.
As a basic overview, I’ll create a simple HTTP server that will host a REST endpoint for the Rasberry Pi to use to store the sensor data.
I have experience with Microsoft’s SQL server, and MySQL, but I want to try out PostgreSQL. I’ve heard great things from other developers, plus after version 9.2, PostgreSQL now natively supports JSON column type (This means we can now create indices with JSON data type).
From what I’ve read, with the JSON column type, you can create a pseudo NOSQL database, however for our purposes I’ll stick to a more relational approach.
I haven’t tried installing PostgresSQL onto a Rasberry Pi, so I’m not sure if the older model will be able to handle both the HTTP server and the database.
There are some fun features I want to try adding to the project, even if it would be overkill for our current specifications.
One such feature would be a caching system made on the Rasberry Pi. Essentially, if the HTTP server request fails, I want each of those requests cached until connection to the server is restored. After connection is restored, a sort of “back-fill” of previous data would be sent to the server.
This way, if the server goes down, we won’t have a gap in our sensor data.
A second feature is an automated backup system, where the database server will push backups to a remote backup server (or a free Google Drive account).
Now that we have a basic overview of the system, we can start defining more concrete plans with some Entity-Relation Diagrams, define the REST endpoints, and choose a language for our server.