Skip to Content

LoRaWAN in industrial plants: without construction or wiring, in a few weeks

19 August 2026 by
LoRaWAN in industrial plants: without construction or wiring, in a few weeks
Ana Escalante Galán

Monitoring energy consumption of an industrial plant is known for being a long project. And the reputation is justified. The traditional approach involves wiring each measurement point to the panels, network deployments, opening conduits, requesting construction permits, and coordinating production stoppages. With large suppliers, the usual timeframe is six to twelve months for the project, and in the end, the data often remains locked in the manufacturer's system. 

That timeline is the reason why many medium-sized factories have been postponing the decision for years. They know they are overpaying for energy. But the cost of resolving it (in construction, in stoppages, in dependence on a manufacturer) seems greater than the problem. 

LoRaWAN changes that equation. This article explains what a real implementation in a plant looks like, why it is completed in weeks and not months, and what conditions are necessary for the deadlines to be met. 

If you are still unclear about the basics of the technology, start with "LoRaWAN in factories: what it is, when to use it, and what limitations it has" and continue here. 

Why traditional projects take months 

A classic energy monitoring project carries three sources of delay: 

  • The wiring: Each sensor needs a data cable and, often, another for power. In a plant with dozens of measurement points spread across several buildings, some very dispersed, that means hundreds of metres of structured cabling, civil works, and weeks of installation. 
  • The stoppages: Working on electrical panels and production areas requires coordinating downtime windows. Each downtime has a direct cost in production and indirect work in planning, and that is where projects often get stuck. 
  • The dependency on the manufacturer: Many solutions require replacing meters or installing proprietary hardware that only communicates with the supplier's platform. The project drags on and, when it finishes, the data remains locked away: another island of information that does not reach the ERP or BI. 

The result is known by anyone who has been through it: projects budgeted for one quarter that are delivered the following year, with the plant staff fed up with the process before seeing the first useful data. 

What changes with LoRaWAN 

LoRaWAN eliminates the first two sources of delay at their root and, if well planned, also the third. 

  • Without wiring: LoRaWAN sensors operate on battery, with years of autonomy, and transmit via radio to the gateways. Installing a measurement point ceases to be a construction project and becomes a mechanical fixture taking minutes. 
  • Without construction or downtime: As there is no need for structured cabling or conduits, there is no civil work or need to stop lines. The sensors are installed while the plant is running. 
  • Without replacing what you already have: The LoRaWAN layer does not replace your infrastructure; it complements it. The meters, PLCs, and SCADA systems that are already accessible are read directly (via pulses, RS485/Modbus, or other protocols), and LoRaWAN only covers the points that currently lack visibility. It is a hardware-agnostic approach: the measurement relies on what already exists and adds sensors only where they are needed. 

That combination is what compresses the schedule. The friction of a monitoring project is not in the electronics: it is in the work, in the stoppages, and in the dependencies. Removing those three, what remains is done in weeks. 

The phases of a real implementation 

A well-executed implementation does not start directly with the installation of the sensors. The first step is to understand the plant. These are the phases of a typical deployment: 

Phase 1. Diagnosis of sources and coverage 

Before proposing anything, an inventory of what already exists is made: which meters, PLCs, SCADA, and sensors are operational, which are accessible for direct reading, and where the visibility gaps are. In parallel, a radio coverage study determines how many gateways are needed and where to place them, because the metal structure of the buildings affects the design. 

The result is a map of the plant with three layers: what integrates directly, what needs a LoRaWAN sensor, and what does not add value to measure. Thanks to our experience of over 19 years in IoT, this phase lasts weeks, not months, and allows you to decide with real information instead of with catalogues. 

Phase 2. Deployment of the acquisition layer 

With the validated map, the gateways (typically one or two per industrial site) and the LoRaWAN sensors are installed at points without visibility: submetering by machine or line, which provide data on their usage, equipment statuses, etc. At the same time, the existing sources are connected for direct reading. 

