Smart Irrigation V2

Refactor sensor architecture

As a user I want to be able to look over historical data for any period where my sensors where gathering in field data so that I can learn from the data that I’ve generated

Areas to investigate here:

• 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?

• Move from static to dynamic sensor reading view window

• Others?

Crop data

As a farmer growing a particular crop I want LiteFarm to know the water needs for that crop by crop stage so that the irrigation prescription recommendations are in line with optimizing my crop

We will need to collect at least the following data for all crops identified in the diagram from https://lite-farm.atlassian.net/wiki/spaces/LITEFARM/pages/1487175681:

• Crop stage data (based on days from planting)

• Crop specific ET curves

Also see Smart irrigation | V2.

Weather data

As a farmer using autonomous irrigation where weather is the primary input into irrigation decisions I want weather data to be recent and hyperlocal so that the irrigation prescription recommendations are in line with optimizing my crop

Also see the diagram from Smart irrigation | V2.

This is an example of weather data from https://lite-farm.atlassian.net/wiki/spaces/LITEFARM/pages/1180499971 which took place in Enchant, AB.

Additional pivot support

As a farmer using a particular brand of pivot I want to know that LiteFarm autonomous irrigation prescriptions support my pivot type before adopting the software so that I don’t waste my time

Instructions for converting irrigation prescriptions to “.vri” to support Zimmatic pivots can be found here: Working with VRI files

However, this will need to be expanded to support additional pivot brands once the sites have been defined here: https://lite-farm.atlassian.net/wiki/spaces/LITEFARM/pages/1487175681

How does LiteFarm begin to support layers?

See Layers V1.0.

For sensors at the same lat / long but with multiple depths, how should we be visualizing those depths?

See Sensor Q&A | How do we link up sensor_reading_types with a depth via csv upload? . Suggest overlaying different depths on the same x-axis (time) so you can see the impact of irrigation events at different depths.

Should we refactor “temperature” to be “soil_temperature”?

Right now “temperature” is a partner_reading_type. However, this actually indicates “soil temperature” and may become confusing as we begin to use air temperature as well.