[Feature Request] MeshCore Wind Measurement Support

[Blake-Latchford]

Community Activity

I think the data below suggests that there is an unmet need in the community to provide solutions for tracking telemetry for wind information.

Argent ADS-WDS1

I am currently looking into how I might add support for the ADS-WDS1.
https://argentdata.com/product/wind-rain-sensor-assembly/

MeshCore SAR

This project seems to implement the decoding of wind metadata, though I'm not sure there is any implementation of encoding the data.
static const int _lppGust = 137;
static const int _lppSpeed = 129;
static const int _lppDirection = 132;
static const int _lppGust = 137;
static const int _lppRain = 139;
https://github.com/dz0ny/meshcore-sar/blob/3e8d4c2d/lib/services/cayenne_lpp_parser.dart#L86-L87

SEN0658 Support

This project seeks to add support for SEN0658, but doesn't seem to have progressed to the point of managing telemetry.
https://github.com/meshcore-dev/MeshCore/pull/1924/changes

Gusty

This proposal assumes that wind telemetry is accessible, but doesn't discuss how it might be obtained.
https://deveco.io/u/w8emv/project/gusty---mesh-networks-for-real-time-off-grid-reporting-of-thunderstorm-gust-fronts

Meshtastic

Several meshtastic projects try to fill this user need. It seems to me that adoption has been quite low, in part because replication of a particular physical build was challenging.
https://discord.com/channels/867578229534359593/1260693979591082015
https://discord.com/channels/867578229534359593/1218808798517399663

Current Status

Base Firmware

The data helper doesn't include an identifier for any wind related telemetry other than direction.

MeshCore/src/helpers/sensors/LPPDataHelpers.h

Line 66 in 0679dbe

class LPPReader {

Number Allocations

Initial proof of concept implementations should use the pre allocated development identifier list. It is the explicit stated policy of the MeshCore project that allocations should be performed after a proof of concept is been completed.

MeshCore/docs/number_allocations.md

Line 4 in 0679dbe

Proposal

I think the MeshCore project should consider an exception to the policy requiring a POC. I think there are users today that want to build this, but don't want to start from scratch. In particular I think that the people with the frontend skills and the firmware skills are different. Creating an established standard would allow app developers to interpret the data even absent a specific implementation. This friction reduction increases the probability that the problem actually gets solved.

[Blake-Latchford]

To make it explicit, I don't think the devs owe me anything. I'm grateful for your consideration.

Furthermore, if someone wanted to make an argument that actually all of the above approaches are wrong, and there is a better way to solve the user needs I would be very interested.

[vielmetti]

@Blake-Latchford -

From the "Group Data Types" document:

NOTE: the range FF00 - FFFF is for use while you're developing, doing POC, and for these you don't need to request to use/allocate.

Once you have a working app/project, you need to be able to demonstrate it exists/works, and THEN request type IDs. So, just use the testing/dev range while developing, then request IDs before you transition to publishing your project.

However, I will note that LoRaWAN has an "anemometer" device type which might be reusable, and there is existing hardware like this Calypso "ULP LoRa Anemometer" of interest: https://www.calypsoinstruments.com/blog/blog-1/ulp-lora-anemometer-revolutionizing-remote-wind-data-collection-224 (unclear on the cost, but definitely a device of interest to this).

[Blake-Latchford]

$756. That's a lot of repeater installs.

[Blake-Latchford]

#2514 (comment)

[Blake-Latchford]

https://discord.com/channels/1495203904898728149/1495410606985969765/1546676415296966746