Inspiration

Flood warnings usually depend on cell networks and the internet, both of which floods can knock out. In the 26 August 2026 Bhote Koshi flood in Nepal, the upstream collapse happened at 08:37, but the first official alert didn’t arrive until 09:05. StormShield is designed to close that gap by delivering warnings that don’t rely on either network.

What it does

Sensor Nodes along the river measure water level, rainfall, soil moisture, and pressure, and share those readings with each other over a Reticulum mesh network. No internet is needed.

When a Registered Node sees the water rise 3 m or more in under a minute, the Hub sends out a signed Community Warning. Unregistered Nodes still appear on the map, but they’re never counted toward a warning, so a broken or spoofed sensor can’t set one off.

From there, each person’s phone works out when the wave will reach their own home, using river speeds that vary along each stretch of the river. It then picks the nearest open Shelter they can reach in time, or points them to higher ground if no shelter is close enough.

A few things we cared about getting right:

Privacy: Your household profile stays on your phone and is never sent to any Node. Transparency: The Flood Risk view explains why it shows each level, so you’re not just trusting a color. Clear sources: Official Alerts and community warnings are always kept visually separate, so nobody confuses one for the other. How we built it

The Node service is written in Python with FastAPI and runs on Raspberry Pis and laptops. Reticulum handles both message transport and signing. Every Node also serves the dashboard, which we built with React, TypeScript, and MapLibre, including 3D terrain.

To make the system work offline, we created a Cache Pack containing maps, elevation data, shelter locations, and routes. It downloads while you’re still online, so your evacuation plan is ready when the connection drops.

For hardware, we wired a breadboard to a Pi’s GPIO pins to drive the sensor readings. For the demo, we replay the real Bhote Koshi event and cut the internet partway through.

Challenges we ran into

Trusting a warning with no server. Without a central authority, how does a Node know a warning is real? We had every sender sign their messages, and each Node checks that signature against the Hub’s registry.

Getting arrival times right. Our first approach used a single fixed river speed. It predicted the wave would reach Syabrubesi in about 26 minutes, when the real arrival was closer to 12. That gap is the difference between a useful warning and a dangerous one, and it’s why we switched to per-reach speeds.

Keeping the 3D map smooth. Terrain plus animated layers is a lot to render, but we managed to hold 60 fps.

Accomplishments that we’re proud of The whole chain works end to end with the internet cut: surge detection, signed warning, arrival estimate, and evacuation plan. People in the audience can join the mesh from their own laptops during the demo. Every fact in the replay cites a source, and anything we had to reconstruct is clearly labeled. We have automated tests covering both the Node API and the dashboard. What we learned

Building offline-first changes almost every design decision. Trust, timing, and maps all normally lean on a server somewhere, and we had to rethink each one to work without it.

What’s next for StormShield

We want to replace the replay with real sensors in the field, connect valleys to each other over LoRa, and run a pilot with a district disaster management office.