Zigbee and LoRaWAN solve different radio problems. Zigbee carries frequent readings from many devices packed into one building. LoRaWAN carries a few small readings an hour from devices spread over a large area. Many energy sites have both: dense sub-metering at the distribution boards, and a handful of gas, water or tank meters far from power and network.
On an EpiSensor system, Zigbee devices join the mesh of the ZGW-20 Gateway, and Edge on the Gateway stores their readings. LoRaWAN devices report to a LoRaWAN gateway and network server. The network server decodes each uplink and passes the readings to Edge over MQTT or HTTPS. Edge then holds both sets of readings in one data model. It does not replace the network server.
Choosing by requirement
| Project requirement | Starting point | What to verify |
|---|---|---|
| Readings every few seconds to every few minutes from many points in a building | Zigbee mesh | Router placement, Wi-Fi channel plan, device count per Gateway |
| A few readings an hour from dispersed battery devices | LoRaWAN | Surveyed coverage, spreading factor at the real meter position, airtime and battery budget |
| Both of the above on one site | Both networks | Who runs the network server, which timestamp each reading keeps, how the two resolutions are aligned |
| Equipment control with a response deadline | Neither by default | End-to-end latency, the state after a lost message, and the equipment's own protections |
A wireless protocol is not a safety function. Specify the safe state of controlled equipment with its supplier, whichever radio carries the command.
Zigbee on site
Zigbee runs on IEEE 802.15.4 at 2.4 GHz. The band has 16 channels, numbered 11 to 26, with centres 5 MHz apart from 2405 MHz to 2480 MHz. The over-the-air rate is 250 kbit/s, and one frame holds at most 127 bytes including headers.
The network has one coordinator, which on an EpiSensor system is the ZGW-20. Routers relay frames for other devices. End devices send and receive only through a parent router. A sleepy end device wakes, polls its parent for held messages and goes back to sleep. A mains-powered device is not always a router, so check the node type in the datasheet (see Silicon Labs' node-type definitions). Every mains-powered EpiSensor device routes. Each one reaches up to 50 m indoors and 300 m outdoors, and on average adds about 1,000 m² of commercial floor coverage. One ZGW-20 carries up to 250 devices and 1,000 sensors.
Each hop retransmits the frame on the same channel. A reading three hops from the Gateway therefore uses the channel three times. Deep chains of routers along a corridor fill the channel faster than a flat mesh with several paths to the Gateway.
Channel planning against Wi-Fi
A 20 MHz Wi-Fi channel covers ±10 MHz around its centre. Wi-Fi channels 1, 6 and 11 are centred on 2412, 2437 and 2462 MHz. They cover 2402 to 2422, 2427 to 2447 and 2452 to 2472 MHz, which overlaps Zigbee channels 11 to 14, 16 to 19 and 21 to 24. Zigbee channels 15 (2425 MHz), 20 (2450 MHz), 25 (2475 MHz) and 26 (2480 MHz) sit in the gaps. Silicon Labs measured that its 802.15.4 radios tolerate a Wi-Fi signal up to 20 dB stronger when the two are far apart in frequency than when they are adjacent.
Two cases break that plan. In Europe, Wi-Fi channel 13 (2472 MHz) is legal and covers Zigbee channels 25 and 26. A 40 MHz Wi-Fi channel covers twice the width of a 20 MHz one. Survey the Wi-Fi channels in use before you choose the Zigbee channel, and survey them again when the site adds access points.
Zigbee failure modes
- A router is switched off, isolated for maintenance or removed. Its end devices must find a new parent. If no other router is in range, they stop reporting until the router returns.
- A device sits inside a steel enclosure or a plant room with a steel door. Its link to the nearest router drops below a usable level. Put a router outside the enclosure, or move the antenna.
- A new Wi-Fi access point starts on a channel that overlaps the Zigbee channel. Reports from the far edge of the mesh arrive late or not at all.
All three show up the same way in the data: a device whose last report is older than two reporting intervals. Alarm on that condition, per device, from commissioning onwards.
LoRaWAN on site
LoRaWAN uses the LoRa modulation in sub-GHz bands: 863 to 870 MHz in Europe (EU868) and 902 to 928 MHz in North America (US915). Devices do not relay for each other. Each uplink goes directly to every LoRaWAN gateway in range, and the gateways forward it to one network server. The network server removes duplicates, checks the frame and passes it to the application.
The data rate is set by the spreading factor (SF). A higher SF reaches further and survives more attenuation, but each step roughly doubles the time on air. The EU868 regional parameters set these limits for 125 kHz channels:
| Data rate | Spreading factor | Bit rate | Maximum application payload |
|---|---|---|---|
| DR0 | SF12 | 250 bit/s | 51 bytes |
| DR1 | SF11 | 440 bit/s | 51 bytes |
| DR2 | SF10 | 980 bit/s | 51 bytes |
| DR3 | SF9 | 1,760 bit/s | 115 bytes |
| DR4 | SF8 | 3,125 bit/s | 222 bytes |
| DR5 | SF7 | 5,470 bit/s | 222 bytes |
Every EU868 device must use 868.1, 868.3 and 868.5 MHz. All three sit in the 868.0 to 868.6 MHz sub-band, which ETSI limits to a 1% duty cycle at 25 mW ERP. The Things Network's public Sandbox adds a fair-use limit of 30 s of uplink airtime and 10 downlinks per device per day. A private network server has no fair-use limit, but the duty cycle still applies.
Range depends on antenna height, terrain, buildings and the SF. A gateway on a mast can reach devices several kilometres away across open ground. Inside buildings and basements, expect hundreds of metres. Model coverage, then test it with a device at the real meter position.
Airtime worked example
A meter sends a 20-byte application payload. LoRaWAN adds 13 bytes of header and integrity check, so the radio sends 33 bytes. With an 8-symbol preamble, coding rate 4/5 and CRC on, the time on air is:
| Spreading factor | Time on air | Minimum gap at 1% duty cycle | Uplinks a day within 30 s | Shortest interval within 30 s a day |
|---|---|---|---|---|
| SF7 | 72 ms | 7 s | 417 | 3.5 minutes |
| SF9 | 247 ms | 24 s | 121 | 12 minutes |
| SF10 | 453 ms | 45 s | 66 | 22 minutes |
| SF12 | 1,810 ms | 179 s | 16 | 90 minutes |
A 15-minute interval is 96 uplinks a day. It fits the Sandbox fair-use limit at SF7 to SF9, but not at SF10 and above. A meter in a basement chamber that only links at SF12 can send about once every 90 minutes on the Sandbox. The same meter also uses about 25 times the transmit energy per reading that it would at SF7, so its battery estimate must use the SF it actually achieves.
Explore the packet-duration calculation with the complete 33-byte radio payload from this example. Changing the spreading factor changes airtime; the result does not establish compliance with a regional channel-access rule or a network fair-use policy.
Device classes and commands
All three device classes can receive downlinks. A Class A device listens only in two short receive windows after each of its own uplinks. A command to a Class A meter that reports hourly can therefore wait up to an hour. Class B adds receive slots scheduled by gateway beacons. Class C listens all the time except while it transmits, which suits mains-powered actuators and costs too much power for most battery devices. None of the classes gives a guaranteed end-to-end delivery time (see LoRaWAN device classes).
LoRaWAN failure modes
- An unconfirmed uplink that no gateway hears is lost. The protocol does not retry it. Choose devices that send a cumulative register, such as total kWh or total m³, with each uplink. A lost uplink then costs time resolution, not energy.
- Confirmed uplinks make the network server send a downlink acknowledgement for each one. A device that confirms every 15-minute reading needs 96 downlinks a day, far above the Sandbox limit of 10, and each downlink blocks the gateway from receiving while it transmits. Use confirmation only where a lost reading matters more than the airtime.
- Adaptive data rate (ADR) moves a device to a lower SF when its link margin is good. When the link degrades, the device steps back up towards SF12. A device that moves, or one behind a door that is usually open, can drift to SF12 and drain its battery much faster than planned. Watch the SF that each device reports to the network server.
- A device activated by personalisation (ABP) keeps fixed session keys. If it resets its frame counter to 0 after a power cycle, the network server ignores every uplink with a counter lower than the last one it saw. The device then transmits normally and nothing arrives. Use over-the-air activation (OTAA), which sets new session keys and counters at each join.
- A LoRaWAN gateway loses its backhaul. Ask whether the gateway buffers uplinks while its link is down. If it forwards only in real time, readings from that period are gone.
Hybrid site examples
Campus with remote meters
A university campus has 20 buildings. Inside each building, electricity monitors at the distribution boards report every minute or faster. That is Zigbee work. Each building with more than 250 devices, or with no radio path to its neighbours, gets its own Gateway.
Across the campus there are water meters in chambers, gas meters at the boundary and weather stations on roofs. They report every 15 to 60 minutes and have no power or Ethernet nearby. LoRaWAN suits them. Place the LoRaWAN gateways from a coverage survey, with a test device lowered into the deepest chamber, rather than assuming that one rooftop gateway covers the campus.
Multi-site portfolio
A property owner monitors 50 commercial buildings. The large buildings each have a Gateway and a Zigbee mesh for circuit-level monitoring. The small sites, such as car parks and unmanned plant rooms, need only a main meter reading and a temperature. At those sites a battery LoRaWAN pulse or temperature device reporting to an existing network server avoids a Gateway visit per site. Check the airtime budget first if the network server is a public one.
Factory with outdoor utilities
A food factory uses Zigbee for power monitoring of each production line. Outside, LoRaWAN devices read the gas meter, the borehole water meter and the level of a fuel oil tank. With both sets of readings in Edge, gas, water and electricity per shift share one timeline, and the site can calculate energy per tonne of product.
Integration architecture
Zigbee route. Zigbee device, ZGW-20 coordinator, Edge on the Gateway. Edge stores the readings locally and keeps working when the upstream link is down.
LoRaWAN route. LoRaWAN device, LoRaWAN gateway, network server with the device's payload decoder, an MQTT or HTTPS integration, Edge. The network server can be private or public, and can belong to the site or to another team. Agree who owns the network server account, the device keys and the decoder version before you connect it. The LoRaWAN device list and Zigbee device list in the Device Directory show how each third-party model connects and which readings it documents.
A site can also skip Edge for LoRaWAN and send both streams straight to its platform: Zigbee readings from the Gateway, and LoRaWAN readings from the network server. The same rules on time and resolution then apply in the platform.
Timestamps
A Zigbee attribute report and a LoRaWAN uplink carry no measurement time at the protocol layer, unless the device puts one in its payload. The receiver stamps each reading. For Zigbee, that is the Gateway, one hop or a few hops from the device. For LoRaWAN, the network server records the time it received the uplink, and the integration can deliver that message seconds or, after an outage, hours later. Map the network server's receive time to the reading, not the time the message reached Edge. Otherwise a replayed backlog lands as a burst of readings at the moment the link returned.
Firmware updates
Both networks can update device firmware over the air, at very different speeds. The OTA guide compares the Zigbee OTA cluster with LoRaWAN FUOTA and explains how to plan an update campaign.
Mixed resolutions
Zigbee readings every minute and LoRaWAN readings every 30 minutes do not line up by default. For consumption, calculate the difference of the cumulative register between interval boundaries. Do not sum spot power values. For a report on a common interval, such as 30 minutes, compare meters only at that interval. Show the reading age beside each value, so that an hour-old LoRaWAN reading does not look as current as a one-minute Zigbee one.
Security
Zigbee encrypts network traffic with a 128-bit AES network key shared by every device on the network. The coordinator acts as the trust centre and sends the network key to each device when it joins. Zigbee 3.0 devices must support install codes. An install code gives each device a unique link key that protects the network key during the join. Without one, the network key is sent under a default link key that is publicly known, so anyone listening during the join window can capture it. Open the network for joining only while you commission, and use install codes where the devices support them.
LoRaWAN 1.0.x uses a root AppKey per device for OTAA. From it, each join derives a network session key (NwkSKey), which the network server uses to check message integrity, and an application session key (AppSKey), which encrypts the payload between device and application server. LoRaWAN 1.1 splits the root key into NwkKey and AppKey and uses separate network session keys. On a public network server, the operator can hold all of these keys. Record who holds each one, and how a device is re-keyed when it moves to another network server.
Protect the link from the network server to Edge with TLS and credentials, as for any MQTT or HTTPS integration. See MQTTS: MQTT over TLS for the commissioning tests.
What to check before rolling out
Run a pilot that includes the hardest meter positions, not only the points nearest a gateway. Agree these acceptance tests with the installer and the platform team:
- Record the device identity, firmware, units, scaling and reporting interval for each point. For LoRaWAN devices, also record the SF each device settles at.
- Compare received values against the meter display or a reference instrument. Store cumulative registers separately from calculated consumption.
- Check that the platform shows a missing reading as missing, not as zero.
- Interrupt the radio link, the Gateway's power and the upstream connection one at a time. Record which component keeps the data and which gaps cannot be recovered.
- For commands, check the equipment's measured state, not only the acknowledgement from the application.
- Hand over the ownership of keys, network server accounts, spare devices and support contacts before you copy the design to 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.