Brainstorming: Improve Sensor Telemetry Support

[pral2a]

During a recent hackathon and experimentation phase at FAB25 using Meshtastic for environmental data collection, several limitations and opportunities for improvement emerged.

This issue is an open brainstorming on strategic features to enhance the usability of Meshtastic as a telemetry transport layer, particularly in environmental sensing use cases.

⚠️ All proposals will require experimental testing and discussion with experts to understand protocol constraints and capabilities, particularly around scalability, network congestion and memory limitations on embedded devices.

1. Standardised Ingestion Architecture

Problem:
Currently, Meshtastic can relay telemetry data, but there's no clear standard or mechanism for routing and storing data in ingestion platforms (e.g., Smart Citizen, external databases).

Proposal:

• Introduce a standard ingestion interface to define ingestion targets during node setup.

• Allow setting a node or external endpoint as an "ingestion node" or "telemetry sink".

• Support configuration of this endpoint via:

  • token-based authentication
  • optional OAuth-style handshake

• Avoid platform-specific integrations by defining a generic ingestion protocol/interface.

• Allow endpoints to be configurable post-deployment via the app or CLI.

2. Improved Sensor Metadata & Identification

Problem:
Sensor telemetry is currently identified mainly by measurement type (e.g., temperature, humidity), limiting traceability and interoperability.

Proposal:

• Explore integration with SensorML or a lightweight schema to:

  • identify sensor types and capabilities
  • support metadata such as units, calibration, manufacturer

• Define a scalable schema that remains lightweight enough for embedded environments.

• Ensure backwards compatibility with existing telemetry structure.

3. Decentralised & Pull-Based Data Access

Problem:
Telemetry currently relies on continuous streaming. There's no support for on-demand data access in low-connectivity scenarios.

Proposal:

• Enable data caching on Meshtastic nodes, treating telemetry like chat messages.
• Develop a mechanism for requesting historical data from specific nodes.
• Test intermediate caching on relay nodes to reduce redundancy and improve availability.
• Treat data as an addressable asset across the mesh, enabling a truly decentralised sensor data architecture.

4. Ingestion Nodes as MQTT-Only Virtual Participants

Brainstorming:
A speculative but potentially strategic idea: what if the ingestion module itself was structured to behave like a proper node in the Meshtastic network, just without radio, operating only / primarly via MQTT?

Rationale:

• This would allow the ingestion service to be a first-class network participant, recognised by other nodes.
• It could send and receive messages like any other node, instead of acting as an abstract external service.
• This might open the door to richer peer-to-peer logic, acknowledgements, or even bi-directional flows with ingestion backends.
• It could help avoid “Frankenstein” topologies where ingestion tools sit awkwardly outside the network logic.
• Could built on meshtasticd Meshtastic on Linux Native Hardware