Non-existing sensors get added to json payload with 0 values by default

[oscgonfer]

In some first tests for the work we are currently doing as part of the Smart Citizen meets Meshtastic Hackathon, the telemetry payload received in our MQTT broker has potentially misleading values. In the payload below, only temperature and humidity was present, but we see that all environment sensors are included, with a value of 0, which makes it difficult to know whether or not there is a sensor present. All sensors there, could potentially have a value of 0, and whether or not is a logical value, I believe they should not be sent (or made NULL)

/mesh12/2/json/LongFast/!da741924
{"channel":0,"from":3665041700,"hop_start":3,"hops_away":0,"id":1913147084,"payload":{"barometric_pressure":0,"current":0,"gas_resistance":0,"iaq":0,"lux":0,"relative_humidity":63.6100006103516,"temperature":29.8299999237061,"voltage":0,"white_lux":0,"wind_direction":0,"wind_gust":0,"wind_lull":0,"wind_speed":0},"sender":"!da741924","timestamp":1750022954,"to":4294967295,"type":"telemetry"}

I am opening a PR to work on this, hopefully is in the right direction.

[thebentern]

For values with protobufs optionals, there are has_member bools to determine if the value is present or not. For ones that don't have this available, 0 may be a legitimate value in some cases (ala temperature) or others like barometic_pressure would not make sense and could be omitted

[oscgonfer]

Hi,

I focused mostly on environment and air quality metrics, which I believe all have a has_ defined.

I would argue against omitting fields based on sensor values, as any sensor could potentially have 0 (even barometric pressure). In that particular case, 0 may indicate the sensor is broken, or a fault code by the manufacturer/library and for remote diagnosis, I would like to know it is still present, and broken, than not knowing. Does that make sense? #7048 works with that in mind.

[oscgonfer]

Closed as #7048 was merged