Smart plant pot
Introduction
In this project, I set out to design, develop and build a fully functional 'smart' plant pot. The initial design
consisted of various sensors embedded in the pot to capture health data of the plant, environment data of its surroundings along with a water delivery
system which would enable the pot to water itself.
I first got the idea of designing this pot when I was away on holiday a few years ago. I had a particular plant I was very fond of and it happened to be very difficult to grow and keep alive,
so the thought of leaivng it alone for a week wasn't nice! (I'm know, I'm sad). I then thought to myself, how cool would it be if I had a way of monitoring how dry the soil was, and
if it got to a certain level, how I could remotely water it. From there, the idea grew into what you see in the following article. A system that captures environment
information as well as information about the plant, displaying this in real-time on a front-end web portal- and accomodating an automatic watering schedule and manual override.
At the heart of this project there was an Arduino Yún prototyping board, which eventually evolved into a standalone ATMega 328p micro-controller. In this blog post, I will be covering all aspects
of the design and implementation stages of this project, covering considerations I made along the way and the rationale behind certain design choices. Please note, this post is not a tutorial as it is just
just to highlight and explore the various stages and choices made along the projects development journey.
Parts and modules
To begin with, let's cover what parts and modules I used for this project. Some parts I already had and reused form old hardware, others I bought specifically for this project.
In this project I used:
- Arduino Yún
- ATMega 328p Micro controller
- ESP8266 Wifi module
- USBasp AVR Programmer
- Breadboard
- Breadboard power supply board
- Temperature sensor
- Humidity sensor
- An old GPU fan
- Soil moisture sensor
- Vertical water sensor
- Micro water pump (M200 series from TCS Micropumps)
- Resistors, Crystals, Capacitors, Mosfet, LED's and jumper wires
- And LEGO!
Design choices
The first and immediately obvious design choice in this project was deciding what prototyping board to use. I settled on the Arduino Yún because of two main factors. One, I already had it and it didn't make sense to buy something new when this already worked. Second, the Yún has built in Wi-Fi, which made communicating with my endpoints (which we will explore on soon) easier as no external Wi-Fi breakout board was required. With the Yún you can simply configure it to connect to your home or office Wi-Fi and you are good to go, no other setup required. I did eventually replace the Yún with a stand-alone ATMega 328p micro-controller, which also meant I needed to find a solution to provide Wi-Fi to the project. For this I settled on the ESP8266 Wi-Fi module.. more on this later!
The next design choice I made was only really a choice once some development had started and I realised I'd need to redesign the physical structure
of the system. Initially, I had the vision that the 'smart' system was seperate to the main plant pot, more of an 'add-on' to the existing planter.
However, after testing and experimenting with different designs, I decided that actually, it would work really well if the entire system was one; i.e.
the planter, water tank, and control unit were one coherent unit.
After deciding that it should be a single unit, the question was then what to make it out of? I finally decided on the perfect building material... LEGO!
Loved by children and adults alike, LEGO was the perfect material as it allowed me to build multiple designs without having to worry about using up a design
material. After multiple iterations, I finally settled on the one you see above (Fig. 1). This design had fittings for two plastic tubs, the bottom tub being the water tank,
and the top tub the actual planter. To the right of the planter tower is the controller unit, complete with stilts to hold a cooling fan above the circuit. A design for the future would be to
include this controller unit under the water tank, making the planter slimmer smaller. I was unfortunately limited by the amount of LEGO I had to hand and parked this idea for future iterations. (In a perfect
world I would use a 3D printer to print all the parts of the body, but alas, perhaps in the future).
I found that a lot of the design process was trial and error. For example, I wanted to make the physical structure out of recycled material, but cardboard and old juice cartons aren't very structurally
secure, and in addition to this it was difficult preventing the juice carton from leaking over the cardboard and having it crumble under its own weight.
One design choice I made right at the end of this project was to switch from using the Yún as the prototyping baord to using an ATMega 328p micro-controller to control my hardware proram logic. One of the main
reasons I did this was to learn how to upload program code to stand-alone micro-controllers such as the 328p, as I was planning to do this for a future project. Another reason for deciding to do this was to
free up the Yún to use for other projects.
Due to the above, I also then needed to find a new solution for bringing internet connectivity to my project. After researching reliable and easy to use Wi-Fi modules, I eventually found the
ESP8266 module. On the face of it, this module seemed easy enough to use, and from what I could tell, also seemed to provide a fairly reliable and stable Wi-Fi connection.
Although fruitful, this choice did end up causing more work than I believe was worth for this particular project (considering at the time of implementing the ESP8266, everything else
had already been done). This is because, although powerful, the ESP8266 module I had, had an old version of the AT Firmware. Which, for those who don't know, is the fiemware developed by
ESPRESSIF, the developers of the ESP Wi-Fi boards. This resulted in me writing a custom library for the module to actually get the thing working properly,
and even then, there were a few small bugs. Reflecting on this however, this library will be useful for future projects, but at the time, caused a serious headache.
Key components
With so many moving parts to this project, there were lots of components to develop and build to ensure everything worked together as it should. To complete this project, there were 5 major components developed; these were:
- API Framework
- Web portal
- Analytics feed
- Hardware controller
- Electronics
The most time consuming of this was definitely building out the front end web portal, and integrating an analytics platform (seen in Fig 3.), however the most complex from a technical point of view was by far was writing a custom library for the ESP8266 mentioned above. Adding to this complexity was then getting the library to work hand in hand with the existing hardware controller I had previously written.
In the following sections, I'll explore these key components in more detail, and highlight anything particular that stood out as challenging or time consuming. Keeping in mind, though, as I mentioned at the beginning of this article, this is not a tutorial on how to create something similar.
API Framework
The first major component to this project was figuring out how data was going to flow in and out of the device, as well as in and out of a database. For this, I designed a simple REST API to handle various requests coming from the plant pot and front end. Over time as the projects feature scope evolved, the schema grew larger to accomodate more features. Eventually, the final schema contained the following endpoints:
- /Actions - PUT action to action queue, GET action from action queue. Action = Activate water pump
- /Data - PUT data to DB, GET data from DB
- /Scheduler - GET current pots automatic watering schedule
- /Info - GET information of current pot from DB
Essentially, the final API was the bare minimum needed for the pot to operate. It contained endpoints to send data too and from the plant pot and front-end, as well as a way to manually override the watering pump on the front-end, this was performed using the 'manual override' button seen in Fig 4.
This component was probably one of the quickest of the five to build, as the API itself was written entirely in PHP using an in-house framework I developed a while ago. Because of this, getting the API up and running to a point where I could send mock data too and from a mocked front-end was relatively simple. For testing, I used Postman a lot to ensure that everything behaved as it should.
Web portal
Although not technically complex, this component contained the most code to be written. The front-end was written entirely in HTML/CSS, with some help from Bootstrap and other libraries (such as Graph.js) for the analytics.
There's probably not much in this section thats of too much interest, essentially Ajax was used to send requests to/from my API's endpoints, Graph.js was used to display the planter data onto graphs, and Bootstrap was used to tie it all together into a nice UI.
A lot of thought did however go into the design of the analytics, which will be explored in more detail in the next section below.
Analytics feed
Another key component to this project was the analytics feed on the front-end. It was important that this was as near real-time as possible. In the final version of this project, there is a 5 second delay between each new incomming data point. To me, this
is an acceptable tolerance to what can be classed as 'real-time'. The analytics feed is an important component of this project because it gives a real world representation on what all the data being collected by the smart planter actually means.
The idea of the analytics front-end was to provide a '10 second summary' of your plant and its stats. To achieve this, simplicity was key. Moreover, visual aids such as colour coding the data, helps to convey important information more quickly. For example,
at a glance, you only have to see if any given metric is red or green to get an indication of what state it is in (good or bad).
As well as real-time graphs that plot the incomming metric data, I also implemented a 'summary' panel, which you can see top right of the page. The purpose of this panel gives you an average glance of all your metric data over a period of time. That way, even if the graph fluctuates
data point to data point, its average will remain fairly constant.
Overall, I again used the motto 'simplicity is key' for this component; attempting to display the plants health data in the most digestible way possible.
Hardware controller
This component contained the smallest amount of code - ~400 lines - but, it was by far the most complex piece of the project. Countless hours went into debugging serial data, analysing sensor data output, and testing HTTP requests from both the Yún and ESP8266. The controller
itself was written in the Arduino language, similar to C/C++. The core logic itself was not tricky per se, but with so many moving parts (sensors + data, HTTP requests, processing data from database, knowing when to invoke certain action, etc.), it soon became a lot to manage.
Because of this, I split the hardware controller up into smaller, more managable sub-sections. First, I wrote the code that would gather data from the sensors and store them in variables for later. Next I worked on getting HTTP requests (which I later re-wrote, due to the ESP8266) working. From there,
I integrated the two sub-sections together to get data into the database direct from the hardware. I then re-vistited the HTTP requests section to process incomming data from the database into the hardware controller, enabling manual override and a scheduling system on the water pump. And then finally,
wrote a custom libaray for the ESP8266 Wi-Fi module, and of course integrated this with the existing controller code and tested along the way.
Another key area of writing the hardware controller was using the USBasp TTL programmer module to upload my program code to the ATMega 328p micro-controller. Although the uploading part was not difficult, once the code was in the controller and running on its own, debugging became tricky. I ended up resorting to
integrating an I2C LCD screen so that I could see some form of output. And of course, just because the program code worked on the Yún, did not mean that it worked as expected on the stand-alone 328p micro-controller. This was definitely the most time consuming part, as even the smallest change in code meant re-uploading the
program code to the 328p MC; thankfully I could fully dedicate a spare breadboard as a 'flashing board' so I didn't have to keep wiring and un-wiring the TTL programmer (seen here in Fig 5.).
With so many parts and areas for error, debugging did take up a large portion of time during this stage. I believe my method of splitting the tasks into smaller sections and implementing/integrating as I wwent was probably the best approach.
Electronics
Finally, the electronics. This section was done in tandem with both the hardware controller and web portal sections mentioned above. This part was probably one of the simplist sections of the project; as all the sensors I used were well documented, and schematics existed online showing exactly
how to use them with an Arduino board.
Although my academic background is computer science, I did share modules in electornics. So, although this component wasn't completely alien to me, I did definitely need to go through a small refreshment before properly getting stuck in. For example, when I first started designing the electronics I forgot about
the maximum safe current rating for certain components, and thus some LEDs were safrificed in the making of this project. Thankfully, with all the components being fairly simple, no complicated circuits were needed to get the project off the ground.
Final result
This leads me onto the final result of the project. By the time I decided I was done (for the time being), the smart plant pot had the following capability:
- Real-time metrics on plant and environment data
- A web console, allowing you to view plant information and provide other features
- A manual over-ride feature on the web portal, allowing you to remotely trigger the water pump
- An automated watering schedule, set on the web console
- An all-in-one design, keeping the planter, water tank and control unit one
Future work
This project was a great learning experience. I learnt a lot about electronics, how to program an ATMega 328p micro-controller, use the ESP8266 Wi-Fi module,
and much, much more. In total, I probably spent upwards of 120 hours on this, where most of that time was dedicated to building the hardware controller.
Throughout this project, I have had thoughts and ideas that would increase the user experience of this device; or even make the device do more. It's important, however, in any project you work on,
to define its scope at the very beginning and stick with it. For example, when I was done with the web front-end, I really liked the idea of developing a mobile app too, that way you're not just limited to viewing it on a browser.
This though, would have added extra requirements, extra hours programming, extra hours testing/ debugging, and all for something that wouldn't really add much to the project in its current form.
As well as this, when thinking about a mobile app, I thought to myself, wouldn't it be cool to give the plant pot bluetooth? That way my mobile app can communicate directly with the pot? This would have
also been a good idea for a pots 'first time setup' - a user could use bluetooth to configure the pots Wi-Fi information, as currently you need to specify that info in the hardware controller code. Again, this
is a feature that, if the time came and the pot was developed commercially, would be a great idea. But for prototyping now, probably not needed.
Another idea I had for the pot was to integrate some form of open API that provides plant informaiton, enabling the system to track the lifecycle of any given plant you are growing. That way, it could display on the
front-end what stage of the plants life its currently in, if its on track to grow properly, what potential diseases it could contract, if its current environment is optimal for its species, etc. This again, although fantastic,
was a little out of scope for this project, although would provide a set of rich features for future iterations.
Finally, on more of the technology and infrastructure side of things; another idea I had was to migrate this project into the cloud. Leveraging services such as AWS Lambda, AWS IOT Core and AWS Quicksight, to name a few.
This would enable a lot of the functionality I custom built to be consumed out of the box, meaning less headaches debugging and testing. This feature will be something I look to implement in future iterations of this project, which
I will revisit from time to time and maybe even write another blog post in the future.
Wrapping up
For now, though, I am marking this project as both successful and closed. I achieved what I set out to do, and in my opinion it works very well. Room for improvements? Definitely! But find me a project that has none!
On a serious note, I hope those that made it this far found the article interesting! Please do connect and say hi on the various social channels listed on my Contact page.
Thank you! -- Chris
