Help LoRa and peers

[Stips5]

Hi

I have following setup

sensor -> (esp-now) -> gateway1 -> (lora) -> gateway2 -> (mqtt) -> mqtt server

Sensor sends data successfully to gateway1 which sends it to gateway2 and there problem occurs, inside gateway in fdrs_functions.h in line 334 or if (memcmp(&packet, &selfAddress[3], 3) == 0) { there seems to be problem, execution never passes this condition, and I don't know why.

I have following config

sensor

#include <fdrs_globals.h>

#define READING_ID    1   //Unique ID for this sensor
#define GTWY_MAC      0x01 //Address of the nearest gateway

#define USE_ESPNOW
//#define DEEP_SLEEP
//#define POWER_CTRL    14
#define DYNAMIC_GTWY
#define FDRS_DEBUG
#define DEBUG_CONFIG 

gateway1

// #include <fdrs_globals.h>
#define FDRS_DEBUG     //Enable USB-Serial debugging

#define UNIT_MAC     0x01  // The address of this gateway
#define DEBUG_CONFIG

// Actions -- Define what happens when a packet arrives at each interface:
// Current function options are: sendESPNOW(MAC), sendSerial(), sendMQTT(),
//  bufferLoRa(interface), bufferESPNOW(interface), bufferSerial(), and bufferMQTT().

#define ESPNOWG_ACT  sendSerial();   bufferLoRa(0);
#define SERIAL_ACT         
#define MQTT_ACT          
#define LORAG_ACT      sendSerial();

#define USE_LORA
//#define USE_WIFI      //Used only for MQTT gateway

// Peer addresses
#define ESPNOW1_PEER  //0x0E  // ESPNOW1 Address 
#define ESPNOW2_PEER  //0x0F  // ESPNOW2 Address
#define LORA1_PEER    0x00  // LoRa1 Address
#define LORA2_PEER    //0x00  // LoRa2 Address

// Peer Actions
#define ESPNOW1_ACT
#define ESPNOW2_ACT               
#define LORA1_ACT
#define LORA2_ACT 

gateway2

#define FDRS_DEBUG     //Enable USB-Serial debugging
#define DEBUG_CONFIG

#define UNIT_MAC     0x00 // The address of this gateway

// Actions -- Define what happens when a packet arrives at each interface:
// Current function options are: sendESPNOW(MAC), sendSerial(), sendMQTT(),
//  bufferLoRa(interface), bufferESPNOW(interface), bufferSerial(), and bufferMQTT().

#define ESPNOWG_ACT
#define SERIAL_ACT
#define MQTT_ACT
#define LORAG_ACT sendMQTT();

#define USE_LORA
#define USE_WIFI      //Used only for MQTT gateway

// Peer addresses
#define ESPNOW1_PEER // 0x0E  // ESPNOW1 Address 
#define ESPNOW2_PEER  //0x0F  // ESPNOW2 Address
#define LORA1_PEER  //  0x01  // LoRa1 Address
#define LORA2_PEER    //0x01  // LoRa2 Address

// // Peer Actions
#define ESPNOW1_ACT    
#define ESPNOW2_ACT                    
#define LORA1_ACT   bufferMQTT();
#define LORA2_ACT

When I remove if condition then MQTT message is received. Also I would like to have more documentation about using peers, do I when do I need to use it.

Thanks

[timmbogner]

Hey, thanks for reaching out! I'll have more time to really look at this in a day or two, but my preliminary note is to try changing: bufferLoRa(0) to bufferLoRa(1) in gateway1 to direct packets to the address defined LORA1, and maybe... bufferMQTT() to sendMQTT(). in gateway2 if you don't have that buffer set up right.

In the newest version of FDRS I have changed the use of "peers" to "neighbors". There is some documentation in the gateway readme. I definitely need to get more documentation for both that and the bufferLoRa() function, because bufferLoRa(0) uses a LoRa broadcast packet, which I'm not sure is even implemented anymore, tbh. There might also be incompatibilities with old FDRS LoRa devices, so make sure you re-flash all of your LoRa gateways if you update.

Let me know if any of this helps. Thanks for trying out FDRS!

[Stips5]

Hi Yes, I've tried using bufferLoRa(1) on gateway1 but then packetSize is always 0 in int packetSize = LoRa.parsePacket(); so that didn't work. Also yes #define LORA1_ACT bufferMQTT(); is not needed here, it works without it I guess its leftover. So in conclusion I still didn't manage to fix it, and I still have problems understanding peers/neighbors, when to use them? do I need them here?...

Also back to initial problem, I've noticed that

    DBG("my addr");     
    DBG(UNIT_MAC);    //here I got 0 as expected
    DBG("Incoming LoRa.");
    DBG(selfAddress[3]);  // here I got 221
    DBG(*packet);   // here I got 225

    if (memcmp(&packet, &selfAddress[3], 3) == 0) {   //Check if addressed to this device  

Also why would I use bufferLoRa(1) if I my receiveing gateway address is 0? I also wounder why selfAddress[3] is always same value, even if I change UNIT_MAC value, which is 221 whatever I do, which is value from MAC_PREFIX (0xDD) but dont understand why.

Thanks for reply, I like your project, but I would like to understand it better.

[Stips5]

Hi, I've updated my fdrs version to newest one, and now there is

gateway 1

Buffering LoRa.
Releasing LoRa.
Transmitting LoRa message of size 20 bytes with CRC 0xe4b7 to LoRa MAC 0xffff

gateway 2

Packet Address: 0xffff Self Address: 0xee0
Incoming LoRa packet of 20 bytes received from address 0xee01 destined for node address 0xffff

config gateway 1

#define FDRS_DEBUG     //Enable USB-Serial debugging
#define DEBUG_CONFIG // Displays full config info on startup

#define UNIT_MAC     0x01  // The address of this gateway

#define ESPNOWG_ACT  sendSerial();   bufferLoRa(0);
#define SERIAL_ACT         
#define MQTT_ACT          
#define LORAG_ACT      sendSerial();

#define USE_LORA
#define USE_ESPNOW
//#define USE_WIFI      //Used only for MQTT gateway

// Peer addresses
#define ESPNOW_NEIGHBOR_1  0x0E  // ESPNOW1 Address 
#define ESPNOW_NEIGHBOR_2  0x0F  // ESPNOW2 Address
#define LORA_NEIGHBOR_1    0x00  // LoRa1 Address
#define LORA_NEIGHBOR_2    0x00  // LoRa2 Address

// Peer Actions
#define ESPNOW1_ACT sendSerial();
#define ESPNOW2_ACT               
#define LORA1_ACT
#define LORA2_ACT 

//Pins for UART data interface (ESP32 only)
#define RXD2 14
#define TXD2 15

// SPI Configuration -- Needed only on Boards with multiple SPI interfaces like the ESP32
#define SPI_SCK 15
#define SPI_MISO 18
#define SPI_MOSI 23

// LoRa Configuration -- Needed only if using LoRa
#define LORA_SS 5
#define LORA_RST 14
#define LORA_DIO0 2

#define LORA_BAND 433E6
#define LORA_SF 7
#define LORA_TXPWR 17       // LoRa TX power in dBm (+2dBm - +20dBm), default is +17dBm.  Lower power = less battery use

// Buffer Delays - in milliseconds - Uncomment to enable any buffer

#define LORAG_DELAY    5000

#define PEER_TIMEOUT 300000

config gateway 2

#define FDRS_DEBUG     //Enable USB-Serial debugging

#define UNIT_MAC     0x00 // The address of this gateway

#define ESPNOWG_ACT         
#define SERIAL_ACT      
#define MQTT_ACT            
#define LORAG_ACT       sendSerial();    sendMQTT();

#define USE_LORA
#define USE_WIFI      //Used only for MQTT gateway

// Peer addresses
#define ESPNOW_NEIGHBOR_1  0x0E  // ESPNOW1 Address 
#define ESPNOW_NEIGHBOR_2  0x0F  // ESPNOW2 Address
#define LORA_NEIGHBOR_1    0x00  // LoRa1 Address
#define LORA_NEIGHBOR_2    0x00  // LoRa2 Address

// // Peer Actions
#define ESPNOW1_ACT    
#define ESPNOW2_ACT                    
#define LORA1_ACT
#define LORA2_ACT

// LoRa Configuration -- Needed only if using LoRa
#define LORA_SS 5
#define LORA_RST 0
#define LORA_DIO0 4

//433E6 for Asia
//866E6 for Europe
//915E6 for North America
#define LORA_BAND 433E6
#define LORA_SF 7
#define LORA_TXPWR 17       // LoRa TX power in dBm (+2dBm - +20dBm), default is +17dBm.  Lower power = less battery use

#define PEER_TIMEOUT 300000

// MQTT Topics
#define TOPIC_DATA "fdrs/data"
#define TOPIC_STATUS "fdrs/status"
#define TOPIC_COMMAND "fdrs/command" 

[timmbogner]

Thanks for updating, the extra debug info gives me a good idea of what's up. The parameter that is passed with bufferLoRa() is not the address of the device, it is meant to be either 1 or 2. If it is 1, the data will be sent to the address you have defined with LORA_NEIGHBOR_1. 2 will send it to LORA_NEIGHBOR_2. A parameter of 0 sends the data to the address 0xFF, which will perhaps be used for broadcast packets in the future. For the time being, bufferLoRa(0) is not used in FDRS.

gateway1:

#define FDRS_DEBUG     //Enable USB-Serial debugging
#define DEBUG_CONFIG // Displays full config info on startup

#define UNIT_MAC     0x01  // The address of this gateway

#define ESPNOWG_ACT  sendSerial();   bufferLoRa(1);
#define SERIAL_ACT         
#define MQTT_ACT          
#define LORAG_ACT      sendSerial();

#define USE_LORA
#define USE_ESPNOW
//#define USE_WIFI      //Used only for MQTT gateway

// Peer addresses
#define ESPNOW_NEIGHBOR_1  0x0E  // ESPNOW1 Address 
#define ESPNOW_NEIGHBOR_2  0x0F  // ESPNOW2 Address
#define LORA_NEIGHBOR_1    0x00  // LoRa1 Address
#define LORA_NEIGHBOR_2    0x0E  // LoRa2 Address

#define LORA1_DELAY    1000

// Peer Actions
#define ESPNOW1_ACT sendSerial();
#define ESPNOW2_ACT               
#define LORA1_ACT
#define LORA2_ACT 

//Pins for UART data interface (ESP32 only)
#define RXD2 14
#define TXD2 15

// SPI Configuration -- Needed only on Boards with multiple SPI interfaces like the ESP32
#define SPI_SCK 15
#define SPI_MISO 18
#define SPI_MOSI 23

// LoRa Configuration -- Needed only if using LoRa
#define LORA_SS 5
#define LORA_RST 14
#define LORA_DIO0 2

#define LORA_BAND 433E6
#define LORA_SF 7
#define LORA_TXPWR 17       // LoRa TX power in dBm (+2dBm - +20dBm), default is +17dBm.  Lower power = less battery use

// Buffer Delays - in milliseconds - Uncomment to enable any buffer

#define LORAG_DELAY    5000

#define PEER_TIMEOUT 300000

In the second gateway you don't need to set up neighbors, but you can. If you were to set #define LORA_NEIGHBOR_1 0x01, then the data would be received by the #define LORA1_ACT macro.

Here I DON'T use neighbors, so packets originating from gateway1 are just treated as general LoRa packets. gateway2:

#define FDRS_DEBUG     //Enable USB-Serial debugging

#define UNIT_MAC     0x00 // The address of this gateway

#define ESPNOWG_ACT         
#define SERIAL_ACT      
#define MQTT_ACT            
#define LORAG_ACT       sendSerial();    sendMQTT();

#define USE_LORA
#define USE_WIFI      //Used only for MQTT gateway

// Peer addresses
#define ESPNOW_NEIGHBOR_1  0x0E  // ESPNOW1 Address 
#define ESPNOW_NEIGHBOR_2  0x0F  // ESPNOW2 Address
#define LORA_NEIGHBOR_1    0x0E  // LoRa1 Address
#define LORA_NEIGHBOR_2    0x0F  // LoRa2 Address

// // Peer Actions
#define ESPNOW1_ACT    
#define ESPNOW2_ACT                    
#define LORA1_ACT
#define LORA2_ACT

// LoRa Configuration -- Needed only if using LoRa
#define LORA_SS 5
#define LORA_RST 0
#define LORA_DIO0 4

//433E6 for Asia
//866E6 for Europe
//915E6 for North America
#define LORA_BAND 433E6
#define LORA_SF 7
#define LORA_TXPWR 17       // LoRa TX power in dBm (+2dBm - +20dBm), default is +17dBm.  Lower power = less battery use

#define PEER_TIMEOUT 300000

// MQTT Topics
#define TOPIC_DATA "fdrs/data"
#define TOPIC_STATUS "fdrs/status"
#define TOPIC_COMMAND "fdrs/command"

My LoRa modules are broken, but I have another pair on the way. Hopefully these changes fix things, please keep me posted!

Neighbors used to be a little more integral to the system. They are now mostly used for repeaters. Say you have device 0x02, in line between 0x01 and 0x03. You want device 0x02 to send packets it receives from 0x03 and give them straight to to 0x01, and vice versa. You would accomplish this by setting it up like this: (EDITED to show both LoRa and ESP-NOW)

// Neighbor addresses
#define ESPNOW_NEIGHBOR_1 0x01  // ESPNOW1 Address 
#define ESPNOW_NEIGHBOR_2 0x03  // ESPNOW2 Address
#define LORA_NEIGHBOR_1    0x01  // LoRa1 Address
#define LORA_NEIGHBOR_2    0x03  // LoRa2 Address

// Neighbor Actions
#define ESPNOW1_ACT    bufferESPNOW(2);
#define ESPNOW2_ACT    bufferESPNOW(1);                
#define LORA1_ACT   bufferLoRa(2);
#define LORA2_ACT   bufferLoRa(1);

#define ESPNOW1_DELAY  0
#define ESPNOW2_DELAY  0
#define LORA1_DELAY  1000
#define LORA2_DELAY  1000

I'm really seeing that I need to update the way I use buffers. There also needs to be a sendESPNOWneighbor(1) function that doesn't use buffers. They make things less intuitive, sorry bout that. It's just how the project has evolved.

Let me know if this is clear, or any suggestions you have to improve.

[Stips5]

Thanks, now peers/neighbors are much more clearer to me know. Now it works. Also is there in plan some kind of sensor-gateway mix which would act like gateway but could send some readings or it breaks modularity

Thanks

[timmbogner]

My current idea for integrating nodes and gateways is to add serial as an IO source for user nodes. This will let the user send sensor readings over the serial port to an attached gateway.

Adding extra responsibilities to gateway devices themselves seems a little risky to me at this point in my knowledge, but it might become more feasible if I study RTOS someday.

Glad you've got it going! Let me know how it works out! Edited some wording.

[nglessner]

I'm not sure about @Stips5 but the reason I wanted this feature is to send the voltage (battery level) of the repeater.

[Stips5]

I'm not sure about @Stips5 but the reason I wanted this feature is to send the voltage (battery level) of the repeater.

Yes, exactly, it would be useful to be able to append message by header or something where gateway would add some of its info, but I understand @timmbogner concerns where this could lead. Also due to power saving it would be sometimes useful to measure eg. temp and humidity + battery status on gateway without needing to power additional sensor just to make measurements.

[timmbogner]

Aye, I see what you guys mean now! That seems like something that can be worked into the system.

I'll have to investigate how I could standardize this. If I'm not mistaken, the code for it will vary with hardware. (voltage monitoring, that is)

[Stips5]

I think we can close this issue, and rise another one for this new feature