Answered questions

How do we uniquely identify a sensor?

For integrated sensors, it should be the compound key: “{brand}{external_id}”. For non-integrated sensors it should be the “{UUID}”.

When irrigating are we aiming for field capacity or something else?

In general, something else. Field capacity will promote disease or fungus growth with many crops. There is a “goldilocks” zone above crop stress (where yields are permanently impacted) and below field capacity. Oftentimes, that goldilocks down is described in percentage of “plant available water” which is field capacity - permanent wilting point. For example, with dry peas we’ll aim for 60% - 80% of “plant available water”.

How does LiteFarm get a non-expiring token from the Ensemble API?

Ensemble access tokens will expire. There is a refresh token for use when this happens.

Ultimately up to ESCI and the owner of https://lite-farm.atlassian.net/browse/LF-2483 .

Will LiteFarm need a different token for each organization or will one token allow us to access multiple organizations?

Ensemble has confirmed that one set of credentials can have access to any number of organizations (farms in LiteFarm). As such, there will be 1 set of credentials used for all users in LiteFarm.

How do we link up sensor_reading_types with a depth via csv upload?

Each sensor will only have 1 depth. We may choose to display sensors with very similar lat / long and different depths as the same sensor via the UI - but they are different in terms of sensor reading types and readings.

What is the format for registering an organization with ESCI?

https://documenter.getpostman.com/view/18529342/UVXeqchj#b3a26ae9-be68-42a4-ac92-ca8025e7008c (see POST Create an organization)

• Authenticated users can create an organization.

  • "name" is the only required field

• The creator will automatically become the admin and member of organization

• Preferred UUID for organization can be optionally specified. Otherwise it will be autogenerated

• Returns an error if UUID incorrect or non-unique

What is the format for registering a callback address with ESCI?

https://documenter.getpostman.com/view/18529342/UVXeqchj#b3a26ae9-be68-42a4-ac92-ca8025e7008c (assumed to be POST Create organization webhook)

• Create webhook for organization

  • Will send a confirmation request in the form of an empty array to the url (with authorization if any) before being created

• Webhooks automatically send any organization data between current time and the webhook's last transmit time based on the webhook's frequency as long as it is active. Will send an empty array if no new data

• authorization_header is optional

• frequency is in minutes

• Errors

  • 400_BAD_REQUEST

    • Invalid json, incorrect url

    • received Response other than 200_OK from url during creation

    • Errors when trying to send confirmation request to the url

• Only organization admins can call

Do we need a different callback address for each organization or can the callback specify org as part of the hierarchy?

We will use a single callback address per integration partner, so there will be one for all organizations in ESCI communications. That address will identify the partner.

Does the callback only send what has happened since the last update? Is there a failsafe if a callback fails to communicate several rounds of data?

Yes, ESCI will keep track of what has been shared and only send updates.

What is the format for registering sensors with ESCI?

Below is a bit misleading since LiteFarm will primarily be claiming devices rather than registering them. Ensemble registers the sensor when it’s manufactured. Farmers (using LiteFarm) then claim the previously registered sensor for use on their farm. Regardless, the register endpoint is described below:

https://documenter.getpostman.com/view/18529342/UVXeqchj#b3a26ae9-be68-42a4-ac92-ca8025e7008c (assumed to be POST Add a new device)

• Adds device to cloud with the specified POST data:

  • part_number

  • hardware_version

  • Device ESID will automatically be generated and any device parameters will be created based on the DeviceType's default parameter list if it exists.

  • Any generated parameters will have a 1:1 calibration generated with it as well

  • If device is interfacer, sets configurable to TRUE, so users can modify the device with other APIs

  • Errors:

    • 400_BAD_REQUEST

      • Device type with part_number does not exist

      • Any fields missing

  • Only ESci admins can call

What depths are the sensors at (for this project)?

For Smart Irrigation V1 10, 20, 30, and 50cm. Duplicates at 10 and 30.

This may change (but isn’t likely to) for Smart Irrigation V2.

What data types can we have for sensor reading values?

• soil_water_content: Derived from water_potential and temperature

• water_potential: Sensed

• temperature: Sensed

What file formats do Zimmatic VRI modules accept in terms of irrigation prescriptions?

Current versions of the VRI module only accept .vri prescriptions (see this write-up for more details). FieldNET does not accept .vri files as an input, but rather exports them for use on the VRI module. FieldNET only accepts .kml files as inputs. There is another tool created by Lindsay called FieldMAP which can accept several different types of input files such as .shp and .kml. Current versions of FieldMAP generate .vri files as outputs. However, older versions of FieldMAP (which is what is being used on our project farm) can produce other formats - including .xml files. Our farmer, generates .xml files in FieldMAP and then uploads that .xml file directly to the VRI module on his pivot using a USB stick.

Can Zimmatic VRI modules be accessed remotely without using FieldNET?

No; you can only access them remotely via FieldNET.

How does a VRI pivot know how much water to put down for a given location?

See Irrigation prescriptions

Open questions

When viewing sensor readings should the default time range differ by sensor type? For example, 24 hours, 7 days, 30 days?

Do we need to persist history of the sensor location and attributes or is the current state sufficient?

How can you view retired sensors?

Could have something like a farm map history insight where you drag a timeline and locations appear / disappear. Probably should be closer to an archive than a traditional retire so that the reading history is still available. What’s the best way to do this?

What are the valid types of sensor (reading) types to start with?

For the

• soil_water_content (derived)

• soil_water_potential

• temperature

Mark says that parameter_number is dynamic from device to device. Will need to develop a strategy to make this consistent.

How does ensemble tie a reading to a parameter when posting new sensor readings?

It appears to be based on “parameter_number”. Need to explore what exactly this means to ESCI.

What is the format for claiming sensors with ESCI?