[Feature Request]: Telemetry: choosing sensor source + identifying which sensor produced a value

[Tomas-Kuchta-FPV]

Platform

Cross-Platform

Description

I’m building an environmental Meshtastic node with multiple sensors (CO₂, temp/RH, PM, IAQ), and I’ve run into a design limitation:

When multiple sensors can produce the same type of data (e.g., temperature, humidity, CO₂), Meshtastic currently just uses one implicitly, with no way to:

• choose which sensor should be used, or
• know which sensor the value came from on the receiving side.

For simple nodes this is fine, but for environmental monitoring, it makes data comparison and trust harder.

Idea:
It would be useful if a node could either:

• select one sensor as the source for a given measurement, or
• apply a simple merge rule (average / min / max / fallback),

and also send a small separate telemetry message indicating which sensor is being used for each measurement (sensor provenance), without changing the normal telemetry format.

Defaults wouldn’t change single sensor nodes would behave exactly as they do now.

This would help makers build more serious environmental sensing nodes, while keeping Meshtastic simple for normal use.

This issue description was drafted with the help of AI.

[thebentern]

Tagging @oscgonfer

[oscgonfer]

Thanks @Tomas-Kuchta-FPV

I've been toying with this idea in my head for a while, and I think meshtastic/protobufs#852 could do the job. It adds the sensor to the telemetry payload, nesting the metrics data under each. What do you think?

For environment telemetry, it'd be some work, specially for clients such as the phone app and others, but maybe worth considering it for a major release? @thebentern any thoughts?

[Tomas-Kuchta-FPV]

Hi @oscgonfer, thanks for the proposal! I think the changes in meshtastic/protobufs#852
are a solid step in the right direction.

A couple of thoughts:

Selecting one sensor as the “main” temperature source makes sense. In that case, it seems reasonable to only send the primary temperature reading and drop the redundant ones on the sender side that would reduce data transmissions without losing meaningful information.

It might also be useful to have an option to request all temperature readings, but I’m not convinced it’s necessary for typical use cases.

One improvement for usability would be to expose the sensor type in the environment telemetry on the mobile app. That gives users more context about where a reading is coming from. I haven’t used multiple sensor types in practice, but my understanding is that mixing readings from different sensors can lead to jumps or inconsistencies if the system switches between them. Showing the sensor type would help users interpret that behavior.

[lagunacomputer]

consider three cases:

a. NRF node with bat pads. Battery voltage is reported.
b. NRF node with bat pads +INA3221. Battery flows thru INA3221 ch1 then to bat pads. Node Battery voltage is reported from the pads. INA3221 ch1 voltage is reported separately in telemetry.
c. NRF node with bat pads +INA3221 and variants.h INA3221 address set to i2c hex address or in IOS app set to 66 binary . Node battery voltage is now reported from the INA3221. INA3221 ch1 voltage is also reported separately in telemetry. However both values (node battery and INA ch1 voltage) are polled at different times.

at least thats been my experience. This is especially noticed on esp32 nodes without APU chip or voltage divider input. Getting node battery voltage from the INA requires that address to be set in the IOS app. If you don't set the INA address in the ios app, you get 0 node battery voltage, but the INA is autodiscovered and reports voltage in telemetry only.
It would be nice to choose your source of value, and apply it to where you like with a checkbox mapping or similar.

[Tomas-Kuchta-FPV]

Hi, it's already in the discussion here. Go give it a like.
#3825

consider three cases:

a. NRF node with bat pads. Battery voltage is reported.
b. NRF node with bat pads +INA3221. Battery flows thru INA3221 ch1 then to bat pads. Node Battery voltage is reported from the pads. INA3221 ch1 voltage is reported separately in telemetry.
c. NRF node with bat pads +INA3221 and variants.h INA3221 address set to i2c hex address or in IOS app set to 66 binary . Node battery voltage is now reported from the INA3221. INA3221 ch1 voltage is also reported separately in telemetry. However both values (node battery and INA ch1 voltage) are polled at different times.

at least thats been my experience. This is especially noticed on esp32 nodes without APU chip or voltage divider input. Getting node battery voltage from the INA requires that address to be set in the IOS app. If you don't set the INA address in the ios app, you get 0 node battery voltage, but the INA is autodiscovered and reports voltage in telemetry only.
It would be nice to choose your source of value, and apply it to where you like with a checkbox mapping or similar.