Im looking for advice regarding my project which I want to migrate to LoRaWAN private network based on Chirpstack.
Currently project works on “raw” LoRa protocol and I want to know will it work as expected after migrating or there would be some restrictions because of switching to LoRaWAN.
Some details about project:
there are some [remote/outdoor/powered-from-battery] LoRa devices with some sensors - temperature, wind, laser, etc., which based on simple Arduino+RMF95 chip - and all communication works on “raw” LoRa protocol.
this remote devices “sleep” almost all time - but every 1 min it wakes up, checks if there is request for it. if not - goes sleep for another 1 min.
But if there is request - prepare data and send this answer and then goes sleep again.
for this project is very important to have ability to send manual “request” for some remote device (by address of device) and after that receive “answer” - so I have one similar LoRa-based device but it is used only for communicating with remote devices.
It is connected to LAN and can send/receive LoRa messages and send it to database.
so we have local device and remove devices.
local device can send requests to desired remote device, wait for answer and redirect answer data into DB.
usually it works on schedule - twice per day it sends requests and receives answers from all remote devices one by one.
Im going to migrate this system to LoRaWAN - change code to use LoRaWAN, implement GW and LoRa Server.
I want to use LoRaWAN because of many reasons - one of them - have some straightforward and standard tech stack for my project which allows me use all advantages of IoT.
But Im not sure if this tech compatible with my requirements - send requests from LAN side to remote LoRa devices. As far I know LoRaWAN works in opposite way - remote devices sends some data time-by-time by itself.
But there is some “downlink” messages from LoRa Server which looks like similar to my “requests” from local device.
But again - this “downlink” messages seems works not like as I need and I dont know if it possible to send this “downlinks” whenever I want.
(As I said - this would be PRIVATE LoRaWAN network in the outdoor location)
So if you still read this please advice - can I switch without big issues or I would need to change a lot in my project processes?
I have a few comments on how this could works / the implication in LoRaWAN.
LoRaWAN does not support end-device to end-device communication, so the idea of having a “local device” ping a “remote device” for info does not work in LoRaWAN. The flow of a LoRaWAN uplink must be device → gateway → server. However, it would seem that your “local devices” could simply be replaced by LoRaWAN gateways.
As for the actual mechanism of requesting info from the remote devices, it depends on what LoRaWAN class you decide you want the end device to be:
Have the remote devices be class C devices. This means that they are listening all the time for potential downlinks, in your device you can have this trigger an uplink. Although this is not typically the ideal use case of LoRaWAN as it will shorten the battery life significantly.
Have the devices be class B devices. That means the device will periodically wake up for downlinks, this seemingly would be the best fit for your project, although I have never used a class B devices myself and they seem to be the least popular for manufacturers. The other thing to keep in mind is that you will have to sort out the correct timing for a downlink, perhaps Chirpstack handles this innately when queueing downlinks for class B devices but I cannot confirm that.
Have the devices be class A devices. That means that the device will only listen for a downlink immediately after it triggers an uplink. You could set your devices to uplink every 15 minutes or so (going down to 1 minute is bad practice for LoRaWAN devices and might violate the regional parameters for airtime), and queue downlinks for your Chirpstack server, that means the server will send the downlink immediately after the devices uplink such that it is listening. This would save the most battery power but would give your devices a slower response time.
You can then program the device such that when it receives a specific downlink it send an uplink with it’s data. From Chirpstack you can “queue” a downlink and it will pass it to the gateway with the best signal for the device you want to downlink to, then when the receive window on the device opens (depending on LoRaWAN class) the gateway will transmit the downlink to the device. From here I believe you all the functionality you are looking for.
It needs to be done both server and device side. I’ve never made my own end device but there are libraries for that. You would likely have to recreate your nodes off of some LoRaWAN package regardless as coding all the end-device intricacies of LoRaWAN yourself would be un-feasable.