Home Page
Map Dashboard Page

Inspiration

In 2026, Indonesia's wildfire season became a national crisis. Between January and July, 202,004 hectares burned, up 69% from 2025 (SiPongi), and economic and health losses for January to August were estimated at Rp39.29 to 123.1 trillion (CELIOS). From 18 August to 21 September, the Ministry of Health counted 174,694 acute respiratory infection cases, including 40,363 children under five.

Much of that fire is on peatland, and peat fire behaves in a dangerous way. Dry peat is a thermal insulator, so embers at 500 to 700 °C stay trapped under a layer of litter that feels cold. They creep along underground at about 1 to 10 cm per hour, can survive for weeks at around 20 cm depth, and come back to the surface with no smoke and no warning.

Firefighters told us the same story in different words: they cannot tell when a burned plot is truly safe, so they keep returning to the same place. When we looked for a tool that monitors temperature inside the peat continuously, we could not find a government platform that does it. That gap is PakuBara.

What it does

PakuBara is a command center for monitoring peatland, from before a fire starts to after the surface fire is out.

After the flames are gone, we put sensors in the ground. A "paku" (Indonesian for nail) is a 1-meter stake with three temperature sensors at 20, 50 and 100 cm. Gas posts measure carbon monoxide above ground. Data travels over LoRa, which works without a phone signal, to a field post and then to the cloud.

The system then answers three questions a coordinator actually asks:

Where are the embers, and how deep? A live Command Map shows every probe with its three depths and a status: Normal, Watch, Warning, Active, or Offline.
Where are they heading? From how fast neighboring probes are warming, PakuBara estimates the direction, speed, depth and time until embers reach the surface, plus a suggested water volume.
When is it safe? Every action is logged. An area is declared safe only after all points stay normal for a set number of days (3 to start).

To avoid false alarms, an alert is sent only when 2 of 3 signals agree: the temperature trend at the point, a neighboring probe also rising, and a nearby carbon monoxide reading. A generator exhaust that only raises CO does not wake anyone up.

When an alert fires, the field crew gets a WhatsApp message with a signed link to that single point. No login, valid for 24 hours, showing three-depth temperatures, spread direction and a navigation button. They acknowledge it and log what they did.

Before a fire starts, a Priority Alert map scores 1 km² cells to show where kits should go first. In this prototype that layer uses demo data.

Anyone can try the whole flow without hardware through the built-in Simulator, which runs four scenarios: a spreading ember, a false alarm, a dead battery, and a successful recovery.

How we built it

Hardware design. ESP32 boards with three DS18B20 sensors per probe (and an MQ-7 sensor on gas posts), LoRa SX1278 at 433 MHz, and 18650 batteries. A compact 18-byte packet with a CRC-16 keeps airtime and battery use low. Probes report every 5 minutes and switch to every minute when temperature jumps. A small Node.js bridge at the field post queues packets on disk when the internet drops and resends them later.

Web platform. Next.js 16 with React 19 and TypeScript, Tailwind CSS, MapLibre GL JS with deck.gl for the map, and Apache ECharts for the temperature charts. Supabase (Postgres, Auth, Realtime) with Prisma holds the data model, and Zod validates every incoming packet. Alerts go out through the Fonnte WhatsApp API. We also pull NASA FIRMS satellite hotspots and Open-Meteo wind data.

Detection logic. The 2-of-3 rule is plain code, not a black box, so a coordinator can explain it to a crew. Defaults are 60 °C or a rise of 3 °C per hour (from a regression over recent readings), a neighbor within 50 m rising at 1.5 °C per hour, and CO above 50 ppm. Thresholds can be changed in Settings.

Design. We designed for people standing in a burnt field with a phone: light and dark themes, large numbers, status colors always paired with shapes, and an alert page that works from a WhatsApp link.

We also used AI assistants as helpers for code suggestions, UI refactoring and drafting documents. The idea, requirements, system design and decisions are ours.

Challenges we ran into

Embers you cannot see. The first hard question was what to measure. Surface cameras and satellites miss smoldering under the litter, so we moved the sensing underground and used three depths to see where heat is concentrated.
False alarms. A single sensor crying wolf makes a crew stop trusting the system. The 2-of-3 rule came directly from that.
No signal in the field. Peatland rarely has mobile coverage, so we chose LoRa and built an offline queue into the bridge.
A 24-hour build sprint. We split scope into must-have and nice-to-have and shipped the full path from a sensor packet to a WhatsApp message first.
Demo without hardware. We built a simulator that drives the same code path as real data, so what judges see is the real pipeline reacting to synthetic readings.
Staying honest. We removed every number we could not source, labeled what is simulated, and wrote a "status and limits" section in our README instead of hiding it.
Engineering detail. A blocked native build tool forced us onto a different bundler, and a race condition made map markers disappear when data arrived before the map finished loading. Both are fixed.

Accomplishments that we're proud of

A working end-to-end flow: sensor packet in, status and spread prediction computed, WhatsApp alert out, action logged, area declared safe.
A full demo that runs without any hardware, with the same logic as the real pipeline.
Every figure on our landing page is sourced and credited next to the number.
A low-cost design: about Rp115,500 per probe in components.
A responsive light and dark interface that works on a phone, since crews open the alert link from WhatsApp.
Complete documentation: flow diagram, detection logic, architecture, repository structure and setup in the README.

What we learned

Peat fires are an information problem as much as a firefighting one: the cost is crews and water spent in the wrong place at the wrong time.
A rule people can explain beats a clever model nobody trusts, especially for the first version.
Designing for the field changes everything: no login for crews, big numbers, offline tolerance, and links that open from a chat app.
Being clear about what is simulated and what is not makes a prototype more credible, not less.
The physics of smoldering combustion in peat (low thermal conductivity, slow creeping spread) turned out to be a good fit for cheap sensors.

What's next for PakuBara

Bench and field tests. Calibrate thresholds and detection radius in a peat test bed, then run a pilot on a burned plot with a regional disaster agency, the national fire brigade (Manggala Agni) or a plantation crew.
Real storage and access control. Connect the main flow to the database and enforce per-role access (coordinator, responder, viewer) with row-level security.
A real risk model. Replace the demo Priority Alert grid with a trained model on human-activity traces such as canals, land clearing, access and burn history, and replace the simple spread physics with a model trained on field data.
Integration. Feed data to the national fire monitoring systems (SiPongi and SIPALAGA).
Offline PWA for crews and multi-organization support.
Beyond peat. Rent kits per season and extend to landfill fires, which also smolder underground.

Try it and read more

Live product (try it without hardware): pakubara.vercel.app. Open the Simulator to run the four demo scenarios.
Demo video (max 3 minutes): youtu.be/CvzNwmyDcrM
Pitch deck: Google Drive
Public GitHub repository: GerasimosAlpen/PakuBara
Full README, including the AI Use and Third-Party Declaration: README.md
Release tag for this submission (submission-24h): GitHub release