Best posts made by bilbolodz

It looks that I've achieved my goal. I'm able dynamically change parent id node (proved in lab) and power level (don't have idea how to check it). You can send V_VAR1 message with number of preferred parent or V_VAR2 with requested power (values: 0 - RF24_PA_MIN, 1 - RF24_PA_LOW, 2 - RF24_PA_HIGH, RF24_PA_MAX) and then REBOOT node (required to changes take effect). Version of sketch reported to controller is changed dynamically depends of set power level.

My "repeater: code bellow:

#define SKETCH_NAME "Repeater Node L1"
#define SV "1.0.1" 
#define MY_RADIO_NRF24
#define MY_REPEATER_FEATURE

int8_t myParrentNodeId;
int8_t myRF24PALevel;

#define MY_PARENT_NODE_ID myParrentNodeId
#define MY_RF24_PA_LEVEL myRF24PALevel

#include <MySensors.h>

#ifndef MY_REPEATER_FEATURE
#define SKETCH_VERSION1 SV
#else
#define SKETCH_VERSION1 SV "R"
#endif

#define SKETCH_VERSION SKETCH_VERSION1 "   "

uint8_t SketchVersion[sizeof(SKETCH_VERSION)];

#define EEPROM_PARENT 0
#define EEPROM_PA_LEVEL 1

void before() {

  int8_t tmpui = loadState(EEPROM_PARENT);
  if (tmpui == 0xFF)
  {
    myParrentNodeId = 0;
  }
  else {
    myParrentNodeId = tmpui;
  }

  memcpy(SketchVersion, SKETCH_VERSION, sizeof(SKETCH_VERSION));

  tmpui = loadState(EEPROM_PA_LEVEL);
  switch (tmpui)
  {
    case 0:
      myRF24PALevel = RF24_PA_MIN;
      memcpy(SketchVersion + sizeof(SKETCH_VERSION) - 4, "MIN", 3);
      break;
    case 1:
      myRF24PALevel = RF24_PA_LOW;
      memcpy(SketchVersion + sizeof(SKETCH_VERSION) - 4, "LOW", 3);
      break;
    case 2:
      myRF24PALevel = RF24_PA_HIGH;
      memcpy(SketchVersion + sizeof(SKETCH_VERSION) - 4, "HIG", 3);
      break;
    case 3:
      myRF24PALevel = RF24_PA_MAX;
      memcpy(SketchVersion + sizeof(SKETCH_VERSION) - 4, "MAX", 3);
      break;
    default:
      myRF24PALevel = RF24_PA_MAX;
      break;
  }
}

void setup()
{

}

void presentation()
{
  //Send the sensor node sketch version information to the gateway
  //sendSketchInfo("Repeater Node L1 MAX", "1.0");
  sendSketchInfo(SKETCH_NAME, SketchVersion);
}

void loop()
{
}

void receive(const MyMessage &message) {
  if (!message.isAck()) {
    if (message.type == V_VAR1) {
      uint8_t tmpui = message.getByte();
      uint8_t tmpui1 = loadState(EEPROM_PARENT);
      if (tmpui != tmpui1)
      {
        saveState(EEPROM_PARENT, tmpui);
      }
    }
    else if (message.type == V_VAR2)
    {
      uint8_t tmpui = message.getByte();
      uint8_t tmpui1 = loadState(EEPROM_PA_LEVEL);
      if (tmpui >= 0 && tmpui <= 3)
      {
        if (tmpui != tmpui1)
        {
          saveState(EEPROM_PA_LEVEL, tmpui);
        }
      }
    }
  }
}

It's already requested feature:

https://github.com/mysensors/NodeManager/issues/73

and it will be done.

Some background information:

I've bunch (over 30) nodes (NRF24) in my garden, there are working as lamp switches. I'm also using message signing. Because of RF range and required good signal quality (signing demands real stable RF network) I'm using repeaters.
In my code I'm using:

int8_t myParrentNodeId;
int8_t myRF24PALelel;

#define MY_PARENT_NODE_ID myParrentNodeId
#define MY_RF24_PA_LEVEL myRF24PALelel

trick to change preferred parent for nodes without needs of having different sketch image for each node and reflashing.

Unfortunately sometimes (because of unknown reason) node changes parent node to some distant repeater node and communication with these node (over "new parent") is very poor. It's also very hard to recover node from such state (reboot command needs signing, signing needs good radio connection, radio link is poor because node is using very distant repeater).

I've some ideas which could be implemented to remedy such situations:

1. Possibility to BLACKLIST some repeaters - it should be a array(?) in RAM/EEPROM which contain IDs of forbidden parents

2. Possibility to declare " MY_PARENT_NODE_IS_STATIC" but with fixed (in RAM or EEPROM) backup parrent ID. It will allow to limit possible parent to two good (in range) nodes but not break connectivity in case of primary parent failure

3. Better RF link quality verification to be 100% sure that whole path to controller is performing well.

4. It could be also a good idea to make possible enable/disable working node "as parent" without recompilation (easier tunning of large Mysensors network).

I'd like to build sensor which answers for "request command" with value for particular sensor. I can catch these message in
void receive(const MyMessage &message) function but questions are:

1. Should I answer for these message in any "special way" or just send a message with sensor value to questioning node using bool send(MyMessage &msg, bool ack) function?
2. Is it save to use send function inside receive function or should I set flag "message to answer" and serve it "in usual way" in loop()?
3. Could someone please clarify a bit meaning of ack parameter? Sometimes I've problems with radio connectivity and I have to find the way to inform controller (Domoticz) that "set command" send to relay was accepted and executed by sensor. Does ack solve my problems?

OK, that's interesting data. Thanks

@mfalkvidd Yes but it's ONLY for "normal version of SMD". Versions with PA have a little different pinout.

@Boots33 I've probably found a bug in Domoticz (beta version). In Setup page I can see that Ack in ON and timeout is 1200ms but it's NOT working (values added from default during device presentation). When I turn off and the on ACK (and save) or change timeout for any other value (and save) "ack detection" start to work (I've got an error without sensor present). Thank you for your help.

Nice plese provide BOM because it's a little unclear which MIC5365/6 should be used

@kalina Thanks.

At the begging quick question: are you sure that all is fine with drills? Some gerber renders in PCB factories show strange results (pcbs.io and oshpark.com).

I've maid a quick research with comparison of cost (I've always took "the cheapest product and shipment option):

• www.seeedstudio.com 10 pcs 4.90 USD + shipment 11.30 USD - (PCB max size 100 mm x 100m)
• pcbs.io 4 pcs 1.50 USD + shipment free (probably problems with drills need to be checked more throughly)
• oshpark.com 3 pcs 1.85USD + shipment free (probably problems with drills need to be checked more throughly)
• dirtypcbs.com "protopack" (at least 10 pcs maybe more) 11.95 USD + 2 USD shipment (PCB max size 50mm x 50m, factory complaining after ZIP upload: "No board outline (.GML/.GKO/.GBR) file found")

Of course it depends of "someone needs" but I think it could be a good idea to prepare "panelized version" with a few pcs of PCB which fits into PCB factory needs (dirtypcbs.com: 5cmx5cm, www.seeedstudio.com 10cmx10cm) for a "batch order" it should be more costs efficient.

It's not quite clear for my how to use MYSBootloader for OTA. I'm running Domoticz as a controller (on RPI) and my gateway also is running on RPI (NRF on GPIO). Should have I one more arduino gateway connected to Windows machine running MYSController? As far I know there could be only one gateway in mysensors network.

@gohan said in Repeatrer level limit (NRF24L01 transport):

You can chain more repeaters.

I've managed to "chain repeaters" so your statement is 100% true Still fighting with range but "there is a hope" for my project.

@hyla You can use function: isTransportReady(). Confirmed working.

Sorry you are right. If you need to check "complete path" fetching time from controller is probably good way to do it.