Project Overview

The Outdoor Environmental Sensor Project is a low-power autonomous system designed to monitor temperature, relative humidity, and atmospheric pressure in an outdoor environment. The system prioritizes energy efficiency, reliability, and long-term autonomy, making it suitable for continuous operation using standard AA batteries.

An ESP32 microcontroller collects data from a BME280 sensor, transmits the measurements via Wi-Fi to a Raspberry Pi, and immediately enters deep sleep mode to minimize power consumption. The Raspberry Pi stores, processes, and exposes the data through a web-based interface. You can see here: https://joelbonifacio.dynip.sapo.pt/electro6.1.html

Hardware Components

• DFRobot FireBeetle 2 ESP32-C6 Module;
• DFRobot SEN0236 - BME280 - Environmental Sensor (Connected via SPI mode);
• Raspberry Pi 4;
• 3 × AA Alkaline Batteries (2500 mAh);
• Outdoor weather-resistant enclosure for testing.

BME280 Technical Specifications

ESP32 ↔ BME280 Wiring Diagram (SPI)

Here is the schematic of the circuit.

FireBeetle 2 ESP32-C6 Firmware (Low Power Mode + SPI)

// ----- CONFIGURAÇÃO HARDWARE -----
// O fio VCC do sensor BME280 liga AQUI, e não nos 3.3V fixos.
// Isto permite desligar o sensor e o LED vermelho completamente.

#define SENSOR_POWER_PIN 14 
#define BME_CS 21 
#define SPI_SCK 18
#define SPI_MISO 19
#define SPI_MOSI 23

// Battery voltage: built-in ADC on pin 0 (onboard resistive divider)
#define BATTERY_ADC_PIN 0

Adafruit_BME280 bme(BME_CS);

// ----- CONFIGURAÇÃO WIFI -----
const char* ssid = "...";
const char* password = "...";
const char* serverURL = "https://.../api/rua/sensor";
const char* serverBatchURL = "https://.../api/rua/sensor/batch";

// ----- SLEEP -----
const uint64_t SLEEP_MINUTES = 15;
const uint64_t SLEEP_MICROS = SLEEP_MINUTES * 60ULL * 1000000ULL;

void setup() {
  // ------------------------------------------------
  // STEP 1: POWER ON AND READ SENSOR (Wi-Fi still off!)
  // ------------------------------------------------
  pinMode(SENSOR_POWER_PIN, OUTPUT);
  digitalWrite(SENSOR_POWER_PIN, HIGH);
  delay(10);

  SPI.begin(SPI_SCK, SPI_MISO, SPI_MOSI);
  
  if (!bme.begin(BME_CS)) {
    goToSleep();
  }

  bme.setSampling(Adafruit_BME280::MODE_FORCED, ...);
  bme.takeForcedMeasurement();
  float temp = bme.readTemperature();
  float hum = bme.readHumidity();
  float pres = bme.readPressure() / 100.0F;
  float volt = (analogReadMilliVolts(BATTERY_ADC_PIN) * 2) / 1000.0F;

  // *** CRITICAL POWER SAVING ***
  digitalWrite(SENSOR_POWER_PIN, LOW); 
  
  // ------------------------------------------------
  // STEP 2: CONNECT WI-FI (DHCP, router-reserved IP)
  // ------------------------------------------------
  WiFi.mode(WIFI_STA);
  WiFi.persistent(false);   // avoid rewriting credentials to flash every cycle
  WiFi.begin(ssid, password);
  // ... timeout 10s ...

  if (WiFi.status() == WL_CONNECTED) {
    // ------------------------------------------------
    // STEP 3: SEND DATA (HTTPS with WiFiClientSecure)
    // ------------------------------------------------
    // ... build JSON {temperature, humidity, pressure, voltage} ...
    int response = http.POST(json);

    if (response == 200) {
      flushQueue();   // send any offline backlog accumulated in LittleFS
    }
  }

  if (!sentLive) {
    // Wi-Fi down or server error -> queue reading for later (see Offline Data Buffering)
    time_t now = resolveCurrentEpoch(wifiOk, true);  // NTP sync on demand
    queueReading(now, temp, hum, pres, volt);
  }

  // ------------------------------------------------
  // STEP 4: DEEP SLEEP
  // ------------------------------------------------
  goToSleep();
}

void goToSleep() {
  WiFi.disconnect(true);
  WiFi.mode(WIFI_OFF);
  esp_sleep_enable_timer_wakeup(SLEEP_MICROS);
  esp_deep_sleep_start();
}

void loop() {
  // Not needed — the ESP32 wakes from deep sleep by restarting setup()
}

Python Services on Raspberry Pi

• Flask API for data ingestion (/api/rua/sensor for real-time readings, /api/rua/sensor/batch for offline backlog — see Offline Data Buffering below);
• SQLite database logger;
• Data aggregation, statistics, pressure tendency analysis, and battery life forecasting.

