close-circle
Close
0%
0%

Internet of Plants (IoP)

Internet of Plants is essentially a mesh-network of plant master and slave controllers for better & less plant care with affordable pricing

Similar projects worth following
close
We probably all know the struggles of caring for a plant, it's just time-consuming and unpredictable. The application Internet of Plants tries to solve exactly this problem.

IoP collects data from essentially three sensors (DHT22, TSL2561, Hygrometer) and calculates a forecast for each plant. Internet of Things doesn't stop there, but rather expands and provides a decentralized network with masters and slaves to ensure data safety and communication across multiple devices for better usability.

Other features include an REST-API and frontend that takes use of the API, hardware components for physical user interactions and custom PCBs.

So what exactly does Internet of Plants do to enhance the users experience with plant caring?
With the help of an extensive frontend, it provides a smart, automated and efficient way to care less for your plants. IoP even supports hardware and software actions, for example, emails for responsible persons, LEDs, and automated watering.

In what scenarios can Internet of Plants be used?

IoP is designed to be expandable and customizable, and just requires a minimum of code change for different problems to solve. To list some examples, the mesh network doesn't rely on the existence of the internet and could easily use radio frequencies, so even outside farming is with this change supported. Another example is the potential use in vertical farming. With just a database change, the water pump is triggered by humidity and not soil moisture.


So what exactly does the mesh network? It is complicated but can be explained through the provided illustration. In this example, a recommended setup is shown, with one or more master (square) per room and any number of slaves (circle). To display possible request routes arrows are provided to show the directions possible.

The Mesh-Network Illustration


The master consists of several independent modules, who interact with each other. An illustration is provided to describe these interfaces and interactions.


The slave module consists of considerably fewer modules, due to the lack of processing power and random access memory (RAM). Because of these constraints, the application is not able to use a database and instead operates with files. Another illustration is provided to describe the interfaces and interactions.


Want to see a feature implemented? Just tell me, I'm always interested in new and fresh ideas and I'll probably add your suggestion!

  • 1 × (per master) Raspberry Pi B+
  • 1 × (per master) SD-Card 16GB I don't recommend Samsung SD-Cards
  • 1 × (per master) DHT22 Temperature & Humidty sensor
  • 1 × (per master) TSL2561 Sensors / Ambient Light
  • 1 × (per master) Hygrometer Moisture Sensor

