Final report from the farm:
Our idea:
Building low cost soil moisture sensory system for farmers facing drought with low cost sensors (<$10) and gateways to easily scale up if necessary.
Demo from the farm:
An overview of what happened:
- Prototyping of the sensor nodes using different types of boards: NanoESP, Arduino Pro Mini, ESP8266: Part #1, #2 and #3
Prototype #1
Prototype #2 - We decided to use the ESP8266 (12-F) board and dived deeper into saving power: Part #1 and #2
- Researched solar and battery infrastructures: Part #1 and #2
- Planed and implemented our main hub (Raspberry Pi with Eclipse Mosquitto and ioBroker gateway): Part #1, #2, #3 and #4
- The main hub and the nodes are ready to leave the building: Part #1 and #2
Lessons learned:
- Building low cost sensory with development boards is easy.
- Building a reliable solar battery power infrastructure is not. Especially when using deepsleep on ESP8266. Good power regulation to avoid getting stuck in a boot loop is very important.
- Raspberry Pi (B+) might not be the best choice as a remote (with no power supply) gateway due to its power consumption. However we are not sure that a Raspberry Pi Zero would be able to handle the (current) load. The 2G/3G and Wifi USB stick are also very power thirsty.
- Power on hygrometers should be turned off when no reading occurs. The sensor end corrode much quicker otherwise. The end of the sensor should be easily replaceable by the farmer. Furthermore, they should be offered in different length as water level might vary with different types of plants.
- We would have liked to integrate automatic updates of the air (OTA) for our IoT devices firmware to make them more responsive to current and forecasted weather information (i.e. reducing interval of data being sent with bad light intensity to save power).
- After 4 days of intensive testing our mobile data consumption is at about 12 MB
Final report from the cloud:
Our backend contains 4 components/services, whenever an event from the farm or a command from the cloud is published, it reaches the controller service through an MQTT broker (IBM IoT platform in this case), the controller then process the event by adding the necessary information to the event such as the user and farm information to the event payload then invoke twoOpenWhisk actions. The first action will store the event/command in the historical database (Cassandra) for analytic purposes. The second action is the main action which will determine if a watering command needs to be sent to the farm or not. The watering action uses the active rule of the farm which is a set of conditions (lessThan, greaterThan, Equals, or ignore) for all the data either coming from the farm (sensor events) or the data collected in the cloud (currently weather data) and have a decision whether to water the farm or not. The rule can be created by the farmer using the farmer web application and can activate any rule he wants for his farms.
The other service is the Enricher, this component enriches the farms with more information from third-party services such as the OpenWeather API, this will allow having better watering decision.
The last component is the API, we offer different API endpoints to interact with the system as well as to get analytics and insights such as the last events and commands in a farm.
The following architecture, is an overall overview of our solution:
Farmer demo application :
Controller Service
As soon as the event are emitted, it goes directly using MQTT to IBM IoT platform. Then the controller service receive these events and process them and invoke both the watering and the historian actions in OpenWhisk. Besides that, Any command that generated by the watering action will also be received by the controller and it will invoke the historian action to store this command in the historical database.Enricher Service
This service is the contact point with the third-party services, for now, we are using the OpenWeather API to provide insights over the weather forecasting to support the decision of watering the farms. However in the future, we could enrich the farm data with soil or plant information.API Service
We offer different API endpoints to interact and get analytics and insight information of the different entities in the system. The API is used mainly by the farmer web application that was built using node-red. The API service has the below endpoints:Devices API
This API endpoint allow different clients to interact with the system by creating, updating, listing and deleting devices as well as retrieving devices by user or farm Ids.Farms API
Same way to interact with devices, we offer an API to interact with farms by creating, adding and deleting farms as well as retrieving farms by userId.Rules API
Adding, updating, deleting, listing and retrieving rules by userId are also offered to interact with the rules.Users API
Above that, we offer also endpoints to interact with the users, adding, updating, listing, deleting and retrieving users by their names.Historical API
This endpoint allow clients to access our historical database and have analytics and insights information based on the events and commands.Farmer Web Application
Open Technologies Used:
MQTT:
We use MQTT as communication medium between the backend components and the fields nodes.
Apache OpenWhisk:
OpenWhisk is an open source serverless cloud platform that execute code and run containers in response to events or direct invocation. We are using OpenWhisk to handle the large number of events in a scalable manner. In our solution, till moment, we have two components hosted on Bluemix OpenWhisk, the watering action and the historical action.Docker Containers:
Some of the components are deployed as a container, such as cassandra and mongoDB which are deployed on the cloud in containers.
Apache Cassandra:
Used as a historical database since it is powerful in time series data. We use it to store all events and commands generated by the system.
MongoDB:
MongoDB is our operational database, where we store the entities used and generated in the system, such as the farms and users information.
NodeRED:
We used NodeRED to build the dashboard to allow farmers to interact with the system in a better way.
OpenWeather :
Lessons learned :
1- Creating a smart service that decides when watering is required based on many different information from sensors in the farm and extra information collected in the cloud, is not an easy task. Currently we are allowing the farmer to decide what rule he wants to create around this data, however in the future, I think we need to use some cognitive services with machine learning capabilities to be able to provide the farmer with some smart rules that he can activate for his farm.
2- Using server-less architecture such as OpenWhisk was a good idea for our use case since we are sending the data from the farm not so frequently (once a day is enough) and this means we execute a watering action only few times which reduce our cost since we don't have to pay for the server runtime all day but only pay for what we execute. Cost is very important factor for our use case.
3- Since our solution is intended to be used by development countries, having internet connection up and running is not always the case. This means we need to provide some kind of edge solution that can work offline until the internet connection is working.
2- Using server-less architecture such as OpenWhisk was a good idea for our use case since we are sending the data from the farm not so frequently (once a day is enough) and this means we execute a watering action only few times which reduce our cost since we don't have to pay for the server runtime all day but only pay for what we execute. Cost is very important factor for our use case.
3- Since our solution is intended to be used by development countries, having internet connection up and running is not always the case. This means we need to provide some kind of edge solution that can work offline until the internet connection is working.
No comments:
Post a Comment