...
Will LiteFarm need a different token for each organization or will one token allow us to access multiple organizations?
Ideally one token per farm, but may have one universal instead. To verify with ESCI team.
What are the valid types of sensor (reading) types to start with?
soil_water_content (derived)
soil_water_potential
temperature
...
parameter
...
parameter_number(s)
...
explanation
...
soil_water_content
...
Ask Morten!
...
soil_water_potential
...
Ask Morten!
...
temperature
...
Ask Morten!
Mark says that parameter_number is dynamic from device to device. Will need to develop a strategy to make this consistentEnsemble 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.
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 registering an organization with ESCI?
...
Do we need a different callback address for each organization or can the callback specify org as part of the hierarchy?
Each farm would have it’s own callback address with the farm_id or organization_id provided as one of the inputs.
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?
...
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)
...
10, 20, 30, and 50cm. Duplicates at 10 and 30.
Are there any attributes above that are missing?
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?
It depends:
Per Nathan Stamp: He generates the xml file using FieldMAP. He then uploads that xml format directly to the VRI module on his pivot using a USB stick. He is NOT using FieldNet. FieldMAP can accept several types of files as inputs, such as .shp and .kml.
Per Dillon Clayton: the VRI module only accepts .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.
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?
Open questions
What are the valid types of sensor (reading) types to start with?
For the
soil_water_content (derived)
soil_water_potential
temperature
parameter | parameter_number(s) | explanation |
|---|---|---|
soil_water_content | Ask Morten! | |
soil_water_potential | Ask Morten! | |
temperature | Ask Morten! |
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.
| Code Block |
|---|
"node_esid":"123",
"sensor_data":[
{
"sensor_esid":"124",
"sensor_values":[
{
"parameter_number":1,
"raw_value":2.910,
"timestamp":"2022-01-10T17:41:00+0800"
},
{
"parameter_number":1,
"raw_value":2.110,
"timestamp":"2022-01-10T17:41:00+0800"
},
{
"parameter_number":2,
"raw_value":0.001938,
"timestamp":"2022-01-10T17:41:00+0800"
}
]
... |