Receiving data in ESPEasy from a gateway does require quite a bit more compared to just sending data.
Sending data via an RN2483 is simple as the LoRaWAN stack running in that module does all the checks for you, like making sure you don’t exceed the 1% allowed air time for example.
The worst that can happen is that your device in the field is not allowed to send for a while.
But supporting sending data back to ESPEasy via LoRaWAN does add some complexity as it isn’t your device that may hit its 1% air time limit when sending data back, but it is the gateway that happens to be closest to your node.
As soon as I add support for “downstream” data to ESPEasy, people will start using it.
So I must find a way to make it easy to use (hence the name ESPEasy) but still discourage users to send lots of data to the ESP in the field.
Sending data to 1 device from a gateway does not differ a lot from receiving data by ESPEasy sent by the gateway.
However, there will probably not be this 1-to-1 relationship so you will have a number of nodes serviced by the same gateway and that gateway also has to obey to this 1% rule.
This means there must be a way to naturally keep this ratio of send/receive at around 100:1 for normal use cases in ESPEasy.
To add to this complexity, you simply cannot just send data to a node and expect it to receive the message within seconds.
Data sent to a node in the field can only be sent 1 second after this node has sent a message to the gateway. Hence the name “RX window”.
The LoRaWAN radio has to listen for a while after sending to make sure it does receive data sent from the gateway.
So you really have to think about what you want to send to the LoRaWAN device out there.
If it is a command like “turn on the light” then it will probably be not very useful as that has to be done “right now”.
But if it is a command like “Turn on the light every day at %sunset+10m%” then it may be useful to send via LoRaWAN.