I have an 18-acre mango and coconut farm split across three blocks. Two blocks have borewells and electricity. One has neither. The blocks aren’t contiguous, mobile coverage is patchy, and irrigation currently means physically moving between them to operate pumps and valves.
Then I came across the story about Bitchat being removed from India’s App Store. The politics around it are interesting, but what caught my attention was the technology: devices communicating directly with each other and relaying messages without depending on the internet.
Bitchat is an offline messaging app. Phones talk to nearby phones over Bluetooth and relay messages onward, with no internet, no mobile network, no phone number and no central server. Reports link the government’s attention to its use during recent protests and internet shutdowns.
This article isn’t about the politics. It’s about the technology underneath, because I’m building something in the same family for a very different purpose: irrigating my farm.
My problem
My farm is 18 acres of mango and coconut, split into three blocks:
| Block | Size | Borewell | Electricity |
|---|---|---|---|
| Block 1 - | 10 acres - | Yes | Yes |
| Block 2 - | 1.5 acres - | No | No |
| Block 3 - | 6.5 acres - | Yes | Yes |
Other people’s farms sit in between, so the blocks aren’t contiguous. Water comes from two borewells (in Blocks 1 and 3) through a full drip irrigation setup.
Today, managing that means walking or driving between blocks to start and stop pumps and open and close valves. Mobile coverage across the blocks is patchy, and a solution that depends on a SIM and a cloud server in every corner of the farm is fragile and carries recurring costs. I want irrigation I can control reliably, whether or not the internet is working.
Why I’m building it?
I’ve spent most of my career designing software systems. This project is an opportunity to take that thinking into the physical world — to build something where reliability isn’t measured by a dashboard, but by whether a valve actually opens when I need it to.
I could look for an off-the-shelf solution, but I also want to understand what is possible with low-power, local communication and a system designed around failure from the beginning. So I’m treating this as both a practical farm project and an engineering experiment.
And unlike a software prototype, the farm will be the final judge. If the network fails, the mango trees don’t care why.
Why LoRa?
LoRa is a low-power, long-range radio technology that’s popular in agriculture and IoT. Its trade-off is that it sends small packets slowly, over long distances, using very little energy. For a farm that’s a good deal: a valve command or a soil-moisture reading is tiny, and I don’t need video.
A mesh adds another layer. Instead of every device needing a direct line to one central point, nodes can relay messages through each other. That matters when the blocks are separated and trees (coconut palms and mango canopies absorb radio signals) don’t make things easy.
I’m doing this with my own nodes on my own land. The gaps between blocks belong to other people, so the design has to bridge them through careful placement and range, not by putting equipment where I don’t have permission.
Power: solar with battery backup, everywhere
The plan is to power the system with solar energy, with battery backup, in all three blocks.
There are a few reasons:
- Block 2 has no electricity. A solar node is the practical way to bring it into the network at all.
- Independence from the grid. Blocks 1 and 3 do have electricity connections, but power cuts are common in rural areas, and they often happen exactly when irrigation is due. A control system that dies with the grid defeats the purpose.
- Consistency. Using the same solar-plus-battery design in every block means one approach to build, test and maintain, instead of two.
The battery backup is what turns solar from “works in the daytime” into “works when I need it.” Sizing it properly, and monitoring its charge level so I get an alert before it runs low, is part of the design work.
The plan
The project is at an early stage, and I’m deliberately building in phases.
Phase 1: the base communication platform (current). Getting reliable, acknowledged messaging between nodes across the three blocks, running on solar and battery power. If messages can’t be trusted, nothing built on top can be.
Phase 2: drip irrigation control. Remote start and stop for pumps and zone valves, with confirmation back to me that a command actually executed.
Phase 3: sensors. Soil moisture, flow and pressure readings, so irrigation can eventually be driven by data and not just schedules.
Phase 4: solar lights. Simple on/off control of solar lighting around the farm.
Phase 5: fertigation. Dosing fertiliser through the drip lines, which needs the most care because mistakes are costly.
Designing for failure
Controlling pumps and fertiliser remotely means thinking about what happens when things go wrong. Principles I’m designing around:
- Safe defaults. If a node loses contact, valves and pumps should fall back to a safe state or a local schedule, not stay stuck on.
- Local fallback. Each controller should be able to run a basic schedule on its own, so a communication failure doesn’t mean a missed irrigation cycle.
- Power awareness. Nodes should report battery level and solar charging status, and behave sensibly when power is low, for example by saving the essentials and sending a warning before shutting down.
- Confirmation, not assumption. Every command should be acknowledged, and the system should report failures instead of silently ignoring them.
- Manual override. Hardware switches stay in place. Software should never be the only way to turn something off.
- Extra safeguards for fertigation. Limits on dose and duration, enforced locally on the device, not only in the app.
Security: the concerns are fair
Critics of offline mesh tools raise concerns that I don’t dismiss:
- With no central server, there’s no obvious place for moderation or oversight.
- Open, account-free communication can be misused.
- Young open-source projects may not have had thorough security audits.
For my farm, the third point is the one I take most seriously. A mesh that controls pumps and fertiliser dosing is a physical system, so it needs:
- authentication, so that only authorised nodes and commands are accepted
- encryption of traffic
- protection against replayed or forged messages
- a clear process for who can add a device to the network
A stranger shouldn’t be able to switch on my borewell. The same discipline applies to messaging apps: the security of the design matters more than the label “decentralised.”
What decentralised mesh is good for
The Bitchat debate tends to focus on one use case. The technology has many others:
- Agriculture: connecting pumps, sensors and people across land with no coverage, like my farm.
- Disaster resilience: when cyclones or floods bring down towers, device-to-device networks can keep communities and volunteers connected, especially when nodes run on solar and battery.
- Rural connectivity: villages and remote areas where building towers isn’t economical.
- Crowded events: festivals and pilgrimages that overload cellular networks.
- Reduced centralisation: less personal or operational data needs to pass through or reside in a central server.
- Backup communication: like backup power, it’s valuable precisely because you hope not to need it.
Rules, Regulations, Policies
The Bitchat debate also raises a broader question: how do we deal with technology that can be used for both legitimate and harmful purposes?
My instinct is to regulate the behaviour and manage the risks, rather than dismissing the underlying technology. Mesh networking has legitimate applications in agriculture, disaster response and rural connectivity.
As someone building one of those applications, I’m also conscious that radio spectrum, security and deployment rules matter. The technology may be decentralised; the engineering still has to respect the real world.
Where I am now
I’m still at the beginning. Right now, the goal is simple: get a small set of solar-powered nodes talking reliably across the farm.
If that works, I’ll teach the network to control irrigation. Then I’ll add sensors, lighting and eventually fertigation.
I’ll share what I learn along the way—especially what doesn’t work. Because this isn’t a lab experiment. As I mentioned earlier, If the network fails, my mango trees don’t care why.
If you’re working on LoRa, mesh networking, solar-powered IoT, farm automation or rural connectivity, I’d like to hear from you.
Tags: LoRa, Mesh Networks, Agritech, IoT, Solar, Rural Connectivity, Privacy