Why did I need to modify FDRS  ?

In FDRS library, Devices are classified into two types: Gateways and Nodes. 

• Gateways comprise the infrastructure of the network, moving data along pre-directed routes and providing coverage to all devices. 
• Nodes allow the user to exchange data with a gateway.

Gateways and nodes are physically independant devices. Thus for a simple 3 devices Rezodo network I would have to deploy 5 devices if working with genuine FDRS library.

I discussed a lot with Timm and understood his motivations to stay with his concept (gateways/nodes). But as I had already manufactured my boards, I decided to modify FDRS to open a little its API for a Gateway to be both acting as gateway and node.

Timm is currently reviewing my modifications and will decide to merge them(or not!) into FDRS master.

Meanwhile we will try to enter (a little) into FDRS inner working.

FDRS inner working

Bear in mind that I will not at all cover the explaination of "FDRS nodes" as I will not use them with my mods...

However you should start to read the very good documentation writen by Timm:

• FDRS general principles 
• FDRS gateways

As I will mostly use the networking layer of FDRS it is important to understand of it works.

FDRS is internally exchanging binary messages which are arrays of "dataReadings"

typedef struct __attribute__((packed)) DataReading {
  float d;
  uint16_t id;
  uint8_t t;
} DataReading;

As such messages include:

• the data payload (d) as a 32bits float number
• the identifier (id) as a 16 bits unsigned integer number
• the type (t) as a 8 bits unsigned integer

A single message is addressed by gateways to any node willing to get this id message.

Routing message from gateway to gateway will be explained later. But for now remember that a gateway has a unique "MAC address" which is a 8 bits integer number.

In the current implementation of FDRS it is not possible to address a control message to a gateway.

My modification will try to perform this task without damaging the FDRS library has it is today.

I adopted the following conventions which are important to follow for my mods to work:

• the master gateway will always have the address 0,

//  GATEWAY CONFIGURATION
//Addresses
#define UNIT_MAC           0x00  // The address of this gateway

• control messages will go from this gateway GTW0 to the others "down to the right one" (example "open valve 1 on GTW2")
• sensor data will go up from the gateways to the GTW0 and then to IoT platforms (explained later)

To allow extra behavior of FDRS I have modified the library to expose messages into the user writen code of the gateway.

//FDRS
#include "fdrs_gateway_config.h"  //https://github.com/timmbogner/Farm-Data-Relay-System
#include <fdrs_gateway.h>
extern DataReading myCtrlData[256];
extern uint8_t myCtrl;

As you can see extern variables are now accessible containing myCtrlData array of messages (dataReading type). The myCtrl variable gives the number of received messages to be read.

To allow identifying the destinee gateway for a CtrlMessage, I simply use half of the id (high byte) to pass the GTW  MAC address and the low byte to pass the message id.

so if you want to send a message to GTW 2 with a Ctrl_id of 3 you will write something similar to 

  uint8_t GTW =2;
  unint8_t Ctrl_id = 3;
  uint16_t id;
  unint8_t t = 255;
  id = (GTW << 8) + Ctrl_id;
  float data = 333.0;
  //loadFDRS(float data, uint8_t type, uint16_t id);
  loadFDRS(data, t, id); //will load message into FDRS 
  sendFDRS();            //send data using INTERNAL_ACT event.

And when the message will arrive at destination you will have to read it into a loop and trigger relevant action: 

 if (myCtrl > 0) //we have received at least a control message for this gateway
  {
    for (int i = 0 ; i < myCtrl; i++) //for each control message
    {
      int id = myCtrlData[i].id >> 8;                 //extract the GTW id
      int index = myCtrlData[i].id & 0xFF;            //extract the Control Identifier
      myCtrlData[i].id = 0x8000;                      //reset the id to unused value (eat the message)
      if (id == UNIT_MAC)                             // if the message is for this gateway
      {
        switch (index)
        {
          case 1:  //do something with type and data
            DBG(myCtrlData[i].t);
            DBG(myCtrlData[i].d);
          break;
        }
      }
      myCtrl = 0;   //reset the message counter     
    }