How do I get multiple different mock barometers?

[NeverDie]

In what library file does "msg_S_BARO_P(ID_S_BARO,V_PRESSURE)" get defined? Maybe I could just go there and create a new thing, called "msg_S_BARO_P2(ID_S_BARO2,V_PRESSURE2)" Then maybe I'd have two different, but similar, barometer things to use for transporting the voltage measurements I want to send?

It just seems strange, though. Surely I can't be the first person to run into this? For instance, lots of people have more than one TH sensor. The same type of limitation would seem to apply to multiple TH sensors as well.

[mfalkvidd]

@NeverDie https://www.mysensors.org/build/pressure has an example on how to use two child IDs to report two values. Just use the same type for both, but different child ids.

Multiple child ids is one of the basics of MySensors. I've actually never considered that people might not know how to use them :)

[NeverDie]

@mfalkvidd
Can I use that as a pattern, then, to add more than one child ID to the barometer as well?

[mfalkvidd]

@NeverDie yes. use something like

#define BARO_1_CHILD 0
#define BARO_2_CHILD 1
...
MyMessage pressure1Msg(BARO_1_CHILD, V_PRESSURE);
MyMessage pressure2Msg(BARO_2_CHILD, V_PRESSURE);
...
present(BARO_1_CHILD, S_BARO);
present(BARO_2_CHILD, S_BARO);
...
send(pressure1Msg.set(pressure1, 0));
send(pressure2Msg.set(pressure2, 0));

You can of course use arrays and/or loops if you prefer that (like the relay example does), but duplicating the code like this makes it more readable when you only have a few sensors.

Do you think there is something we could add to the examples or the documentation to make it clearer how to use child ids?

[mfalkvidd]

Child id is also described at https://www.mysensors.org/download/sensor_api_20#presentation

[NeverDie]

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

Child id is also described at https://www.mysensors.org/download/sensor_api_20#presentation

Thanks for that link. It certainly helps. It's funny, though, that in the simple example NODE_ID appears to be completely undefined. I assume it's missing this line?

#define NODE_ID 0

[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 :)