Can You Use LoRaWAN for Light Switches?

Someone asked me this recently, and it is a good question because the answer is not a flat no. It is more nuanced than that, and understanding why tells you something useful about what LoRaWAN is actually for.

The short version: LoRaWAN can control things, but it is not designed for anything where responsiveness matters. A light switch that takes a second or two to respond is not a light switch anyone wants to use. So for that specific use case, no. But the longer answer is worth working through, because there are actuator scenarios where LoRaWAN is entirely the right choice.

What LoRaWAN is optimised for

LoRaWAN is a low-power wide-area network protocol. Every design decision in it is oriented around two goals: long range and long battery life. It achieves both by being extremely sparing with radio time. Devices transmit small packets infrequently, the network acknowledges them, and the device goes back to sleep. A soil moisture sensor running on two AA batteries for three years is exactly what this protocol was built for.

The tradeoff is that communication is mostly one-directional and inherently slow. Uplinks (device to network) are easy. Downlinks (network to device) are constrained, and that constraint is what makes real-time control difficult.

The duty cycle problem

LoRaWAN operates in unlicensed spectrum, and unlicensed spectrum comes with duty cycle restrictions. In Europe, most devices are limited to transmitting for 1% of the time on a given channel. In practice this means a device that just sent a packet may have to wait tens of seconds before it can send another. The network side has similar constraints.

For a sensor reporting every 15 minutes, this is completely irrelevant. For a light switch where you expect an immediate response, it matters enormously.

Class A, B, and C

This is the part of the spec that determines whether you can actually send commands down to a device at all, and how quickly.

Class A is the default and by far the most common. A Class A device only opens a receive window after it has sent an uplink. If it transmits every 10 minutes, you can only reach it in the brief window after one of those transmissions. You cannot push a command to it on demand. This rules out interactive control entirely.

Class B devices open additional receive windows on a schedule synchronised to the network’s beacon. You can reach them more predictably, but still not instantly, and the added radio activity increases power consumption.

Class C devices keep a receive window open almost continuously, only closing it while transmitting. This means you can send a downlink command at any time and it will be received within a second or two. The problem is that this requires the device to be powered constantly. The battery life advantage of LoRaWAN disappears entirely.

A Class C LoRaWAN relay controlling a mains-powered device is technically viable. It is just not obviously better than the alternatives.

So why not just use it anyway?

If you already have a LoRaWAN gateway running, the marginal cost of adding another device is low. The question is whether LoRaWAN is the right protocol for the job, not just whether it is possible.

For a light switch inside a building, the honest answer is no. Zigbee and Z-Wave exist precisely for this use case. They have sub-second response times, they are designed for mesh networking inside buildings, and the hardware ecosystem is mature. Thread and Matter are pushing this further. Any of these protocols will give you a better experience for indoor switching than LoRaWAN, at lower cost and complexity.

The argument for LoRaWAN collapses even further when you consider that most buildings already have Wi-Fi. A Wi-Fi or Zigbee light switch does not require you to run any additional infrastructure at all.

Where LoRaWAN actuators do make sense

The protocol earns its place when you need to control something that is beyond the reach of your local network, and where a second or two of latency is acceptable.

The clearest examples are things like irrigation valves in a large garden or allotment, gate or barn door controllers on a rural property, pump controllers for a water tank or borehole, and ventilation or heating toggles in an outbuilding. In all of these cases, the device is too far away for Zigbee or Wi-Fi, it is mains powered so Class C is an option, and nobody cares if the valve takes two seconds to open after you tap a button in Home Assistant.

This is a legitimate and useful set of scenarios. It is just a different set from the one most people picture when they ask about light switches.

The honest summary

LoRaWAN is a sensing protocol that can also control things, under the right conditions. It is not a home automation protocol that happens to have long range. If you approach it as the former, it makes sense for a specific set of actuator use cases. If you approach it as the latter, you will spend a lot of time fighting against what it was designed to do.

For light switches inside your house: Zigbee. For the pump in the field at the bottom of your garden: LoRaWAN might be exactly right.