Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/diarpicu2022-commits/backend-AgroPulse/llms.txt

Use this file to discover all available pages before exploring further.

The Readings API is the primary ingestion path for sensor measurements. Edge devices (ESP32 nodes, LoRa gateways, serial bridges) POST readings as they arrive; the dashboard and analytics services consume them via the GET endpoint. Every POST also triggers the GreenhouseMonitor observer pipeline, which runs anomaly detection against any active thresholds configured for the sensor.

​
Endpoints

MethodPathDescription
GET/api/readingsList recent readings with optional filters
POST/api/readingsIngest a new reading and trigger anomaly detection

​
GET /api/readings

Returns the most recent readings, sorted by timestamp descending. Results are always paginated — the default page size is 100 rows.

​
Query parameters

​
limit
number
default:"100"
Maximum number of readings to return. Results are ordered newest-first.
​
sensor
number
Filter readings to a specific sensor ID. Cannot be combined with greenhouseId — sensor takes precedence.
​
greenhouseId
number
Filter readings to all sensors that belong to this greenhouse. Ignored when sensor is also present.

​
Response

{
  "readings": [
    {
      "id": 42,
      "sensorId": 1,
      "sensorType": "TEMPERATURE",
      "value": 24.5,
      "greenhouseId": 3,
      "source": "ESP32_WIFI",
      "timestamp": "2024-06-01T14:32:00"
    }
  ]
}

​
curl examples

# 50 most recent readings
curl "http://localhost:8080/api/readings?limit=50"

# Readings for a specific sensor
curl "http://localhost:8080/api/readings?sensor=1&limit=200"

# All readings for a greenhouse
curl "http://localhost:8080/api/readings?greenhouseId=3"

​
POST /api/readings

Saves a sensor reading and immediately passes it to GreenhouseMonitor.processSensorReading(). The monitor checks active thresholds for the sensor and emits anomaly events when values fall outside configured bounds.
Auto-registration: when sensorId is 0 or omitted, and greenhouseId plus sensorType are both present, the API looks up an existing sensor by (greenhouseId, source, sensorType). If no match is found, a new sensor is created automatically with the name <TYPE> (auto) and active = true. The new sensor ID is then assigned to the reading before it is persisted. This allows ESP32 devices to submit readings without pre-registering their sensors.

​
Body parameters

​
sensorId
number
default:"0"
ID of the sensor that produced this reading. Set to 0 or omit to trigger auto-registration when greenhouseId and sensorType are present.
​
value
number
required
The measured value. Units are determined by sensorType (°C, %, lux, ppm, pH, m/s).
​
greenhouseId
number
ID of the greenhouse the reading originates from. Required for auto-registration.
​
source
string
default:"MANUAL"
Transport or origin of the reading. Common values: MANUAL, ESP32_WIFI, ESP32_LORA, ESP32_SERIAL.
​
sensorType
string
default:"TEMPERATURE"
Measurement type. Must be a valid SensorType enum value. Used during auto-registration and stored on the reading record. See the Sensors API for the full list of values.

​
Response fields

​
id
number
Auto-generated reading identifier.
​
sensorId
number
ID of the sensor that produced this reading. Populated automatically when auto-registration runs.
​
sensorType
string
SensorType enum value describing the measurement category.
​
value
number
The raw measurement value.
​
greenhouseId
number
ID of the originating greenhouse.
​
source
string
Transport identifier (MANUAL, ESP32_WIFI, ESP32_LORA, ESP32_SERIAL).
​
timestamp
string
ISO-8601 datetime set at ingestion time, e.g. "2024-06-01T14:32:00".

​
curl examples

curl -X POST http://localhost:8080/api/readings \
  -H "Content-Type: application/json" \
  -d '{
    "sensorId": 1,
    "value": 24.5,
    "greenhouseId": 3,
    "source": "ESP32_WIFI",
    "sensorType": "TEMPERATURE"
  }'

Build docs developers (and LLMs) love

Get started for freeTalk to us