Infrastructure where the internet is optional

Most of the software I build assumes a network. The olive farm project has made that assumption expensive.

The property is in the Homs countryside, and the conditions are ordinary for the area: power can drop, mobile coverage is inconsistent, and there is nobody on site most of the time. Any monitoring system has to work anyway.

This is a note about the constraints, not a description of a finished installation.

The first assumption to remove#

The instinct is to design a system that reports continuously. A sensor reads a value, the value goes to a server, the server shows a dashboard. Remove the network and the whole chain stops.

The alternative is to design for interruption:

• Devices store readings locally, with a timestamp, regardless of connectivity.
• Sending is an opportunistic job, not a requirement.
• When the link returns, the device sends what it has and continues.
• The system tolerates gaps rather than treating them as failures.

This changes the data model. Every reading needs to be associated with the device's own clock, and the receiving side has to accept late data without assuming it is wrong.

Monitoring before automation#

It is tempting to start with control: valves, pumps, irrigation schedules. That is the wrong order.

Automation without a trustworthy picture of the current state is a liability. If a sensor is reporting stale data, an automated decision based on that data can do real damage. The first phase is measurement only: is there water, is there power, is the gate closed, is anything obviously wrong.

Control can come later, once the monitoring has been running long enough that the data is boring.

Power shapes the design#

Solar planning is usually described as a capacity question. In practice it is a duty-cycle question. What actually needs to run, for how long, and how much energy does it take to keep that running through a cloudy week?

The answer pushes toward devices that sleep, send in batches, and do not keep a radio active for no reason. It also pushes toward accepting a lower reporting frequency. A daily summary that is reliable is worth more than a live feed that is not.

Connectivity is a design input#

Mobile coverage varies across the property. A device placed for convenience of wiring may have no signal at all, while a device forty meters away has two bars.

The practical approach is to treat the link as a separate, testable component:

• Measure signal strength at candidate locations before committing to them.
• Allow the gateway to buffer and forward, so individual devices do not each need a modem.
• Use a connection that degrades predictably, and test what happens when it disappears for a week.

What I am being careful about#

This project involves a real property, and some of the details are sensitive. The site does not publish coordinates, layouts, or security configuration, and the writing stays at the level of approach rather than specifics.

That is not only a privacy preference. Publishing the details of how a remote property is secured and monitored would make the work harder.

The transferable lesson#

Software delivery teaches you to define a happy path and then handle the exceptions. Physical infrastructure inverts that: the exceptions are the normal case, and the happy path is the rare window when everything is working.

Designing for that has made me a more conservative engineer elsewhere. Systems that recover on their own, keep local state, and fail visibly are worth the extra effort — especially when nobody is around to restart them.