Apache Reverse Proxy (electro6.conf)

Apache is configured as a reverse proxy to forward /api/rua requests to the internal Flask. This covers all sub-routes under that prefix, including the real-time ingestion endpoint (/api/rua/sensor), the batch endpoint for offline backlog (/api/rua/sensor/batch), and the read-only data endpoints consumed by the frontend. This isolates backend services and provides clean, stable URLs.

Offline Data Buffering (LittleFS Persistent Queue)

In the initial version of this project, any reading taken while the Raspberry Pi was unreachable — whether due to a server restart, a network outage, or scheduled maintenance — was silently lost. For an outdoor sensor that may need to operate autonomously for extended periods, this is unacceptable: the most interesting weather data often coincides with the conditions most likely to cause connectivity issues.

The firmware now implements a persistent offline queue using the ESP32's onboard flash memory via LittleFS. When a reading cannot be delivered (either because Wi-Fi is unavailable or the server does not respond with HTTP 200), it is appended to a CSV file stored on flash along with its estimated timestamp. The queue can hold up to 672 readings (~1 week) at the 15-minute interval. Once connectivity is restored and a live reading is successfully acknowledged by the server, the entire backlog is flushed in a single HTTP POST to a dedicated batch endpoint (/api/rua/sensor/batch), and the queue file is deleted only after the server confirms receipt. If the batch delivery itself fails, the file remains intact and retransmission is attempted on the next cycle — no data is ever partially sent or silently discarded.

Timestamping offline readings required solving a non-trivial problem: the ESP32 has no battery-backed real-time clock, so it only knows the current time when it can reach an NTP server. In earlier iterations, the firmware estimated timestamps by counting deep-sleep cycles and multiplying by the nominal 15-minute interval — but the ESP32-C6's default 150 kHz RC oscillator has a frequency tolerance of approximately ±5%, which translates to roughly 9 minutes of drift over 3 hours. The final implementation avoids this entirely: whenever a reading needs to be queued and Wi-Fi is available, the firmware performs an on-demand NTP synchronization at that exact moment, producing an accurate timestamp with no accumulated drift. The internal RTC clock (which does persist across deep-sleep resets) is used as a fallback only when Wi-Fi itself is unavailable — an uncommon scenario, since the most frequent failure mode is server downtime with Wi-Fi still operational.

On the backend, the Flask API exposes a /api/rua/sensor/batch endpoint that accepts an array of readings, each with its own device-side timestamp, and inserts them into the same SQLite table used by real-time readings. Because all existing queries (charts, statistics, pressure tendency, battery forecast) use ORDER BY timestamp rather than insertion order, the late-arriving historical data integrates seamlessly — no frontend changes were required.

// Offline queue — partial firmware excerpt (simplified)

#define QUEUE_FILE "/queue.csv"
const int MAX_QUEUE_ENTRIES = 672;  // ~1 week at 15 min intervals

// Called when the live POST fails (Wi-Fi down or server error)
void queueReading(time_t epoch, float temp, float hum, float pres, float volt) {
  if (epoch == 0) return;  // no valid time reference yet
  File f = LittleFS.open(QUEUE_FILE, "a");
  f.printf("%lu,%.2f,%.2f,%.2f,%.3f\n", (unsigned long)epoch, temp, hum, pres, volt);
  f.close();
}

// Called after a successful live POST — sends the entire backlog at once
void flushQueue() {
  if (!LittleFS.exists(QUEUE_FILE)) return;
  // ... reads all lines, builds a JSON array, POSTs to /api/rua/sensor/batch ...
  // ... deletes the file ONLY after HTTP 200 confirmation ...
}

Power Consumption Analysis

Empirical Battery Life Validation

But why using 3 AA Batteries Instead of 4 Batteries AA?

Using 3 AA alkaline batteries provide an initial voltage of approximately 4.5 V, which is safely handled by the ESP32 onboard regulator. Using 4 batteries would raise the voltage to 6V, exceeding the regulator's optimal input range and increasing thermal dissipation.

SPI Was Mandatory Instead of I²C

During development, the use of I²C combined with active Wi-Fi on the ESP32 caused intermittent communication failures and bus lockups. Migrating the BME280 to SPI provided a dedicated, synchronous communication channel, fully eliminating the instability.

Outdoor Weather-Resistant Enclosure For Testing

I bought a waterproof box and made some minor modifications to adapt it to this project. It has two large holes in the bottom for ventilation, and right above them is the BME280 sensor. The goal is to prevent water from entering, especially since it's windy and raining heavily here (which is quite common), but at the same time, to avoid interfering with the sensor readings. I also put a very fine green mesh to prevent insects from getting in and covering the sensor hole. Now it will be screwed to the outside wall of the house.

P.S. - It will not be exposed directly to sun/rain.

This is the final result:

Vented Radiation Shield Implementation

You can see more in the Solidworks section.