Can we use LORAWAN to control lights in our houses?


Hi all,

I was going through a review on and came across below link on TTN where it say
that LORAWAN can not be used for controlling lights in houses?

Is there any specific reason , why we can not use it? I was thinking of experimenting with one such use case with TTN?

Downlink to SX1276 using Arduino LMiC
(Arjan) #2

Technically you could, though on TTN you might only be able to send 10 "downlink" messages per day to nodes (which would then control your lights).

However, I think the major question is: why would you do this? At home, you've got WiFi, or Bluetooth, or you can set up some other hub to connect things to the internet. And you surely don't need long range to connect to the internet. I feel LoRaWAN is the solution for sensors in places where the user is not around with some internet-connected device. Your bike, parked somewhere in the city: yes. Some device you're wearing while also carrying an internet-connected phone: nah.


Thanks @arjanvanb for your reply.Yes , I understand it does not make much sense to use LORAWAN for controlling lights in our houses.I was wandering , if it will be really possible to use LORAWAN for managing street lights in a town/city or a big commercial/industrial complex based on this downlink restrictions? Also , can we use TTN in multicast mode?

LoraWan controlling street lights

TTN, and most of the other operators I heard of, currently only implements class A devices.
With class A, a node is mainly meant to have upstream traffic (from node to network). It is possible to send downstream messages but the node only listens for this exactly 1s after sending an upstream message.

So controlling lights with LoRaWAN (on current networks) means that all nodes have to send messages in order to be able to receive a message. This means that you can only change the state of the node (light on/off) when the network received a message from the node.
If I push a button to switch my lights on, I want them to respond now, not in 2 minutes ...

With class C, nodes are in "listen always mode" and the network may send a message to a node at any time.
Still, with 10 nodes, you need to send 10 messages - one for each node. This is a relatively slow process and since a gateway has the same 1% duty cycle limitation that nodes have, you are limited in the amount of nodes and messages per node.
Let's say one message takes 0.25s (not the fastest and no the slowest data rate).
With one gateway controlling 1000 nodes it takes 250s to send a message to all nodes. After this, the gateway has to wait 24,750s before it is allowed to send another 1000 messages. That's almost 7 hours :open_mouth:

So even technically, controlling lights through a public gateway is not possible. With a private network and 20 lamps: 20 * 0.25 = 5s to switch all your lamps on. But after this you have to wait 8.5 minutes before you may switch them off again. Best case this goes down to about 2 minutes.

So I fully agree with the TTN limitations.

Real time switching: No
Managing: Yes
You could send messages to the lamps given them the schedule for switching on/off the next day. You could also use this to inform the operator about the burning time and light level of a lamp - allowing the operator to schedule maintenance.

They drive through town a few times a year to check all street lights. Integrating LoRaWAN nodes in each light to monitor performance and plan maintenance saves a lot of money.

(Hylke Visser) #5

LoRaWAN is meant for long range, wide area networks. There are many technologies that are better suited for smart homes and smart offices (Bluetooth/ZigBee/Z-Wave). The Things Gateway will also include a Bluetooth 4.2 Low Energy chip so that we will be able to support smart home applications in the future.

The LoRaWAN specification does include multicast for Class B devices, which could be used for the streetlight use case.

12.2 Unicast & Multicast MAC messages
Messages can be “unicast” or “multicast”. Unicast messages are sent to a single end-device and multicast messages are sent to multiple end-devices. All devices of a multicast group must share the same multicast address and associated encryption keys. The LoRaWAN Class B specification does not specify means to remotely setup such a multicast group or securely distribute the required multicast key material. This must either be performed during the node personalization or through the application layer.

However, TTN does not support this.


good thinking ! :grinning:


Thanks @Rob65 for your deep thought on this topics. It makes sense and is now clear to me.


Thanks for clarification Hulke. Is it possible to be added to the TTN roadmap?
Does anybody know if KPN is going to support uni-/multicast?

(Hylke Visser) #9

I think this will be quite difficult for Class B devices, because then we'd have to time-synchronize all gateways (which are not in our control). But we might be able to build support for this for Class C devices, although I wouldn't expect it any time soon.

(Xandcapcom) #10

LoRa would be very useful for home automation, from my point of view. We can use to control windows and doors sensors in a very large house, with low power consumption, and could have a centralized gateway to the automation system. Leaving the wifi router separate from automation. We have long range, low power consumption and safety. No need to use the TTN network, a LoRa server can be made. Leaving out of the limit of 10 messages per day.

I’m sorry for my English

(Hylke Visser) #12

sure, you could use LoRaWAN for home automation. LoRa SF7 or FSK 50kbit modulation don’t consume too much airtime. TTN currently doesn’t really do FSK, but we might in the future. Also, if you have a private server you won’t have the fair access policy that we have in the public community network, but you’d have to pay for your own server of course, and you’d still have to be compliant with the regulations in your country.

On the other hand, there are many other home automation technologies that have already been used for years, so if you want something that “just works” I think it would be better to look at those.