| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...
Summary
...
Description
...
Fix Version
Sensor model work
...
Build out database to support tables for:
Sensors (location)
Sensor reading types (see ESCI doc)
Sensor readings
...
MVP
Bulk or individual?
...
v2
Upload screen with template and front-end validation
...
v1
Bulk sensor creation and outcome splash
...
v1
Proposed CSV upload format
...
Sensor
...
ESID
...
Name
...
Lat_long
...
Reading_types
...
Depth
...
Brand
Proposed CSV upload format
This is a proposed format for bulk uploading sensors. To be vetted and verified with Ensemble folks.
Sensor | ESID | Name | Lat_long | Reading_types | Depth | Brand | Model | Part_number | hardware_version |
|---|---|---|---|---|---|---|---|---|---|
Description | The sensor’s unique external id. This is the identity that will be used to register the sensor with external services and receive readings associated with this sensor. | How the sensor will be labelled in LiteFarm. | The latitude and longitude for the sensor, comma separated. | Comma delimited list of sensor reading types. Valid values are:
| Assumed to be in cm, only 1 depth per sensor. For this project depths can be 10, 20, 30, 50. | The brand of sensor. | The model of sensor. | ||
Required? | Required | Required | Required | Required | Required | Optional | Optional | Optional | Optional |
Example | WERKTX | “Sensor 1” | -31.362442522541148, -64.21047544487595 | soil_water_content, soil_water_potential, temperature | 10 | “Ensemble Scientific” | “Model ABC” | “ESA-12345” | “B” |
Notes | Where the sensor has been placed in the ground. | Will need to be grouped on the map. This should be default behaviour since sensors are points. | ESCI Add device will fail without this attribute. | ESCI Add device will fail without this attribute. |
...
Definition of a sensor: A device with a single id, name, lat / long, and depth. Must have at least one reading parameter, but may have several. Optionally has a brand and model. When uploading, Ensemble requires a part_number and hardware_version to register it with their service.
When uploading, LiteFarm needs to perform validation on the uploaded content.
...
Validation should be performed at least via the API and potentially through the UI as well.
...
Architectural guidance
Please take this as guidance rather than instruction. The following tables seem to make sense to allow users to document sensors and to integrate them with those external services.
...
Probably manually enter this into an “integrations” table to similar to how certifiers have a surveystack link. Ultimately up to ESCI and the owner of LF-2483.
Will LiteFarm need a different token for each organization or will one token allow us to access multiple organizations?
For MortenIdeally 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?
...
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.
...
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?
...
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
Requirements
Summary | Description | Fix Version |
|---|---|---|
Sensor model work | Build out database to support tables for:
| MVP |
Bulk or individual? | v2 | |
Upload screen with template and front-end validation | v1 | |
Bulk sensor creation and outcome splash | v1 |