FarmGuard Weather AI

Prototype Agricultural Weather Intelligence Dashboard

1. Project Overview

This prototype is a lightweight, browser-based intelligence dashboard designed for agricultural operations. It ingests hyperlocal environmental telemetry from a distributed sensor network, processes it through a simple normalization pipeline, and correlates it with public meteorological datasets to derive actionable field recommendations.

Primary Purpose:
To transform raw sensor telemetry and third-party weather data into farmer-readable guidance — specifically daily irrigation demand, spray windows, atmospheric stress indicators, and soil health metrics.

Scope:
This is a functional proof-of-concept. It demonstrates end-to-end data flow from physical sensing hardware to rendered visualizations, but does not yet include production-grade authentication, multi-tenant isolation, or long-term historical analytics.

2. Tech Stack

Prototype - as web access and as well as android app/iOS

3. Data Collection Architecture

3.1 Sensor Hardware (Source X)

Field-deployed environmental stations are equipped with the following telemetry array:

• Soil moisture probe: Capacitance-based volumetric water content (%)
• Soil temperature sensor: Thermistor at 6-inch depth (deg F)
• Soil pore EC sensor: Electrical conductivity (dS/m)
• Ambient air sensors: Temperature, relative humidity, barometric pressure
• Rain gauge: Tipping bucket (inches accumulation)
• Anemometer: Wind speed and direction
• Solar radiation / UV sensor

All sensors are polled by a microcontroller at 15-minute intervals. The readings are packetized into a compact binary payload and transmitted via LoRaWAN to a cellular-enabled gateway.

3.2 LoRaWAN Transmission Flow

Sensor Node → LoRaWAN Gateway → Network Server → HTTP Endpoint

The payload is intentionally small to respect LoRaWAN duty-cycle constraints:

[SoilMoisture: 2 bytes] [SoilTemp: 2 bytes] [PoreEC: 2 bytes]
[AirTemp: 2 bytes] [Humidity: 1 byte] [Rain: 2 bytes]
[WindSpeed: 1 byte] [WindDir: 1 byte] [Battery: 1 byte]

At the network server, the payload is decoded from Base64 and forwarded as a JSON POST to the ingestion endpoint.

3.3 Ingestion Endpoint

The backend exposes a simple REST receiver:

POST /api/v1/telemetry
Content-Type: application/json

Example payload:

{
  "node_id": "WS_001",
  "zone_id": "Zone 1",
  "latitude": 36.757351,
  "longitude": -120.195309,
  "timestamp": "2026-06-25T07:15:00Z",
  "readings": {
    "soil_moisture_pct": 10.21,
    "soil_temp_f": 70.99,
    "pore_ec_ds_m": 0.06,
    "air_temp_f": 74.5,
    "humidity_pct": 74.07,
    "rain_daily_in": 0.00,
    "wind_speed_mph": 1.18,
    "wind_dir_deg": 245,
    "battery_v": 3.00
  }
}

4. Data Storage & Schema

Telemetry is stored in a relational schema optimized for time-series insertions.

Core Table: telemetry_readings

