Nope, not yet.
Downlink isn’t yet implemented.
Is espeasy supported with ttn both ways (download,upload) ?
Are only 8266 or esp32 chips supported?
how about ttgo lora32 board?
I currently only support the RN2483 (and probably the 915 MHz version too, but never tested)
This means the Lora32 board cannot be used unless you run a stack on it yourself and accept exactly the same UART communication as the RN2483 
ESP8266 and ESP32 is supported as both are supported by ESPEasy.
You can either use HW serial, SW serial or even the NXP SC16IS752 I2C to UART bridge.
I (currently) do not process any messages received in the RX window, so you cannot control anything remotely on an ESP via LoRaWAN.
if i use rn2483 and esp8266, is it supported after both espeasy sending and receiving? I would like to send and receive data from lory from mqtt server via esp easy (mqtt client), write back to mqtt
No, you can send data via LoRaWAN on ESPEasy, but you cannot receive data sent by a gateway.
Like I said, I do not process the data received from the gateway within the RX window.
When will it be possible to process espeasy data received from lory?
Until now nobody requested it and I also have no idea how many do use it.
After all it is a rather impopular LoRaWAN module as you cannot buy ready made modules using it and it also doesn’t fit the regular breadboard layout.
I’m a beginner, I liked espeasy. I’m looking for a way to communicate with lorawan (receiving a send). I’m looking for the best way to integrate, the right choice of lorawan chip. I see you have some experience. I’ll let you handle.
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.
Not to forget: when sending downlink messages to a class A node, the node will only be informed and receive the downlink when it sends the next uplink message. The next uplink message may be sent after hours, days or even weeks and the downlink will not be received until after that uplink occurs.
@bluejedi Yep I mentioned it too.
But it may even be worse… The downlink may only be sent by the gateway after the gateway received a message from the node.
So even though you’re sending a message every minute or so, it may take a long time before the intended message is even sent to the node if there’s no gateway receiving the broadcasts from the node.
And even then, there is no guarantee the node received the message sent by the gateway.
1 Like
Which firmware for esp8266 will communicate with RN2483? Is it possible to extract a value from mqtt and send it to lorawan at a defined interval?
Does the latest firmware test with the RN2483 module allow reading the values from the mqtt server and sending them to lorawan? I searched, I didn’t find it.
Sorry, I apparently missed the update notifications on your replies.
You can indeed get numerical values via MQTT import and send them to the TTN controller.
One way of doing it is to fetch them and store them in a dummy task (via rules, triggering on events from the MQTT import task and using taskvalueset to place them in a dummy)
Then if you filled all the spots you need on the dummy (to make the number of TTN messages as low as possible) you can call the taskrun of the dummy and then it will send over the values to the connected controller (e.g. the TTN controller)