How do I get multiple different mock barometers?

[mfalkvidd]

@NeverDie if NODE_ID is not defined in the sketch, the controller will(/needs to) provide the next available node id.
https://www.mysensors.org/download/sensor_api_20#received-node-id

Node id 0 is reserved for the gateway.

[korttoma]

The correct line for API 2.x is actually:

#define MY_NODE_ID 1

[NeverDie]

@mfalkvidd said in How do I get multiple different mock barometers?:

Node id 0 is reserved for the gateway.

The text of the wiki says:

child-sensor-id This is where you specify the child sensor that's reporting the data. In the example we only have one child sensor so we pick 0.

So, based on @mfalkvidd and @korttoma remarks, that is wrong and we should avoid naming child sensor id's as zero? Or, is this confusing the node-id with the child-id?

Regarding the node-id, doesn't the gateway provide the actual node-id, not the programmer?

[mfalkvidd]

@NeverDie child sensor id and sensor node id are different things.

A sensor node (usually arduino + radio) has a node id. Node id 0 is reserved for the gateway. A sensor node can have many child sensors (two bme280 for example). There is no reservation for child sensor id (except maybe 255, I think that is used by some controllers for special data)

[NeverDie]

I have it working now, but why are:

#define LONG_WAIT 500
#define SHORT_WAIT 50

needed?

[rmtucker]

@NeverDie
Why barometer instead of voltage and multimeter?

[NeverDie]

@rmtucker said in How do I get multiple different mock barometers?:

@NeverDie
Why barometer instead of voltage and multimeter?

No real reason anymore. If you rewind the tape to the beginning, though, it was because barometer compiled and volt meter didn't.

[gohan]

@NeverDie said in How do I get multiple different mock barometers?:

I have it working now, but why are:

#define LONG_WAIT 500
#define SHORT_WAIT 50

needed?

I think those are used in the code to delay the sending of mock values

[rmtucker]

@NeverDie

Here is a little sketch that compiles on the NRF5.

// Enable debug prints to serial monitor
//#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_NRF5_ESB

/**
   @def MY_NRF5_ESB_PA_LEVEL
   @brief Default nRF5 PA level. Override in sketch if needed.

   - NRF5_PA_MIN = -40dBm
   - NRF5_PA_LOW = -16dBm
   - NRF5_PA_HIGH = 0dBm
   - NRF5_PA_MAX = 4dBm
*/
#define MY_NRF5_ESB_PA_LEVEL (NRF5_PA_MAX)

#define MY_NRF5_ESB_CHANNEL (76)

#define MY_NRF5_ESB_MODE (NRF5_250KBPS)

#define MY_NODE_ID 10
#define VOLTAGE     0
#include <MySensors.h>

float vcc = (hwCPUVoltage() / 1000.0);

MyMessage VoltageMsg(VOLTAGE, V_VOLTAGE);

void presentation()
{
  sendSketchInfo("General sensor", "1.0");
  present(VOLTAGE, S_MULTIMETER);
}


void setup() {
//  Serial.begin(115200);
//  while (!Serial) ; // wait for Arduino Serial Monitor
}

void loop() {
  send(VoltageMsg.set(vcc, 3));
//  Serial.print(F("Voltage = "));
//  Serial.print(vcc, 3);
//  Serial.println(F("v"));
  sleep(60000);
}

[NeverDie]

@gohan said in How do I get multiple different mock barometers?:

@NeverDie said in How do I get multiple different mock barometers?:

I have it working now, but why are:

#define LONG_WAIT 500
#define SHORT_WAIT 50

needed?

I think those are used in the code to delay the sending of mock values

Yes, but why? Is it to give the serial gateway time to process it?

I'd like to know the motivation for it because I'm using an ESP8266 as my serial gateway (the Easy-Peasy), and it's considerably faster than, say, an Arduino UNO. For instance, maybe it doesn't need these delays on the sending side to keep up.

[gohan]

I think it's more related to allow enough time for people to read the log without flooding it

[NeverDie]

@gohan said in How do I get multiple different mock barometers?:

I think it's more related to allow enough time for people to read the log without flooding it

LOL. Glad I asked!

[NeverDie]

@gohan said in How do I get multiple different mock barometers?:

I think it's more related to allow enough time for people to read the log without flooding it

No, there's more going on than just that apparently. If I reduce their value to zero, it bombs. Reducing short-wait to zero causes the mote to get stuck in a loop somewhere, and reducing long-wait to zero causes the gateway to miss receiving some packets.

If these examples are meant to teach, it sure would be nice if it was documented code!

[gohan]

It is always good practice not to flood the gateway anyway :)

[rejoe2]

This wait() can also help to avoid packet losses due to insufficient power supply when using nRF24.

[mfalkvidd]

@NeverDie I am not sure, but I think the mock sketch is meant only for validating new builds of MySensors (by the Jenkins build system connected to Github). It is not included on the build page and as you said it is not documented so I don't think it is meant to teach.

I may be wrong though, I didn't know that sketch existed before you mentioned it.

At almost 1,500 lines it is 10x bigger than most of the build examples, which seems like a very bad idea if the intention is to teach.

[gohan]

It's big because it has all the code to simulate almost all sensors 😀

[mfalkvidd]

@gohan yes. And that is a terrible way to teach.

[gohan]

all-in :D

[NeverDie]

@rejoe2 said in How do I get multiple different mock barometers?:

This wait() can also help to avoid packet losses due to insufficient power supply when using nRF24.

You mean it needs extra time for the auxiliary cap to recharge? If so, surely we can find a better way to power the radio module that doesn't require taking a breather between packets....

I don't remember how it works with the nRF24L01, but on the RFM69, there's only one buffer for both sending and receiving, so you have to empty the receive buffer before you either send or receive another packet.