The Truth About IoT Protocols: Where Z-Wave Long Range, LoRaWAN and Other Technologies Really Work

Overview

The session is a panel discussion comparing Z-Wave Long Range and LoRa/LoRaWAN for IoT use cases. The emphasis is that protocol selection should be driven by application requirements and interoperability, not by “range wars.”

Core comparison themes (RF design tradeoffs)

LoRa vs. LoRaWAN vs. Z-Wave Long Range

• All are positioned as long-distance, low-power wireless approaches.
• They operate in sub-gigahertz/ISM-style spectrum contexts (the same spectrum family is mentioned).
• They differ in architecture, for example:
  • LoRaWAN: a gateway “star” model
  • Z-Wave Long Range: a star-like controller-based link approach

Decision criteria discussed

The panel highlights the intersection of:

• Range
• Power consumption
• Latency
• Topology
• Network size
• Total cost of ownership

Repeated advice: engineers should start from requirements (e.g., battery life, latency tolerance, bandwidth needs, network density) rather than rely on datasheet range alone.

LoRaWAN: when it works best

Definition / ecosystem

• LoRa is described as the radio technology (Semtech-originated, low power).
• LoRaWAN is an open-source software protocol managed by the LoRa Alliance (not owned by a single company), used to connect devices to the network via gateways.

Key technical strengths

• Optimized for very low power operation (e.g., coin-cell-type longevity).
• Designed for long range and deep penetration (e.g., through walls/concrete).
• Strong fit for small payloads.

Representative use cases

• Dominant market: water-related metering and infrastructure, including:
  • water metering/submetering
  • leak detection
  • irrigation
• Growing area: connected buildings, attributed to long installation distances and flexible business/network models.

Network/business model flexibility

• The LoRa Alliance is described as a non-profit.
• The discussion frames business model choices as flexible, such as:
  • public/community networks (e.g., The Things Network)
  • hybrid/private models

When LoRaWAN is a “no-go”

• Ultra-low latency apps: LoRaWAN is said to involve roughly ~1 second delay due to its gateway-based communication model, making it unsuitable for interactive, millisecond-style experiences (e.g., “button-like” responsiveness).
• High bandwidth needs: not intended for video streaming or large data rates. Video requires different modulation approaches (not “LoRa” in the strict sense, per speaker).

Z-Wave Long Range: when it works best

Why Z-Wave is strong

• Emphasis on reliability at sub-gigahertz
• Security
• Interoperability via certification/spec guarantees
• Described as a member-driven alliance/standard

Topology and modulation changes for long range

• Baseline Z-Wave mesh is contrasted with Z-Wave Long Range:
  • Long Range is described as star-like, where end nodes can communicate directly with the controller.
  • Uses spread spectrum modulation to extend range.
• Range figures mentioned:
  • ~2.4 km official number
  • ~7 km achieved in an earlier summit context (under optimal conditions)

Power optimization

• Dynamic transmission power is described as reducing consumption when devices are closer to the controller.

When Z-Wave Long Range is considered

• More than just basic meters: reaching devices at plot edges, sheds/gardens, and commercial scenarios like hotel/commercial lighting.
• Coexistence is highlighted:
  • Long Range devices can coexist with Z-Wave mesh under controllers that support both—so it’s not strictly either/or.

Limits / constraints

• Not suitable for huge bandwidth use cases (e.g., cameras or voice transmission).
• Network size scaling:
  • Long Range can handle up to ~4000 nodes or more
  • but heavy communication can cause collisions, so performance depends on traffic patterns and application requirements.

Engineering guidance & pitfalls (practical selection advice)

Major pitfall for engineers

• Choosing a protocol based on datasheet/spec “range” rather than real-world conditions.

The panel recommends real-world testing that accounts for:

• walls
• concrete
• elevators
• other environmental factors

Correct workflow

1. Determine application requirements first (latency tolerance, bandwidth needs, expected traffic frequency, battery constraints)

2. Then evaluate protocol fit

LoRaWAN-specific selection checkpoints

• Power/consumption priorities (e.g., sleep mode duration)

• Range vs. success rate (how long and how often transmissions must occur relative to link reliability)

• Duty cycle / regional compliance for ISM band operation, including whether multi-region constraints matter

Note: LoRa is described as cost-efficient for ecosystem reasons, but it still has regional duty-cycle/spectrum limitations.

Questionable assumptions to avoid

• Don’t assume extreme range demos prove practical value.
• Avoid treating technologies as single-purpose (e.g., “LoRa is only for water meters”).
• The discussion differentiates:
  • LoRa vs. LoRaWAN
  • LoRa used in other modes such as D2D (device-to-device) with lower latency
  • “LoRa +” (combining LoRa with additional radio/modulation options on the same chip) to broaden application possibilities

Research / resources promoted

Z-Wave Alliance study

• A Z-Wave Alliance commissioned study is mentioned covering:
  • comparison/contrast of long-range Z-Wave vs. LoRaWAN
  • how they can interact
  • differences in applications and relevant considerations

Call to action

• Scan a QR code at the Z-Wave Alliance booth for study details.
• Additional booth information is available via:
  • Semtech
  • Z-Wave Alliance
  • SiLabs (Silicon Labs)

Main speakers / sources

• Avi Rosenthal — Chairman, Z-Wave Alliance (moderator/panel leader)
• Anders Fagerde — Software Development Manager, Silicon Labs; leads Z-Wave software development
• Olivier Boujot — Semtech (inventor of LoRa per panel); Chairman, LoRa Alliance