Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

[Feature request] Optional BLE repeater observer transport with bounded queues

未关闭
#3,640 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
c, github
领域
embedded-iot

调研方向

Read the proposed implementation at https://github.com/throny/meshcore-ble-observer and its source/provenance tooling, then review MeshCore's CONTRIBUTING guidance for the maintainer discussion. The request leaves API boundaries and PR split undecided, and validation is incomplete across long duration, RF, energy, recovery, security and other hardware. Done means maintainer agreement on scope and boundaries before a feature PR.

由索引模型根据 Issue 内容生成。

描述

Problem

A repeater observer normally needs a permanent USB connection to forward the
repeater's own packet observations to a host. A nearby Companion observes its
own RF reception, not the repeater's internal observations. An opt-in BLE export
would support installations where a permanent USB data cable is impractical.

Proposed approach

  • Default-off repeater observer feature selected through a separate custom build
    target; no automatic replacement or update of stock firmware.
  • Physical enrollment, bonded/encrypted BLE, one pinned observer peer and explicit
    revocation. No automatic or open enrollment after reboot.
  • Bounded packet/log callbacks, record queues and fragmentation with session and
    sequence identifiers, complete-record ACKs and explicit loss counters.
  • ACK means host RAM reassembly, not MQTT delivery; no lossless/durable replay
    claim. RF forwarding must remain the primary responsibility.
  • Shared protocol/queue primitives, with an initial nRF52/SenseCAP Solar P1-Pro
    binding. Other boards need reviewed transport bindings and actual validation;
    no generic cross-board compatibility claim.

An experimental implementation, source/provenance tooling and independently
maintained optional meshcoretomqtt BLE adapter are at:
https://github.com/throny/meshcore-ble-observer

Validation and limits

The current implementation cleanly replays against official repeater-v1.18.0.
Hosted CI builds the custom image and runs native/exact-source tests. Initial
P1-Pro/Linux-host checks exercised identity-preserving application updates,
bonded BLE packet reception, parsing and MQTT connections. Long-duration,
matched RF, energy, recovery and full interruption/security acceptance remain
incomplete; other hardware is unvalidated. This is not an official release or
an unattended/solar-readiness claim.

Following CONTRIBUTING, this issue seeks maintainer agreement before a large
feature PR. Would you consider this as a default-off repeater capability, and
what API boundaries/PR split would you prefer before a port to dev?

主要语言
C
星标
3.9k
派生
1.5k
平均合并
1 天 3 小时
30 天内合并 PR
24

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

meshcore-dev/MeshCore 的其他 Issue

查看 meshcore-dev/MeshCore 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。