
The most common field failure in IoT projects is not a broken sensor or a slow platform. The sensor is fine, the platform is ready β the data simply never arrives. A pump at the far edge of the site, a tank behind the warehouse, a distribution panel in the building across the yard: all of them sit outside the plant network, and running cable to them turns out to cost far more than the hardware itself.
Choosing the connectivity path correctly at the start decides whether a project stays a pilot or scales across every site.
Four questions before naming a technology
Don't start from technology names. Start from these four numbers:
- How often is the data needed? Tank level every 15 minutes is fine. Motor vibration needs every second. That gap changes every downstream choice.
- How large is one payload? Ten sensor values is a different world from one camera frame.
- Is mains power available, or is it battery? This is what eliminates certain options immediately.
- How far is the nearest network point, and what is in between? Concrete walls, metal structures, and terrain matter far more than the range figure in a brochure.
Cable: the best option whenever it is possible
Ethernet or RS-485 remains the most reliable: low latency, ample bandwidth, no subscription, no batteries. Where the distance is reasonable and a cable route exists, there is no reason to go wireless. RS-485 is particularly useful in plants because a single run can daisy-chain many Modbus devices over hundreds of metres.
The obstacle is not technical but civil. Crossing a road, penetrating a floor slab, or running through an active production area routinely makes installation cost several times the hardware price.
WiFi: easy to deploy, hard to depend on
WiFi is tempting because the infrastructure already exists. But office networks are designed for laptops, not for devices that must stay connected for years without interruption. The recurring problems: access points rebooted during IT maintenance, passwords rotated without notice, and production areas full of metal structures that reflect signal. If you do use WiFi, put IoT devices on a dedicated SSID and make sure the IT team knows that network cannot be restarted casually.
4G cellular: for genuinely detached points
When a location sits outside the site entirely β a substation in a field, a tank at another property, a moving fleet β cellular is the most practical answer. Bandwidth is ample for both sensor data and imagery, and it depends on no plant infrastructure at all.
Two consequences follow: a data plan cost per point per month, and power draw that makes pure battery operation impractical for frequent transmission. For ten remote points this makes complete sense. For five hundred sensors within one site, the economics stop working.
LoRa: long range, very low power, very little data
LoRa exists for the case the other three cannot serve: kilometre-scale range, power consumption low enough that devices run for years on a battery, and signal penetration far better than WiFi.
The price is capacity. LoRa payloads are tiny and transmission cannot be frequent. That makes it excellent for tank levels, soil moisture, open/close status, and meter readings β and entirely unsuitable for high-resolution vibration or imagery.
The pattern that usually works: a mix
Real sites are rarely uniform, and forcing one technology onto every point is a reliable source of disappointment. The arrangement that tends to survive:
- Core area β machines and main panels over RS-485 or Ethernet cable.
- Site perimeter β points scattered across hundreds of metres over LoRa into a single gateway.
- Off site β one gateway with a cellular connection carrying all those points to the platform, rather than one SIM per sensor.
The key is in that last phrase: a gateway aggregates many devices into one outbound path. That is what keeps monthly cost under control as the number of points grows.
The costs that only appear in year two
Cost comparisons at the planning stage almost always count hardware price alone. The three items below only bite once the system is running β and they are what decide whether the project can scale:
- Data plan subscriptions. A per-point monthly fee looks trivial across five points. Multiplied by a hundred points over three years, it exceeds the entire hardware spend.
- Battery replacement. Battery-powered devices in remote locations mean recurring site visits. The real cost is not the battery but the technician's time and the journey to reach that point.
- Network maintenance. Any wireless network degrades over time β new buildings, new machines, changed layouts. Budget for periodic review, not a one-time installation.
The better question, therefore, is not "which is cheapest to install" but "what does every point cost over three years".
Where the gateway sits in the architecture
IncludeGateways occupies exactly this position: reading field devices over RS-485/Modbus, receiving nearby LoRa nodes, then forwarding everything to the platform over the plant network or 4G. Legacy equipment that only speaks Modbus stays in service, and only the gateway needs an outbound connection.
For processing that must run on site β buffering data during a network outage, or analysis that cannot wait for the cloud β IncludeBox handles that load at the edge. How this connectivity layer fits into the wider IoT architecture is set out in our guide to IoT & AIoT platforms in Indonesia.
Have points the network cannot reach?
Describe your site layout and the distances involved β the INCLUDE team will suggest the connectivity mix that makes the most sense on cost.
Konsultasi Gratis via WhatsApp β See IncludeGateways β