How do I get multiple different mock barometers?

[NeverDie]

I want to have more than one mock barometer, but I'm not sure how to set that up in the MySensors framework. Any hints?

[gohan]

Do you mean more than one in the MockMysensor sketch?

[NeverDie]

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

Do you mean more than one in the MockMysensor sketch?

Yes.

[NeverDie]

If not that, how do I create a new sensor type with similar qualities?

[gohan]

what are you trying to do? Just to understand what viable solution it may fit your need

[NeverDie]

@gohan
I'm trying to send different 12bit (two byte) values back to Domoticz, and so far the barometer is the only sensor type I've found which does that. Everything else only seems to send 1-byte values.

I want to send the voltage measurement of the supercap back, and I want to send the voltage output of the solar panel back. It doesn't graph well if I use the same barometer (which I've hijacked for this purpose) for both readings. I either need more barometers, or more of some device that can send two byte values within the mysensors framework.

If there's an easier way to do it, then I am, of course, open to that as well.

[rejoe2]

@NeverDie I'm not sure, if I got your problem right:
Do you want to have different values reported on the same ChildID? There are other sensor types doing so, most generic would be the S_CUSTOM, allowing up to 5 different info-channels for the same child. Afaik, there is no logical limitation wrt. data types to use for VAR1 to VAR5, just a limitation in the payload length (around 12 chars).

[NeverDie]

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

@NeverDie I'm not sure, if I got your problem right:
Do you want to have different values reported on the same ChildID? There are other sensor types doing so, most generic would be the S_CUSTOM, allowing up to 5 different info-channels for the same child. Afaik, there is no logical limitation wrt. data types to use for VAR1 to VAR5, just a limitation in the payload length (around 12 chars).

Basically I have two different 12-bit values that I want to report back to the gateway and have appear inside Domoticz so that they're graphed. I want to keep them separated. I'm flexible as to how that gets done, but I'm sending it from an nRF52832, and so far the mocksensors demo example is the only one that I've gotten to work.

I'm unfamiliar with the mysensors software framework, so I'm not sure what, for example, ChildID's are.

[gohan]

@rejoe2 no, he doesn't need to send as the same child ID, he only needs to find what kind of variable supported by domoticz can be used to transfer a 12 bit value.

[NeverDie]

I just now uncommented:

#define ID_S_CUSTOM            99

in the mocksensors sketch, but nothing appears within Domoticz as a result. Not much of a demo sketch for S_CUSTOM I guess.

Surely it can't be this hard?

Since I have an extra 4 bits than I need, I guess I could just parse the serial gateway output and separate the values that way. But that takes me outside the MySensors framework.

[rejoe2]

@gohan Thanks for info. I'm not familiar to Domoticz, and FHEM seems not to limit the data type of received.
Also when I present S_CUSTOM, I get 5 new "readings", but these are filled not automatically, I first have to send some data through the sketch (or send something through some kind of console to the node from FHEM side).

As I'm not familiar with Domoticz, this may be different there...