As there is no wiring or construction, this phase progresses in parallel with normal production. The plant is unaware that a project is underway, except that data starts to arrive. 

Phase 3. Unification and integration with ERP and BI 

All data, both from the LoRaWAN layer and from direct sources, is consolidated into a centralised platform. From there, it connects with management systems: Power BI, Navision/Business Central or others. The aim is for the energy data to reach where decisions are made, not to reside in a separate application that no one reviews. 

At this point, the plant already sees useful data: consumption by machine and line, detection of idle consumption, peaks and deviations by shift. And this happens before the project has formally finished. 

Phase 4. Exploitation and evolution 

The implementation does not end with the installation. The dashboards are adjusted to how each team works, the actual return (in euros, kWh and CO₂ footprint) is measured, and the data model evolves as the plant changes. New lines, new machines, new measurement points are added without construction, just like the first ones. 

What conditions must be met for the deadlines to be met 

The promise of "weeks" is realistic, but it is not magic. It depends on three conditions that should be verified before starting: 

Well-studied radio coverage. Buildings with a lot of metal structure, basements, and galleries reduce the range. A prior coverage study (phase 1) prevents discovering this with the sensors already purchased. 

Access to existing sources. Direct reading of meters and PLCs requires knowing what protocols they speak and who has the credentials. If that information is located, integration is quick. If there is documentary archaeology, phase 1 is prolonged. 

A contact person on site. A dedicated team is not necessary, but a person who knows the installation, validates locations, and facilitates access is essential. This is the factor that most differentiates a three-week deployment from one of three months. 

None of the three conditions require prior investment or stopping production. They are matters of preparation, not of work. 

A typical example of a schedule 

For a medium-sized factory with two or three buildings and a few dozen measurement points, a realistic schedule would be: two or three weeks of diagnosis and coverage study, one or two weeks of deployment of gateways and sensors, and one or two weeks of integration with ERP and BI. Between four and seven weeks from the start to seeing consumption by machine on the dashboard. 

(Hypothetical example with indicative timelines; the actual schedule depends on the size of the plant and the state of the existing sources.) 

Compare it with the six to twelve months of the traditional approach. The difference is not in working faster, it comes from eliminating the tasks that consumed time. 

The first step: a diagnosis, not an order

The correct way to start is not to buy sensors: it is to request a diagnosis. At Celestia TST, that is the start of any energy monitoring project: in a few weeks you have the map of your data sources, the blind spots of your plant, and a unification proposal ready to execute. You decide with real information, and the technology adapts to your operations, not the other way around.


Yes, LoRaWAN is a radio technology designed to capture data from dispersed sensors in complex environments: it is resistant to electronic noise, with long range and high penetration in infrastructures, do you want to know more about LoRaWAN?, we recommend reading our article: "LoRaWAN in factory: what it is, when to use it and what limitations it has" 

Not for the LoRaWAN layer: sensors are installed while the plant is running. Only the connection to certain electrical panels for direct reading may require a one-off intervention, which is planned within the existing maintenance windows. 

No. The approach is hardware-agnostic: what is already measured and accessible is integrated through direct reading, and LoRaWAN is deployed only at points without visibility. 

It depends on the size and structure of the buildings. As a reference, one or two well-placed gateways usually cover an entire industrial site. The coverage study of phase 1 determines this precisely. 

Adding measurement points is the scenario for which LoRaWAN is designed: a new sensor is installed in minutes and registered on the software platform without touching the infrastructure. 

No, the solution is based on an open platform, the data is fully accessible and integrable wherever necessary. The correct design criterion is that the energy data integrates with the client's ERP and BI from day one. If a solution does not allow this, it is advisable to discard it before starting. 



 Request your energy diagnosis



Written by Ana Escalante Galán, Head of Marketing and Communications at Celestia TST

Technical review: Iván Bermejo, Head of IoT Industry Business Development



Share this post
Archive