Implement Forwarding

[Devilbinder]

Implement forwarding to a specific peer.

The release function now takes a parameter that is the peer_mac. This is the data destination. The release function will then send all collected data to that peer.

The default parameter of the release function is NULL. If no parameter is pass to the release function then it will broadcast to all peers including unknow ones that have sent to that particular node. Note: All unknown peers are erased after sending in a "send to all" release.

This can be configure with the macros in the Universal Gateway example fdrs_config.h.

#define ESPNOW_ALL           //send to all know and unknow peers
#define ESPNOW_PEER_1  0x0C  // ESPNOW1 Address 
#define ESPNOW_PEER_2  0x0D  // ESPNOW2 Address

This block in the example determines how data is sent.

#if defined(ESP_SEND)
#ifdef ESPNOW_ALL
  ESPNow.release();
#endif
#ifdef ESPNOW_PEER_1
  ESPNow.release(ESPNOW1);
#endif
#ifdef ESPNOW_PEER_2
  ESPNow.release(ESPNOW2);
#endif
#endif 

This is only for the ESPNOW protocol as per https://github.com/timmbogner/Farm-Data-Relay-System/pull/20

We can have a look at LoRa once we have the ESP working.

Any questions feel free to ask.

[timmbogner]

That looks right. Now to keep configuration simple for novices (a huge priority), maybe we can do something like:

//In the config file
#define ESPNOW_ALL_ACTION         ESPNow.release();
#define ESPNOW_PEER_1_ACTION   ESPNow.release(ESPNOW1);
#define ESPNOW_PEER_2_ACTION   ESPNow.release(ESPNOW2);

//in the sketch... 
#ifdef ESPNOW_ALL
  ESPNOW_ALL_ACTION
#endif
#ifdef ESPNOW_PEER_1
 ESPNOW_PEER_1_ACTION
#endif
#ifdef ESPNOW_PEER_2
 ESPNOW_PEER_2_ACTION
#endif

Basically, I'd like to keep the user configuration method pretty similar to the existing one.

[Devilbinder]

No, what you have shown there is horrific practice. Macros are reserved for constant values that are used regularly or may change at some point and enabling/disabling blocks of code. Only time when a Macro should replace code is, small repetitive routines that need a 1 or 2 parameters changed that a function can't quite solve. There are some other use cases but I don't want to get into it.

Macros that contain code only serve to obfuscate code, not make it more readable.

The current universal gateway is not idea but its only purpose for me is to test compiling with and hopefully make it easy for you. The idea is to replace the examples with something more readable like with the sensors examples. I'd like to outright get rid of the config macros excluding pins and network credentials. After, working as intended confirmation.

[timmbogner]

Gotcha. I see your concern, and am open to a new configuration method. It just has to be really simple. We can talk about that later. I'm testing the gateway again right now... My goal for today and tomorrow is to get the dev branch in shape to be merged. I'm going to add the new sensor example to the root directory with something like _beta after it, and I'm going to move all the new gateway stuff to the Universal Gateway example. I think it's time to remove the '2000' from the names as well. The examples will be left as they are in the main branch for the time being. Andreas's video is still getting a lot of viewers, and I want to play it safe with the examples that he and I designed. If a little more testing goes well, I think I'll make the new sensor code official within a couple weeks.

[timmbogner]

Okay so back to the gateway. It currently gives two "E (274) ESPNOW: Peer interface is invalid" errors. On a quick glance I think esp_now_peer_info_t peerInfo; wants to be in the global scope. I've had issues here before. Even with those errors it should work, but it doesn't as far as I can tell. Debugging isn't functioning so it's tough to know exactly what's going on with it at the moment.

The functionality is also still not quite there as far as I can tell. If I want a gateway that sends serial when it receives ESP-NOW, but sends LoRa when it receives serial, I don't think it is possible in your method. All of the inputs feed into all of the outputs equally, unless I'm misunderstanding something. There is no way to configure individual actions for individual inputs.

[Devilbinder]

Create a PR that should fix that error and get the debugging working again.

On the functionality. Do you want this to run concurrently on one device.

if get ESPNOW:
 send serial

if get Serial
 send LoRa

If on separate devices all that needs to happen is setting the right macros in the fdrs_config.h. For ESP to Serial

 //Where we get the data from
//#define LORA_GET
//#define MQTT_GET
#define ESP_GET
//#define SER_GET  

//Where we send the data to
//#define LORA_SEND
//#define MQTT_SEND
//#define ESP_SEND
#define SER_SEND 

For Serial to LoRa

 //Where we get the data from
//#define LORA_GET
//#define MQTT_GET
//#define ESP_GET
#define SER_GET  

//Where we send the data to
#define LORA_SEND
//#define MQTT_SEND
//#define ESP_SEND
//#define SER_SEND 

[timmbogner]

The first one is what I'm referring to. This is how the system is currently so flexible, and why the code macros make things simpler for me. If we can design a simple configuration syntax (with if/thens) then we would be in better shape.

[Devilbinder]

Is is also per peer?

// X Y Z K replace with whatever number
if get ESP_PEER_Z
   send to serial port X

if get ESP_PEER_K
    send to serial port Y

So the data is collected on a per peer base?

[timmbogner]

Yes. The main use for peers is to have an address to listen for. So you can set very specific routes from gateway to gateway. This route-making isn't used much in any examples because it is largely designed to eventually enable two-way communication. You can send ESP-NOW on ESP32 to another device without adding it to the internal ESP-NOW peer list. If I recall, 8266 lacks this ability? To be honest the internal peer registry for ESP-NOW is still a bit of a mystery.

[timmbogner]

I updated dev branch with what I'm going to merge after work tonight. Let me know if I missed anything.

[Devilbinder]

I'm still working on piping the data from A->B in the gateway.