How do I get multiple different mock barometers?

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