CREATE TABLE telemetry_readings (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  node_id TEXT NOT NULL,
  zone_id TEXT NOT NULL,
  latitude REAL,
  longitude REAL,
  recorded_at DATETIME NOT NULL,
  soil_moisture_pct REAL,
  soil_temp_f REAL,
  pore_ec_ds_m REAL,
  air_temp_f REAL,
  humidity_pct REAL,
  rain_daily_in REAL,
  wind_speed_mph REAL,
  wind_dir_deg REAL,
  battery_v REAL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_telemetry_zone_time ON telemetry_readings(zone_id, recorded_at);

Table: forecast_cache

Public weather forecast responses are cached to reduce API calls and enable offline dashboard rendering.

CREATE TABLE forecast_cache (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  zone_id TEXT NOT NULL,
  latitude REAL,
  longitude REAL,
  forecast_date DATE NOT NULL,
  temp_min_f REAL,
  temp_max_f REAL,
  et0_in REAL,
  rain_in REAL,
  wind_max_mph REAL,
  humidity_avg_pct REAL,
  fetched_at DATETIME NOT NULL,
  UNIQUE(zone_id, forecast_date)
);

5. Data Processing Pipeline

5.1 Normalization

Raw readings are normalized to consistent units before any derived computation:

• All temperatures stored as Fahrenheit
• Rainfall as inches (cumulative per 24-hour window)
• Wind speed as mph
• Soil moisture as volumetric percent

5.2 Derived Metrics

The pipeline computes several derived values per zone:

Water Demand (ET deficit)

// Simple crop-water-demand approximation
const waterDemand = Math.max((et0 - rain), 0);

Where et0 is reference evapotranspiration retrieved from the public weather API.

Vapor Pressure Deficit (VPD) - Atmospheric Stress

function calculateVPD(airTempF, humidityPct) {
  const airTempC = (airTempF - 32) * 5 / 9;
  const saturationVP = 0.6108 * Math.exp((17.27 * airTempC) / (airTempC + 237.3));
  const actualVP = saturationVP * (humidityPct / 100);
  return saturationVP - actualVP; // kPa
}

High VPD indicates atmospheric stress demanding higher irrigation.

Spray Window Suitability

function isSpraySuitable(windMaxMph, rainIn, nextRainIn) {
  return windMaxMph < 10 && rainIn === 0 && nextRainIn === 0;
}

5.3 Aggregation Scheduler

A lightweight cron task runs every 6 hours to:

1. Fetch latest 24h of sensor telemetry per zone.
2. Compute rolling averages and daily totals.
3. Pull fresh 5-day forecast from the external API.
4. Write derived metrics to a daily_summary table.

6. Correlation with NOAA / Public Meteorology

The prototype does not ingest NOAA data directly. Instead, it uses Open-Meteo, which is a public aggregation service that normalizes multiple global meteorological inputs including NOAA GFS (Global Forecast System), ECMWF, and regional models.

6.1 Why This Indirection?

• NOAA GFS requires GRIB2 decoding and large bandwidth; Open-Meteo provides a lightweight JSON REST layer.
• It handles spatial interpolation automatically for the provided lat/lon.
• It exposes agriculturally relevant parameters: ET0, soil temperature, humidity, precipitation probability.

6.2 Correlation Logic

The system correlates local sensor data with the regional model by computing deltas:

function correlationDelta(sensorReading, forecastValue) {
  return {
    tempDelta: sensorReading.air_temp_f - forecastValue.temp,
    rainDelta: sensorReading.rain_daily_in - forecastValue.rain,
    humidityDelta: sensorReading.humidity_pct - forecastValue.humidity,
    biasScore: computeBias(sensorReading, forecastValue)
  };
}

These deltas are not yet surfaced to the UI in the prototype, but they are stored in daily_summary for future calibration use.

6.3 NOAA GFS Reference

When reporting to agronomists or regulators, the system can reference the upstream model lineage:

• Primary upstream source: NOAA GFS (Global Forecast System) via Open-Meteo pipeline
• Resolution: 0.25 deg x 0.25 deg global grid
• Update frequency: 4 times daily (00Z, 06Z, 12Z, 18Z)

7. Frontend Dashboard

7.1 Component Architecture

Dashboard
├── Header
│   ├── Today's Date
│   └── Last Updated timestamp
├── Zone Selector
├── Today's Goal Card
│   ├── Irrigation recommendation
│   ├── Spray window status
│   └── Root zone summary
├── 5-Day Outlook
│   └── Rain / ET demand strip
├── Detail Charts
│   ├── Water Demand (5-day)
│   ├── Spray Window (24hr)
│   ├── Atmospheric VPD (daily)
│   ├── Root Moisture Profile
│   ├── Growth / GDD Cumulative
│   └── Health Index Score
└── Alert Panel

7.2 Critical Frontend Code: Forecast Labeling

One critical requirement was making the X-axis labels human-readable for farm operations. The shared formatter is:

// frontend/src/utils/forecastLabels.js
export function formatForecastLabel(date, index) {
  if (index === 0) return 'Today';
  if (index === 1) return 'Tomorrow';
  return new Date(date).toLocaleDateString('en-US', { month: 'short', day: 'numeric' });
}

Used in both the chart resolvers and the outlook strip.

7.3 Chart Resolvers

The chart system is resolver-based. Each chartKey maps to a function that transforms a zone object into Chart.js-compatible data:

const CHART_RESOLVERS = {
  'water-demand-5day': (zone) => ({
    labels: zone.forecast.map((d, index) => formatForecastLabel(d.date, index)),
    datasets: [{
      label: 'Water demand (in)',
      data: zone.forecast.map(d => Math.max((d.et0 || 0) - (d.rain || 0), 0)),
      borderColor: '#0f766e',
      backgroundColor: 'rgba(15,118,110,0.10)',
      fill: true,
      tension: 0.3
    }]
    // ... additional resolvers
  })
};

7.4 Date Display Pattern

The header separates two distinct temporal concepts:

const todayLabel = new Date().toLocaleDateString('en-US', {
  weekday: 'short',
  month: 'short',
  day: 'numeric',
  year: 'numeric'
});

// Render:
// Left: "Thu, Jun 25, 2026" - orientation for the farmer
// Right: "Last updated Jun 23, 7:15 AM" - data freshness

8. Forecast Data Format

The raw forecast from the upstream API is simplified into a flat array for frontend consumption:

[
  {
    date: '2026-06-25',
    rain: 0.24,
    et0: 0.31,
    windMax: 8.2,
    windMin: 1.1,
    tempMin: 58,
    tempMax: 86,
    humidity: 74,
    dewPoint: 52,
    uvIndex: 7
  },
  // ... Day 2 through Day 5
]

Critical rule: date is stored as an ISO string; all formatting is deferred to the UI layer.

9. Future Directions

9.1 Near-term (Prototype → Alpha)

• Real-time socket layer: Replace 6-hour cron polling with WebSocket pushes from the LoRaWAN network server.
• Historical trending: Render 30-day soil moisture and ET0 trend lines rather than point-in-time snapshots.
• Alerting: Push SMS/email alerts when VPD crosses crop-specific thresholds or soil moisture drops below refill points.
• NOAA direct ingestion: For operations requiring regulatory-grade audit trails, implement direct GRIB2 ingestion from NOAA NOMADS rather than the simplified API.

9.2 Medium-term (Alpha → Beta)

• Crop modeling integration: Feed water demand and GDD into simple crop growth models (e.g., ASCE standardized ET, CIMIS coefficients).
• Multi-tenant zoning: Support distinct ranches with RBAC and zone-level configuration.
• Mobile PWA: Add service worker, offline forecast caching, and field-friendly touch targets.
• Sensor calibration dashboard: Surface the sensor-vs-forecast delta scores to agronomists for hardware recalibration.

9.3 Long-term (Production)

• Machine learning pipeline: Train regression models on sensor + satellite + weather data to predict irrigation demand 7-14 days ahead with confidence intervals.
• Valley integration: API integration with irrigation valve controllers for semi-automated pivot scheduling.
• Regulatory reporting: Automated export of water usage and ET reports for state water board compliance.

10. Security & Data Integrity Notes

• LoRaWAN payload includes AES-128 encryption at the physical layer.
• The HTTP ingestion endpoint should implement basic API-key validation.
• Sensor battery voltage is included in every payload to flag hardware degradation before data loss.
• All timestamps are stored in UTC; localization happens only at the presentation layer.

11. Glossary