TrueFlood is my IoT flood-prediction project, with separate real-data and demo evaluation tracks. I built it around a safety-first approach: hard safety rules trigger alarms, while the Random Forest is advisory only.
My Wokwi simulation uses a wokwi-esp32-devkit-v1. Because the simulator has no soil-moisture model, I use potentiometers as stand-ins; descriptive part ids and on-canvas wokwi-text labels make screen recordings self-explanatory. The five sensing elements are hcsr04_water_level for water level (inverted distance), representing an ultrasonic or radar level sensor over 0–4.0 m on D5 / D18; pot_rainfall for 24-hour rainfall, representing a tipping-bucket rain gauge over 0–200 mm on D34 (ADC1); pot_soil_moisture for ground saturation, representing a capacitive probe over 0–100% on D35 (ADC1); bmp_pressure for barometric pressure and trend, representing a BMP280 / BME280 over 950–1040 hPa at I2C 0x77; and dht_humidity for humidity and temperature, using a real DHT22 rather than a proxy on D15. The local output stack is an LCD1602 at I2C 0x27, three LEDs on D25/D26/D27, and a buzzer on D14. Full wiring and per-state reproduction recipes are in trueflood flood early warning system.
I keep analog sensors on ADC1 (GPIO32–39), not ADC2: the ESP32 WiFi radio owns ADC2, and once WiFi is up, analogRead() on an ADC2 pin returns garbage. Since every node publishes over MQTT, ADC2 is off-limits for sensors; firmware/make_diagrams.py fails generation if a potentiometer is wired to ADC2. GPIO34/35 are input-only and have no internal pull-ups, which makes them suitable for potentiometers but not buttons. I removed the earlier flow-velocity potentiometer and turbidity photoresistor and retrained the model without those two features rather than feeding it silent 0.0 defaults. I also removed discharge_m3s: water level × flow velocity is undefined without velocity, and depth × velocity has units of m²/s, not m³/s. Barometric pressure trend replaced those features in Layer 1; it is a better predictor and the only signal able to fire before water level moves.
- ESP32 sensors, simulated in Wokwi, send data over MQTT to a Flask bridge.
For the real-data track, I evaluated predictions 2 days ahead using USGS gauge 05389500 and the NWS 16 ft flood stage.
On the real-data track, I got F1 0.9016 and recall 0.9912, versus 0.8519 F1 for a persistence baseline.
On the demo track, the Random Forest actually loses to persistence (0.46 vs 0.71 macro-F1), and I documented that openly rather than hiding it.
For TrueFlood alerts, I chose not to rely entirely on machine learning. On the demo dataset, the ML model didn't perform as well as simpler methods, so I used rule-based logic for critical alerts and kept ML for additional forecasting. This reflects my preference for reliable problem-solving over choosing a technology for its own sake, as described in how i think and make decisions. The source does not specify the comparison metrics, evaluation procedure, exact rules, forecasting methods, or performance beyond the demo dataset.
A simple rule-based approach was more reliable for critical alerts than leaning entirely on machine learning.
I keep the demo-track result distinct from the real-data result: the Random Forest performs worse than persistence on the demo track, so I report that comparison openly rather than treating the model as universally better.
The project has 38 pytest tests. GitHub Actions CI includes a train-and-gate step.
- The system fuses Open-Meteo weather data with sensor information.
- It uses SQLite, Prometheus metrics, Twilio alerts, and PSI drift monitoring.