For an energy-monitoring project, the choice between Zigbee and LoRaWAN starts with the measurements you need: where the devices sit, how often a reading is useful, and whether the system must send commands back. A building with many nearby measurement points and a dispersed estate of battery-powered meters can need different radio networks, even when their data belongs in the same energy platform.
Use one network where it meets the requirement. Combine them when the additional coverage or device choice justifies operating two. Sharing a protocol name does not establish that a particular sensor, Gateway and application will work together.
Which approach fits the site?
| Project requirement | Starting point | What to verify |
|---|---|---|
| Frequent readings from many points inside a building | Assess a Zigbee mesh | Router placement, interference, reporting load and device support |
| Small, occasional readings from dispersed battery devices | Assess LoRaWAN | Surveyed coverage, regional settings, airtime and battery budget |
| Both indoor detail and remote meters | Assess a hybrid design | Who runs each network and where the data streams are combined |
| Time-sensitive equipment control | Start with the required response and safe behaviour | End-to-end latency, feedback, loss of communications and the equipment's own protections |
These are design starting points, not guarantees of coverage or performance. For the measurement layer itself, see the guide to selecting current transformers.
Zigbee: Strengths and Characteristics
Zigbee builds on IEEE 802.15.4. Check the radio band supported by the actual devices; support for a band in a specification does not mean it is present in every product. In a mesh, router-capable devices can relay messages, while end devices communicate through a parent.
Key Strengths
- Mesh networking: Specify router-capable devices where forwarding is needed. A mains-powered device is not necessarily a router: non-sleepy end devices also exist and do not relay other devices' messages. See Silicon Labs' node-type definitions.
- Reporting: Supported reporting intervals depend on the device, payload and network load. A radio's headline data rate is not the usable reporting capacity of an installed mesh.
- In-building coverage: Link range depends on walls, plant, interference, antenna placement, and transmit power. The mesh can extend coverage through intermediate routers, but it should be surveyed and commissioned in the real building.
- Low power: Battery-powered Zigbee end devices can operate for years on a single battery by sleeping between transmissions.
- Network planning: Check the supported device count and reporting workload for the selected Gateway and firmware; a theoretical protocol limit is not a deployment limit.
- Security: Zigbee includes security mechanisms, but commissioning, key handling and device maintenance remain part of the system design. Encryption alone does not establish that a deployment is secure.
Limitations
- Range: Zigbee is designed for in-building or campus-scale deployments. Covering areas spanning kilometres requires many repeaters or is simply impractical.
- Gateway requirement: Each Zigbee network requires a coordinator/gateway device connected to the internet for cloud connectivity.
- 2.4 GHz interference: In the 2.4 GHz band, Zigbee shares spectrum with Wi-Fi and Bluetooth. While Zigbee's channel agility and mesh routing mitigate this, heavily congested RF environments can pose challenges.
LoRaWAN: Strengths and Characteristics
LoRaWAN (Long Range Wide Area Network) uses the LoRa physical layer, operating in sub-GHz ISM bands (868 MHz in Europe, 915 MHz in North America). It uses a star-of-stars topology where end devices communicate directly with one or more gateways.
Key Strengths
- Wide-area coverage: LoRaWAN can cover much larger areas than an in-building mesh, but real range depends on frequency plan, antenna height, terrain, buildings, spreading factor, and link budget. Coverage should be modelled and then verified on site.
- Difficult locations: Test reception at the actual meter position. Radio frequency alone does not establish whether a signal will escape a metal cabinet, basement or underground chamber.
- Battery operation: Estimate battery life from the selected device, reporting interval, link conditions and operating temperature rather than assuming a multi-year lifetime from the protocol alone.
- Minimal infrastructure: One or a few gateways can cover an entire campus, town, or rural area, reducing deployment cost for geographically dispersed sensors.
- Public and private networks: LoRaWAN can be deployed on private gateways or via public network operators (such as The Things Network or Helium).
Limitations
- Low data rate: LoRaWAN is designed for small, infrequent messages rather than high-rate waveform or power-quality data. The usable rate depends on region, data rate, payload, and network conditions.
- Constrained airtime: Regional radio rules and network capacity limit how often devices should transmit. Reporting strategy must be designed with the relevant frequency plan and duty-cycle requirements.
- Topology: Plan coverage through LoRaWAN gateways rather than assuming that ordinary end devices form a Zigbee-like routing mesh.
- Downlink timing: All three device classes support downlinks, but receive opportunities differ. Class A opens receive windows after an uplink; Class B adds scheduled opportunities; Class C listens almost continuously except when transmitting. Class C can reduce downlink delay at a higher power cost. None of this guarantees deterministic end-to-end control timing. See LoRaWAN device classes and network limitations.
Why Combine Zigbee and LoRaWAN?
Many real-world IoT deployments have requirements that neither protocol can satisfy alone. A hybrid architecture using both Zigbee and LoRaWAN can address a wider range of use cases:
The following layouts are illustrative examples, not coverage or performance guarantees.
Scenario 1: Building-Level and Campus-Level Monitoring
Consider a university campus with 20 buildings. Inside each building, detailed electrical monitoring requires frequent data reporting (every 10 seconds) from dozens of sensors at each distribution board. This is a natural fit for Zigbee, with a gateway in each building collecting data from a mesh network of sensors.
Across the campus, there are also environmental sensors, water meters in remote locations, and utility meters at the boundary. These devices report infrequently, are spread across a large area, and may not have convenient access to power or Ethernet. LoRaWAN is worth assessing here, with gateway locations established by a coverage survey rather than an assumption that one rooftop gateway covers the entire campus.
Scenario 2: Multi-Site Portfolio Monitoring
A property management company monitors energy consumption across a portfolio of 50 commercial buildings. Each building has an EpiSensor Gateway with Zigbee sensors for detailed electrical monitoring. At some remote sites (unmanned substations, car parks, telecommunications towers), only basic consumption and environmental data is needed. LoRaWAN sensors at these sites report data directly to a shared LoRaWAN network, avoiding the need for a full Zigbee deployment at each location.
Scenario 3: Indoor Detail with Outdoor Context
A manufacturing facility uses Zigbee for detailed power monitoring of production equipment inside the factory. Outside, LoRaWAN sensors monitor gas meters, water flow meters, fuel tank levels, and weather conditions across a large industrial site. Both data streams feed into the same cloud platform, providing a complete operational picture.
Integration Architecture
Combining Zigbee and LoRaWAN data requires a common integration layer. The typical architecture is:
- Zigbee sensors communicate with an EpiSensor Gateway via the Zigbee mesh network. The Gateway forwards data to the cloud platform via Ethernet or cellular.
- LoRaWAN sensors communicate with a LoRaWAN gateway (or public network), which forwards data to a LoRaWAN Network Server (LNS).
- The cloud platform ingests data from both the EpiSensor Gateway (via MQTT or HTTPS) and the LoRaWAN Network Server (via webhook, MQTT, or integration API), normalising it into a unified data model.
The key technical consideration is data normalisation: ensuring that data from both protocols is stored with consistent timestamps, units, and device identifiers so it can be queried and visualised together.
Practical Considerations
Data Granularity
Zigbee sensors can support frequent site telemetry, while battery-powered LoRaWAN devices are usually configured for less frequent trend data. The actual interval should be chosen from the operational requirement, battery budget, payload, regional radio constraints, and network capacity. Analytics must preserve those different resolutions instead of implying that all points are equally current.
Network Management
Operating two wireless protocols means managing two sets of infrastructure. Zigbee networks are managed through the EpiSensor Gateway, while LoRaWAN networks require a separate network server. Consider the operational overhead of maintaining both, and whether the benefits of the hybrid approach justify the additional complexity for your specific deployment.
Security
Both Zigbee and LoRaWAN provide encryption (AES-128 for Zigbee, AES-128 for LoRaWAN application and network layers). Ensure that encryption keys are properly managed for both networks and that data in transit to the cloud platform is protected with TLS.
Using Both with EpiSensor
EpiSensor uses Zigbee for its wireless sensor mesh, and the ZGW-20 Gateway can be specified with LoRaWAN support for wide-area devices. A hybrid design should still define where the LoRaWAN network server lives, how identities and keys are managed, and how both streams are normalised before they reach the customer's platform.
Before specifying a hybrid deployment, agree the device list, required radio options, network-server location and supported integration with the EpiSensor team. The Gateway page and current datasheet are the starting point for hardware selection; Edge explains the local software layer. A radio option does not by itself establish support for every third-party device or payload.
What to check before rolling out
Start with a representative pilot, including the hardest meter locations rather than only the points nearest a gateway. Agree acceptance criteria with the installer and the platform team:
- Record the device identity, firmware, units, scaling and expected reporting interval for each point.
- Compare received values against the meter or a known reference. Preserve cumulative readings separately from calculated consumption.
- Check how the platform distinguishes a stale reading from a genuine zero. Preserve observation time separately from delivery time when replaying buffered data.
- Test loss and restoration of the radio link, gateway power and upstream connection separately. Establish which components retain data and which gaps cannot be recovered.
- For commands, verify the equipment's observed state as well as the application's acknowledgement. Agree safe behaviour with the equipment supplier; a wireless protocol is not a safety function.
- Hand over ownership of keys, network-server accounts, device replacements and support contacts before replicating the design across more sites.
For the next design decisions, read about IoT data storage and architecture and energy-management platforms. If you have a site plan and point list, contact EpiSensor to review the sensing and connectivity requirements.