Why do "passive nodes" need to set their Node ID manually?

[NeverDie]

I have two sensor nodes, both running the same code (https://www.openhardware.io/view/510/CR2032-Small-Wireless-Temperature-Humidity-Sensor#tabs-source ). I thought that the gateway's job was to assign them each a unique ID. However, what instead seems to be happening is that they have both had their nodeID set to 100, whereas they should have separate ID's.

Please advise.

[mfalkvidd]

@NeverDie a gateway will never assign an id to a sensor node. That's the controller's job.

But since your sketch has this

#define MY_NODE_ID 100

you have (maybe inadvertently) chosen to assign node ID manually. The nodes will obey this, and use the manually assigned node id 100. They will not ask the controller to assign id.

Computers do what you tell them to do, which can be different from what you wanted them to do

[NeverDie]

Oops. I see it right there now in the code I just posted:

// Passive mode requires static node ID
#define MY_NODE_ID 100

Seems like a better solution would be for the node to first gets its ID from the gateway and then become passive, wouldn't it?

[NeverDie]

@mfalkvidd said in Do "passive nodes" need to set their Node ID manually?:

a gateway will never assign an id to a sensor node. That's the controller's job.

Thanks for the correction. I should have said controller.

If I omit the static ID definition on a passive node, then will the controller assign it an ID?

[mfalkvidd]

@NeverDie yes and no.

When a sensor node starts up, it will check its eeprom (at address defined by EEPROM_NODE_ID_ADDRESS) and if there is a valid node id stored there, the node will use that ID. Otherwise nodes would get new ids every time they are reset, which would be confusing, destroy graphs and quickly result in running out of node IDs.

So to get an existing node to request a new ID, you'll need to clear the eeprom. The cleareeprom example sketch will clear everything. I guess it is possible to just clear the byte that contains the node ID if the node has eeprom data you want to keep intact.

[NeverDie]

Well, I don't believe the nRF51822 has an eeprom, so I'm guessing a simple "mass erase" will wipe it. I'll try that.

[mfalkvidd]

@NeverDie probably, yes.

Otherwise, here is the function to use:

void hwWriteConfig(int adr, uint8_t value)

Seems like the NRF5 implementation uses NVRAM.

The cleareeprom example sketch will also work.

[NeverDie]

Hmmm...., I get this compile time error if I remove the static ID:

 #error MY_PASSIVE_NODE configuration requires setting MY_NODE_ID

[mfalkvidd]

@NeverDie seems my inexperience with passive nodes is clear. Sorry for misleading you.

[NeverDie]

Which MySensor example should I use, then, for a TH sensor? I want it to report temperature, humidity, and battery voltage. And I want Domoticz to be able to graph all three (including negative temperature values). I was surprised that none of the given examples was exactly this. What do you recommend?

[mfalkvidd]

@NeverDie I have no idea. The passive node is a bit of a hack, since MySensors nodes were initially designed to always have a path to the gateway. Hacks usually have unintended side-effects and it appears you have found one of those side-effects.

[NeverDie]

@mfalkvidd OK, but setting the passive node sketch aside, which of the other "normal" example sketches do you recommend?

[mfalkvidd]

@NeverDie I'm not sure what you mean. any example should work. That's what they are for

[smilvert]

@NeverDie

I have started to test node-red (Which dont work yet...) so I have created a dummy sketch for parse the data to domoticz.

// Enable debug prints
#define MY_DEBUG
#define MY_GATEWAY_SERIAL

// Enable passive mode
#define MY_PASSIVE_NODE
#define MY_REPEATER_FEATURE

// Passive mode requires static node ID
#define MY_NODE_ID 0

// Enable and select radio type attached
// #define MY_RADIO_NRF24
//#define MY_RF24_PA_LEVEL RF24_PA_HIGH

//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95

#include <MySensors.h>

#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1
#define CHILD_ID_BINARY 2

// Initialize general message
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgBinary(CHILD_ID_BINARY, V_STATUS);
int counter = 0;
float temperature = 0;
float humidity = 0;
int binary = 0;
void setup()
{
}

void presentation()
{
  // Send the sketch version information to the gateway and controller
  sendSketchInfo("Passive node", "1.0");

  // Register all sensors to gw (they will be created as child devices)
  present(CHILD_ID_TEMP, S_TEMP);
  present(CHILD_ID_HUM, S_HUM);
  present(CHILD_ID_BINARY, S_BINARY);
}

void loop()
{
  // generate some random data
  counter ++;
  if (counter == 20 ){
    temperature = 0;
    humidity = 0;
    counter = 0;
  }
  else
  {
    temperature = 25.0 + random(0,30)/10.0;
    humidity = 55.0 + random(-20,20);
  }
/*
  if (binary == 0){
    send(msgBinary.set(binary,2));
    binary = 1;
  }else {
    send(msgBinary.set(binary,2));
    binary = 0;

  }
*/
  send(msgTemp.set(temperature,2));
  send(msgHum.set(humidity,2));
  wait(1000);
}

[NeverDie]

@smilvert I guess it's destiny then: Node Red + MQTT

[smilvert]

@NeverDie

Well I wanted to filter noise values and I also want to use influx/grafana as a complement to domoticz

[NeverDie]

@smilvert So, do you have the gateway connected directly to Node Red, which then feeds Domoticz and also feeds influx/grafana? I think I want to do the same, if that's how to do it.

[smilvert]

@NeverDie
that's the idea but it is not 100 % yet but I working on it.

[NeverDie]

@smilvert I think @Toyman said he has it figured out. Maybe he can tell us how he did it?

[rmtucker]

@NeverDie
Just cut domoticz out of the picture as node-red/influx/grafana works perfect with any gateway serial/ethernet/mqtt.
I prefer the serial gateway in my own experience is the most stable and no reliance on wifi routers and things.
Domoticz has nowhere near the same flexibility when graphing etc.

[NeverDie]

@rmtucker Ahhhhhh, that's right, it was rmtucker, not toyman, who had done it: https://forum.mysensors.org/topic/6961/nrf5-bluetooth-action/1078

[tekka]

@NeverDie @mfalkvidd Passive nodes communicate without message ACKs - ID requests may never make their way to the controller, hence the requirement of a static node ID.

[NeverDie]

@tekka In that case couldn't it just keep retrying until it received its ID?

[tekka]

@NeverDie No, that's not the idea of a passive node. However, with

void transportTogglePassiveMode(const bool OnOff)

you can enable the passive transport mode, see here for additional information (>=2.2.0)

[NeverDie]

@smilvert Got it working: https://www.openhardware.io/view/510/Multi-Sensor-TempHumidityPIR-LeakMagnetLightAccel#tabs-source

I cited you in the credits at the beginning of the sketch.