[PARENT] [ALIGNMENT]: Sensor Telemetry UI/UX

[jamesarich]

Area of Alignment
Meshtastic supports a wide range of sensor and telemetry data. The client apps should be aligned on how this data is presented to provide a consistent experience when moving between platforms.

Sub-tasks

• Understand the full range of telemetry metrics available

• Understand how to display each telemetry metric (value, unit, formatting, scale, chart, etc)

• Create Android alignment issue.

• Create iOS alignment issue.

• Create Web alignment issue.

[oscgonfer]

This issue requires a lot of unpacking. I would try to categorise the metrics that meshtastic currently collects, which I believe are somewhat reflected on the firmware, with some nuances:

1. Power: data coming from power sources such as current/voltage meters.
2. Weather (note that I don't use environment): data from typical weather units, namely air temperature, humidity, barometric pressure, wind speed, wind direction, rain, radiation. This is every parameter measurable in the air, that is not related to AQ below. This is partially implemented in the EnvironmentTelemetry module.
3. Air Quality: Pollutant data, both from particulate matter and chemicals.
4. Device-related thermal parameters: metrics that are sadly now being collected "as if they were weather" but that are basically related to the device itself (a temperature sensor inside the box, or poorly placed).
5. Soil: soil humidity, soil temperature, etc. Niche, but supported in the firmware.
6. (maybe in the future) Water: currently not measured, but pH, water temperature, Conductivity, etc.

Warning

Note that, with the exception to AQ, all the other ones: Weather, Device, Soil are now packed into EnvironmentTelemetry, with the issue being that only one of the metrics is being sent over (for multiple temperature sensors, you only get one temperature). This last issue will be solved by changing how protobufs are described (explicitely mention which sensor collected the metric).

Power

This is largely done in PowerTelemetry, although there is little to show for people that don't know what is connected where. I believe there is a representation gap in how this data makes it to the client and how it's shown at the moment, largely because most current/voltage meters provide several channels, but at the moment there is no way to say "this is the channel that actually means something". I am not sure how the power metrics are used, but it'd make sense to have the metrics coming from the PV panel, and load at least.

My suggestion here would be to:

1. Have a way to choose a channel and describe what it is.
2. If the power metrics are coming from a solar panel (most likely the case), and the load.

Overview (Battery, Panel power, Load power):

• This is the best possible representation, which may not be possible with the current data, but overall, a representation of the battery %, how much power the panel is providing, and how much we are consuming, is the best way to know if a system is balanced.

Panel power metrics (power = voltage * current) and load power metrics:

Note

Note: This could be combined with temperature data (if it existed) inside the device.

Weather

Caution

A lot regarding weather was unpacked in meshtastic/Meshtastic-Apple#308

Similar to PowerTelemetry, for EnvironmentTelemetry temperature, RH and barometric pressure sensors in this category we don't have a way to know if they are measuring the weather, or the box in which the device is, or something else. For that, I would simply represent those metrics as timeseries.. Note that:

• Barometric pressure is mostly static, except when there are weather events (storms). I'd represent it on a timeseries on it's own, with fixed axis (not autoscaling), ranging from 70kPa to 120kPa for a device in sealevel. This lets you see if there is something going to happen (a storm) or not. If we autoscale this, it will be very difficult to see trends. An important note is that we can derive the expected barometric pressure if we have elevation data (see formula)
• Temperature and rh: These two metrics require different scales (not represented on the same vertical scale) on a timeseries. Autoscaling here would be possible, although probably interesting to have quite a bit of margin on the scale to see trends.
  • For the particular case of temperature, a heatmap may be an interesting representation of data to look for "hot days".

• For wind, the most typical (scientific) representation is a wind-rose but it's probably too much effort to represent it. Simply a table/timeseries with indications of speed and direction with little arrows is the most typical I've seen:

• For precipitation, in addition to the above tabular representation alongside with the wind (like most weather apps), a bar chart is probably one of the most common representations, although the aggregation level is important (similar to many other metrics). Probably this is a minimally used metric though.
• Radiation: a timeseries would do, with fixed lower value of 0. I don't know how this is measured in meshtastic, but typically, it's best to use a UV index. However, if the UV index is not provided by the sensor, we can't estimate it based on the irradiance (uW/cm2) because UV index is dependent on the associated wavelength. Then:
  • If we only get the uW/cm2 readings from the sensor: a timeseries with no "judgement". Autoscaled, fixed value at 0uW/cm2.
  • If we get UV index from the sensor: then we can apply a "recommendation" - see index usage

Note

One comment for all timeseries: IMHO, timeseries charts with "big dots" are a problem if they become too cluttered. I'd aim to either have thin lines, and maybe a dot where the cursor is (see an example below).

Adding here an example which probably overuses the color scales.

Air quality

AQI

I'll unpack this in #54.

CO2

We now support many CO2 sensors. There is no guidance on how to report it in a general sense. There are some regulations for work environments, but nothing really on households. However, some basic recommendations are:

• Good: 400-1000ppm
• Stuffy: 1000-2000ppm
• Poor: 2000 (and above)
  If we want to add more colors:
• Unsafe to work for 8h: Above 5000ppm.
• Evacuate: Above 30000-40000ppm

Device metrics

Again, the issue here is to be able to know if these metrics are something or not. In any case, the current timeseries do the job.

Soil & water

I don't know if this is really an interesting topic to unpack. For now, simple timeseries can be used as probably this is not really a big use case.

[b8b8]

My comment is on air quality. I think it should be renamed "Hazards".

Hazards should include:

• VOC/IAQ
• Particulate/AQI
• CO2
• CO
• Radiation (the dosimeter supported in meshtastic is the radsens)

https://climateguard.info/radsens/

UV readings can in a separate section.

[oscgonfer]

I think Air Quality is the accepted term for it in most disciplines. Hazards feels too extreme for me, especially since Good Air Quality is no hazard.