[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

[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

[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.

[mfalkvidd]

@NeverDie a discussion on that topic is underway in https://github.com/mysensors/MySensors/issues/892

[NeverDie]

@mfalkvidd
In that case the nRF52832 should be faster at emptying the buffer, since it doesn't have to rely on the slower SPI bus. And from what I gather, it can also do DMA's, which could speed things up even further.

[mfalkvidd]

@NeverDie for a node I think the bottleneck is the speed of the air transfer. Sending a message takes about 1ms at the default setting of 250kbps. But a busy gateway might benefit from the higher processing speeds on nRF52832.

[NeverDie]

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

@NeverDie for a node I think the bottleneck is the speed of the air transfer. Sending a message takes about 1ms at the default setting of 250kbps. But a busy gateway might benefit from the higher processing speeds on nRF52832.

Does it default to 250kbps to compensate for the range problems that the nRF24L01 has? I'm planning to bump mine up to 2mbps if at all possible. That might save appreciably on battery life.

[NeverDie]

I suppose the

wait(long_wait)

isn't so bad a power drain if it's actually sleeping rather than busy-waiting for 500ms.

[NeverDie]

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

#define MY_NRF5_ESB_PA_LEVEL (NRF5_PA_MAX)

#define MY_NRF5_ESB_CHANNEL (76)

#define MY_NRF5_ESB_MODE (NRF5_250KBPS)

Just now noticing that your definitions:

#define MY_NRF5_ESB_PA_LEVEL (NRF5_PA_MAX)

#define MY_NRF5_ESB_CHANNEL (76)

#define MY_NRF5_ESB_MODE (NRF5_250KBPS)

can also be set in myconfig.h.

Strangely, myconfig.h defaults to max Tx power on the nrf52, but not max Tx power on the nrf24. Not sure why, especially since, if anything, the nRF24 needs it more.

So, I just now changed myconfig.h to put everything at max Tx power and 2mbps ota datarate. A lot of the nrf24 fake chips don't even run at 250kbps.

[gohan]

Do mean the fake chips need to run at higher datarate?

[rmtucker]

@NeverDie
Ye i just like all the settings at the beginning of my sketches etc,it reminds me if i have changed channel number etc.

[NeverDie]

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

Do mean the fake chips need to run at higher datarate?

All the fakes I've encountered can handle 1mbps and 2mbps.

[NeverDie]

Not sure why, but by upgrading to 2mbps datarate from the previous default of just 250kbps, I'm able to reduce LONG_WAIT to 0 without incurring packet losses. Go figure.

[NeverDie]

For the SHORT_WAIT, 10ms seems adequate on an nRF52832. Not sure where it hangs if the SHORT_WAIT is reduced too much lower than that though.

[gohan]

@NeverDie my question was if thay handle higher speeds better than the lowest since you said "A lot of the nrf24 fake chips don't even run at 250kbps"

[NeverDie]

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

@NeverDie my question was if thay handle higher speeds better than the lowest since you said "A lot of the nrf24 fake chips don't even run at 250kbps"

I'm not understanding your question.

[NeverDie]

What does it mean when the Domoticz log looks like this?

2017-08-11 08:11:20.670 MySensors: Node: 1, Sketch Version: v0.5
2017-08-11 08:11:24.053 MySensors: Node: 1, Sketch Name: MockMySensors
2017-08-11 08:11:24.068 MySensors: Node: 1, Sketch Version: v0.5
2017-08-11 08:11:27.454 MySensors: Node: 1, Sketch Name: MockMySensors
2017-08-11 08:11:27.470 MySensors: Node: 1, Sketch Version: v0.5
2017-08-11 08:11:30.870 MySensors: Node: 1, Sketch Name: MockMySensors
2017-08-11 08:11:30.887 MySensors: Node: 1, Sketch Version: v0.5
2017-08-11 08:11:34.245 MySensors: Node: 1, Sketch Name: MockMySensors
2017-08-11 08:11:34.260 MySensors: Node: 1, Sketch Version: v0.5
2017-08-11 08:11:37.650 MySensors: Node: 1, Sketch Name: MockMySensors
2017-08-11 08:11:37.666 MySensors: Node: 1, Sketch Version: v0.5
2017-08-11 08:11:41.036 MySensors: Node: 1, Sketch Name: MockMySensors
2017-08-11 08:11:41.051 MySensors: Node: 1, Sketch Version: v0.5
2017-08-11 08:11:44.375 MySensors: Node: 1, Sketch Name: MockMySensors
2017-08-11 08:11:44.391 MySensors: Node: 1, Sketch Version: v0.5
2017-08-11 08:11:47.800 MySensors: Node: 1, Sketch Name: MockMySensors
2017-08-11 08:11:47.816 MySensors: Node: 1, Sketch Version: v0.5
2017-08-11 08:11:51.185 MySensors: Node: 1, Sketch Name: MockMySensors
2017-08-11 08:11:51.200 MySensors: Node: 1, Sketch Version: v0.5
2017-08-11 08:11:54.583 MySensors: Node: 1, Sketch Name: MockMySensors
2017-08-11 08:11:54.599 MySensors: Node: 1, Sketch Version: v0.5
2017-08-11 08:11:58.005 MySensors: Node: 1, Sketch Name: MockMySensors
2017-08-11 08:11:58.021 MySensors: Node: 1, Sketch Version: v0.5
2017-08-11 08:12:01.384 MySensors: Node: 1, Sketch Name: MockMySensors
2017-08-11 08:12:01.401 MySensors: Node: 1, Sketch Version: v0.5

Plainly, it's caught in a loop of some kind and never receives the sensor values.

[NeverDie]

For some reason, downgrading from 2mbps back down to 250kbps solved the above problem.

[NeverDie]

Fortunately, 1mbps seems to work, even if 2mbps doesn't.