View all 16 components

  • REST v4.1 & frontend v3.2 & mesh v2.7

    Bilal Mahmoud04/12/2017 at 20:04 0 comments

    So what exactly changed?

    To be honest, nothing you can really see. The frontend and mesh-network now support RESTv4, which increased the speed up to 100%.

    In other news /responsible/ got removed and / added. The new path now returns a JSON object full of every endpoint and the possible data you can input. That's a quite important and visible addition to the REST-API. /discover now no longer uses a PUT request for execution but rather a POST boolean input called execute. The attribute dict is now also deprecated and should not be used anymore.

    Also in the backend of the backend (REST-API), an own input verification system got added, that proves if the correct data got inserted and converts the data if possible and necessary. The new verification system uses the following syntax to gather the data:

    {'name': STRING, 'type': TYPE, 'fallback': STRING, 'restricted': [STRING, {'name': STRING, 'fallback': STRING}], 'list': BOOLEAN}
    A small explanation:
    • name is the name of the selected argument
    • type is the target type of the argument, like str, bool, int or float
    • fallback is used if the argumentis not present or a non-valid value
    • restricted is a list of all possible values, if a value referes to another it is a string with a name and fallback
    • list is a boolean indicating if chaining should be done

    Also, the select statement now supports chaining. So you can now query for multiple things at once, in just one request. It get's returned as an object, where each item in select is a key. Here's an example:

    Example request GET arguments:

    ?select=created_at,timestamp
    Example input verification output:
    {"select": ["created_at", "timestamp"]}
    Example return output:
    {'created_at': DATA, 'timestamp': DATA}

    REST v4.2 will remove REST v3 and include a write only test case

    Have a nice day

  • REST v4

    Bilal Mahmoud04/02/2017 at 13:21 0 comments

    For the fourth time completely rebuilt how the REST-API works. I did this because hit a wall concerning reusability, simplicity, and expandability.

    Instead of having one path for one interaction, I regrouped them for a better RESTful representation and a less hacky approach.

    To show the changes I made, these are the old URLs in REST v3:

    /create/message
    /create/plant
    /create/plant/register
    /create/responsible
    /delete/responsible/<r_uuid>
    /execute/discover
    /get/day/night/time
    /get/discovered/<int:registered>/names
    /get/discovered/<int:registered>/names/extended
    /get/message/<m_uuid>
    /get/message/<m_uuid>/content
    /get/messages/names
    /get/plant/<p_uuid>
    /get/plant/<p_uuid>/created_at
    /get/plant/<p_uuid>/intervals
    /get/plant/<p_uuid>/location
    /get/plant/<p_uuid>/message
    /get/plant/<p_uuid>/responsible
    /get/plant/<p_uuid>/responsible/email
    /get/plant/<p_uuid>/responsible/username
    /get/plant/<p_uuid>/responsible/wizard
    /get/plant/<p_uuid>/sensor/<s_uuid>/latest
    /get/plant/<p_uuid>/sensor/<sensor>/<any(high, low):mode>/today/<any(yes,no):if_no_data_days_before>
    /get/plant/<p_uuid>/sensor/<sensor>/<any(high,low):mode>/ever
    /get/plant/<p_uuid>/sensor/<sensor>/data
    /get/plant/<p_uuid>/sensor/<sensor>/data/<float:until>
    /get/plant/<p_uuid>/sensor/<sensor>/data/count
    /get/plant/<p_uuid>/sensor/<sensor>/data/current
    /get/plant/<p_uuid>/sensor/<sensor>/data/start/<int:start>/stop/<int:stop>
    /get/plant/<p_uuid>/sensor/<sensor>/prediction
    /get/plant/<p_uuid>/sensor/<sensor>/range
    /get/plant/<p_uuid>/sensors/range
    /get/plant/<p_uuid>/status/average
    /get/plant/<p_uuid>/status/online/
    /get/plant/<p_uuid>/survived
    /get/plant/<p_uuid>/type
    /get/plant/<plant>/average_status/percent
    /get/plant/<plant>/current_status
    /get/plant/current/host
    /get/plants/master
    /get/plants/name
    /get/plants/name/extended
    /get/plants/satisfaction
    /get/plants/sensors/satisfaction
    /get/responsible/<r_uuid>
    /get/responsible/persons
    /get/sensor/<s_uuid>
    /get/sensor/<sensor>/range
    /get/sensor/<sensor>/unit
    /update/current/host/to/localhost
    /update/day/night/time
    /update/notification/message
    /update/plant/<p_uuid>/alive/<any(online,offline):mode>/add
    /update/plant/<p_uuid>/connection-lost/duration
    /update/plant/<p_uuid>/location
    /update/plant/<p_uuid>/name
    /update/plant/<p_uuid>/non-persistant/duration
    /update/plant/<p_uuid>/notification/duration
    /update/plant/<p_uuid>/ranges
    /update/plant/<p_uuid>/responsible
    /update/plant/<p_uuid>/satisfaction/level/add
    /update/plant/<p_uuid>/satisfaction/level/reset
    /update/plant/<p_uuid>/type
    /update/responsible
    /update/responsible/wizard
    

    Those are many paths to remember and to use, huh?

    In REST v3 only /get/ essentially used the GET method. Everything else, more or less consistent, used the POST method.

    What exactly changed? Instead of having 65 endpoints, which aren't particularly well ordered or have any structure what so ever, the new API now has 18 endpoints and is a bit faster. The new endpoints are using, instead of only one, multiple HTTP request method. Just for comparison, here's a small list of the new paths and the supported methods:

    /day/night                         (GET, POST)
    /discover                          (GET, PUT - substitute for execute)
    /host                              (GET, POST)
    /messages                          (GET, PUT)             
    /messages/<m_uuid>                 (GET, POST)
    /persons                           (GET, PUT)
    /persons/<r_uuid>                  (GET, POST)
    /plants                            (GET, PUT)
    /plants/<p_uuid>                   (GET, POST)
    /plants/<p_uuid>/message           (GET)
    /plants/<p_uuid>/responsible       (GET) 
    /plants/<p_uuid>/sensor            (GET)
    /plants/<p_uuid>/sensor/<s_uuid>   (GET)
    /plants/<p_uuid>/status            (GET)
    /responsibles                      (redirect to /persons - REST v3 artifact)
    /responsibles/<r_uuid>             (redirect to /persons/<r_uuid> - REST v3 artifact)
    /sensors                           (GET)
    /sensors/<s_uuid>                  (GET)
    

    As you can see from the now available endpoints, every object has only a fraction of the paths used before. Essentially every object now has two endpoints except one. The object that is the exception is the plant. This something is one of the more important objects used for saving a variety of different data.

    Another new feature is...

    Read more »

View all 2 project logs

  • 1
    Step 1

    gather all needed materials

  • 2
    Step 2

    print the pcbs

  • 3
    Step 3

    assemble pcbs

View all 10 instructions

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates