I’m taking on a project involving building automation and was wondering where y’all stand when it comes to using LoraWAN switches - it’s a lot less expensive than wired installs where the switches you’re looking to control are scattered all over the area instead of being in one place/room.
I’m really keen on trying LoraWAN for this. From my preliminary testing (I’m using Dragino’s LT-22222-L which is Class C), the relay is able to process approx. 9 out of 10 downlinks, ie. if I send a turn ON/OFF command 10 times, there’s a possibility that it might fail to turn ON/OFF once. The Gateway is in good range (~ RSSI -80; ~SNR 2). I’m wondering why this is happening. I’m having the relay switch uplink its status every 30 sec. (so I know it’s online and connected) - should this interval be a lot higher? Will this affect the Rx window even though the device is of Class C type? Is the relay failing because it’s uplinking status way too often and so might miss the downlink when it’s uplinking?
I’m planning on doing a commercial install so I want to make sure it’s as close to 100% perfect as can be. I’m using Home Assistant and Chirpstack to send downlink commands over MQTT.
Has anyone used/installed LoraWAN switches before? Are commercial buildings even doing LoraWAN for controls? If yes, what are some of the best practices other than ensuring the Gateway is in good range.
Typically lorawan is meant to be used much more for uplinks than for downlinks, and I think many people in the field would tell you that it is designed for monitoring rather than control. That’s because it is an innately lossy protocol, and because most gateways / regions are designed with only 1 downlink channel and multiple uplink channels.
Regardless as long as you don’t have an absurd amount of devices you definitely should be able to do this.
The devices really have no point to be uplinking that frequently though. Depending on your region this might affect downlinks and increase chance of a collision, not to mention reducing battery life. What you probably should do though is enable confirmed downlinks, this will guarantee the server will send another downlink if the device fails to respond to the first.
Ah I see - bummer about most gateways using just the one downlink channel.
I’ll looking at approx. 30-40 relays. Does this qualify as being absurdly high?
These relays that I’m using utilize mains power, so fortunately I don’t have any battery life restrictions. I’m going to increase the uplink frequency to 30 mins. then, just to avoid collisions. I’m not sure how the region I’m in affects collision chances?
I did take a look at my Local Chirpstack Server (running on Seeed’s SenseCap M2 Indoor Gateway) - I can see there’s a time limit within which Chirpstack acknowledges confirmed downlinks as false (in case end node fails to confirm). However, I don’t see any option enabling retries. I didn’t know Chirpstack could do that. I was considering using Home Assistant for that purpose - to check if downlinks were successful and do retries if unsuccessful. Another approach I’m considering involves sending each downlink command 3 times consecutively (unconfirmed and with a delay of 8 seconds between each downlink). This way there’s a very small chance device won’t receive.
For example, eu868 uses the same frequency range for uplinks and downlinks, so devices that are uplinking often could send on the same frequency / timing as a downlink. Whereas in us915 uplinks and downlinks use different frequencies.
Selecting confirmed is a much better option than just repeating a downlink 3 times. This will guarantee the device gets the message with as few downlinks as possible. There is also a confirmed variable if you are using gRPC or MQTT to trigger downlinks.
Ah ok. I’m doing in865 for this project - similar to eu868 where rx1 downlink channels = uplink channel frequencies. So there’s the possibility of collisions. The thing about this dragino relay is : it uplinks a payload 2-3 seconds after the downlink. This payload is like any regular payload (whose frequency I said I’d change to 30 min.). It’s separate from the confirmed ack payload you’re referring to. So with confirmed downlink enabled, I get 2 separate uplinks within 2-3 seconds - the regular looking one (with the updated relay status value) and an ack with the true val. The former I just cannot seem to disable and so I’m using the updated relay status value it sends as an indicator of downlink success. I feel like the thing might malfunction if I spam confirmed downlink msgs.
Downlinks use inverted polarity from uplinks, so there is no collission between uplinks and downlinks. They will likely become noise to each other. RX2 may have a different centre frequency from RX1 channels.
Note that the RSSI seen in Chirpstack refers to the measurement made by the LoRa gateway, not the node. The node typically has less sensitivity and the RF performance there could be worse.
Please consider not using such an often uplink rate as there is only so much bandwidth and LoRaWAN is ALOHA like. Meaning that there is no nechanism to avoid collissions and sending more uplinks could cause the important messages to be lost.
LoRaWAN does not guarantee delivery on its own. Your application should retry as required and this should factor in the behaviour of the device.
Since it is a relay, I suppose it should send an uplink to confirm the switch in relay state?
One thing you could evaluate, is whether there are already many LoRaWAN frames flying over your selected frequencies. If so, do consider using another set of channels (aside from the fixed ones) if there is bandwidth to create more channels.
Since your devices are class C, you can adjust the RX2 datarate to fit your deployment. Gateways based on the SX1301 are half-duplex. So while it transmits, it cannot receive. The default for RX2 tends to be some low datarate like DR0, which results in long air time and this may result in missing responses when commanding a group of devices with unicasting. Personally, I use SF9BW125 (DR3 in AS923), from experience and because some big-name LNS services also use this. Whether DR3 is too high for you or not, depends on the site conditions and design.
Finally, if you will do group control and the device supports multicasting, do consider exploring the use of multicast for downlink commands to groups of devices.
Based on you guys’ responses, I changed uplink rate to once every 6 hours lol.
Since it is a relay, I suppose it should send an uplink to confirm the switch in relay state?
Yes, I get an uplink 2-3 seconds right after (with the status of the switch updated) if the downlink’s successful.
Since your devices are class C, you can adjust the RX2 datarate to fit your deployment. Gateways based on the SX1301 are half-duplex. So while it transmits, it cannot receive. The default for RX2 tends to be some low datarate like DR0, which results in long air time and this may result in missing responses when commanding a group of devices with unicasting. Personally, I use SF9BW125 (DR3 in AS923), from experience and because some big-name LNS services also use this. Whether DR3 is too high for you or not, depends on the site conditions and design.
I’m using Seeed’s SenseCap M2 Indoor Gateway that’s based off SX1302. I don’t know if this is half-duplex. But I have observed - there are times where the relay turns on/off the load and the uplink that it sends right after (the one I mentioned above in my reply here) fails to get through. So I wait until the next regular/periodic uplink to know if my downlink was successful (by checking to see if the relay status changed). My guess is that SX1302 is half duplex and that these packets go missing because the gateway’s still transmitting - just like you mention. Here I see that the downlink data rate for the frequency plan I’m using is indeed low (well, kind of @SF10). Luckily I can change this (this manual shows how), but there’s no downlink command for it I’ll have to manually plug it into the laptop at the site sigh.
One another thing I’m considering doing is sending the same command * 4 to a single device, but just once. Eg. Sending 4 turn ON commands at one instant. Will this work? I’m guessing the relay would then process only 1 or 2 of these since they’ll be arriving at the same instant (almost)?
I’ll have to manually plug it into the laptop at the site sigh.