Version | Owner / Editor | Last Modified date |
1 | Divya Chayanam | 18 22 Oct 2024 |
|
|
|
|
|
|
|
|
|
Introduction
...
The solution will be implemented in the following components and sub-components. The division and sub-division is done from a user perspective:
Module -1 Sensors
As a farmer and Litefarm user, I want to be able to add, view and manage sensors in my farm on the app. For this MVP, we will be supporting only sensors by the manufacturer Ensemble Scientific.
1. Study & Refactor existing sensor architecture
Research must be done on previous implementation for relevance and soundness of code. Adding notes from previous document:
Review architecture and refactor as needed
Make queries against time series data more performant
Automated migration of data out of Postgres after a certain amount of time?
2. Add / Create sensors on map view –
Flow to add multiple sensors through the UI: A single point on the map can have an array of sensors, all with same location, but different depths. Sensors can be added only on already created farms. An array of sensors can be represented by a single point.
User flow to upload an array or batch of sensors
Create sensor attributes in the DB
3. View, edit & delete sensors
See essential sensor details by clicking on a sensor point on the map: Shows if sensor is active / inactive, soil water potential, label and depths of sensors
Flow to edit the location, label and depths of a sensor array. It’s not possible to move just one sensor from an array of sensors. Can possibly make use of the create sensor flow and allow editable fields.
Flow to retire/delete a single or array of sensors.
4. Capture sensor readings
Capture sensor readings in database via webhook. Archive / delete readings older than 6 months.
Sub-component / Feature | UI details | Backend requirements | Jira issue link | |||||||||
a | Sensor refactoring |
| ||||||||||
b | Create multiple sensors from UI | Map view > add sensor > choose location > add details | See sensor attributes in the list above |
| |||||||||
c | Upload sensor CSV data from app | Map view > add sensor > upload via CSV | CSV template to upload to be available for download and re-upload |
c
| |||||||||
d | Sensor details quick view | Map view > click on sensor > see details (name, active/inactive, depth last soil moisture reading, soil temperature reading) & Edit & delete actions | sensor attributes, API to fetch sensor details, opportunity to cache? |
4
| |||||||||
e | View and edit sensor details | Map view > click on sensor > Edit flow > confirm? |
|
| |||||||||
f | Delete sensors | Map view > click on sensor > delete flow > confirm? |
|
| |||||||||
g | Capture & show sensor readings | Flow TBD - after deciding if it’s necessary to display readings | Capture sensor readings via ES webhook. |
| |||||||||
h | Error handling | Unable to fetch data: default error screen or snackbar and message Unable to perform requested action: error screen and message | TBD |
i | Efficiency | Limit sensor readings on app to a week to begin with | Based on volume and frequency on data, plan to move historic data out of DB |
Module -2 Center Pivots
A pivot is an farm machinery or equipment used for irrigation in large scale farms. As a farm manager/technician and Litefarm user, I want to be able to add, view and manage pivots in my farm on the app. Some field notes on pivots from previous implementation.
...
A farm can have only one pivot. It is assumed that a particular area of the farm is never irrigated by more than one pivot. As a rare scenario, for very large farms, there can be multiple pivots. In such cases, each pivot irrigated area becomes a separate “field” or “farm” and must be created as such in the Litefarm.
A pivot-irrigated farm for MVP1 will have one homogenous crop throughout.
Farm must be created first and then only a pivot can be added
1. Add / Create pivots on map –
Add pivot: Create a pivot on the map, on an existing farm.
Create pivot attributes in the DB
2. View, edit & retire pivots
See essential pivot details by clicking on the pivot on the map: Shows if pivot is active / inactive, last irrigation prescription link (if available), else CTA to create one.
Edit & retire pivots - to verify if this is a necessary user action and plan to scope after talking to Lewis
3. Initiation / Generate Irrigation prescriptions
Generate prescription to have an additional visibility in the app, apart from the pivot on the map.
To generate this, there must be atleast one pivot, one active sensor and one crop plan added.
Irrigation prescription or a .vri file is a modified json that is understood by pivots. This will be created by Litefarm either when a user requests it, or when the sensor triggers the need for one.
This will also form the basis for the irrigated zones view on the map, described in next module.
The structure of the json could vary depending on the pivot manufacturer.
4. Irrigation prescriptions - Push & History
h) A newly generated irrigation prescription could show up in the notifications with CTA to confirm or ignore. Push prescription to pivot on confirmation. Delete prescriptions older than 24hours, notifications can remain without CTA
...
j) View an irrigation plan with zones - An irrigation plan shows the irrigated zones of the field for a single pivot. More detail in the next module.
S.No | Sub-component / Feature | UI Details | Backend Requirements | Jira link | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Create pivots / Add pivot to farm map | Map view > Add pivot Cannot add more than one pivot to a field | Create pivot attributes API to fetch pivot attributes |
| ||||||||
2 | View pivot | Map view > Click on pivot > basic pivot details (name, farm name, irrigated area, active/inactive) including CTA to generate irrigation prescription | same as above, opportunity to cache? |
| ||||||||
3 | Edit pivot | To be decided if needed | ||||||||||
4 | Delete pivot | To be decided if needed | ||||||||||
5 | Generate IP - user initiated | User-generated: Map > Pivot details > generate Show notification > approval TBD: Associate with irrigation task? |
| |||||||||
6 | Generate IP - automatic / trigger-based | Monitor sensor readings based on defined rules > generate IP > show notification > approval |
| |||||||||
7 | User defined settings / rules | Min & max values of soil water deficit (depends on crop, we will suggest to start with) Monitor time (hrs, 0 - 12, steps of 0.5 ) - Generate IP only if the soil water continues to stay below the threshold Checkbox - Do not create prescription at night Checkbox - do not create another prescription if there was a previously approved prescription within 24 hours Approval permissions - what roles can approve prescriptions | One or two parameters must be monitored in combination with the defined rules. |
| ||||||||
8 | Push prescription | Error snackbar if applicable | The .vri or equivalent file to be sent to pivot. Exactly what kind of integration this would be is to be figured out. Fall back in case of failure: Check for bluetooth / USB options? |
| ||||||||
9 | View last prescription | Give user the option to view IP on map. To include color grading and irrigation values per zone (in mm) | Creating the map zones using the algorithm |
| ||||||||
10 | IP history | Given that we are generating IP and the map beforehand, it might not be too difficult to maintain and show a history as well. Could limit the history to a month for starters and then have more options based on popularity of feature. |
|
Module - 3 Layers & Integrations
Layers are visual representations of data on the same map, usually simultaneously. An example would be satellite view / default / terrain view in Google maps.
...
Currently we show farm location, boundaries and structures in the map. This can be expanded to the following:
View soil layers on map
The map would give the user an idea of the type of soil that is present in their farm(s). A user can look at the map of the farm and see a visual representation of zones / areas categorized by type of soil.
SoilGrids API gives the data on type of soil and other soil data when a lat long is passed. To begin with, this will be system generated and we won’t accept user uploaded maps or zones.
View irrigation zones on map
The irrigation prescription typically is not readable by common apps and is not easily consummable. So the last executed irrigation prescription is made available on the map as irrigated zones so it gives users a user-friendly way of understanding how their area was irrigated.
This will be system generated and not user generated. Please refer to this document on how these zones can be generated. An example of how that would look like:
S.No | Sub-component / Feature | UI Details | Backend requirements | Jira link | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Layers architecture - general | Group or categorize layers for visibility, toggle for a group. Turned off by default | Grouping & visibility keys, API modification |
| ||||||||
2 | Soil layers - Soilgrids API integration & UI | Static soil layers map + legend | Static zones, can be constructed for active farms as a completely asynchronous job, cache once done? Frequency of update can be periodical or when a delete / create farm action happens Constructing zones - TBD |
| ||||||||
3 | Irrigation zones - map UI | Static for one irrigation prescription | Near real-time for the latest irrigation prescription. |
How to create these zones - read doc | related to Jira story in module 2, point 9
| |||||||||||
4 | Zones algorithm - Theissen polygons | Algorithm to generate the polygons - static, will change only if number of sensors and their locations in a farm are changed |
| |||||||||
5 | Weather API integration | Weather predicted today to next 7 days. Show where? | No requirement to store past weather data |
Open Questions
Can/should users be able to edit an irrigation prescription?
How much of an area is represented by a sensor? - answered in irrigation zones in module-3 layers
How do a sensor and a pivot understand a field mapping? Is it configured at the beginning? - also answered in irrigation zones in module-3 layers
How exactly do we integrate with a pivot?
Possible error scenarios to be thought through in this entire journey.
How to show soil types for multiple depths in layers? How much of this information is relevant to the user?
We could recommend min and max values for the 10 crops and give a guidance around that for a user to choose? Or this common knowledge. Check 6,7 with Michelle
Are the user settings / rules we defined fine enough to prevent over and under watering? Double check!