<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:webfeeds="http://webfeeds.org/rss/1.0">
  <title>MeshCN - Meshtastic 中国社区</title>
  
  <subtitle>在中国建立太阳能供电的 Meshtastic 无线电网络，让任何拥有智能手机的人都能在没有电力或互联网的情况下发送文本消息。</subtitle>
  <link href="https://meshcn.net/feed.xml" rel="self"/>
  <link href="https://pubsubhubbub.appspot.com/" rel="hub"/>
  <link href="https://meshcn.net/"/>
  <updated>2026-06-01T02:00:00.000Z</updated>
  <id>https://meshcn.net/</id>
  
  <author>
    <name>Hays Chan | 陈希</name>
    
  </author>
  
  <generator uri="https://hexo.io/">Hexo</generator>

 <!-- <webfeeds:cover image="https://cdn.jsdelivr.net/gh/hayschan/static@master/2020/12/gFn7zm.JPG" /> -->
 <webfeeds:icon>https://meshcn.net/images/meshtastic_china_meshcn_logo_png_light_theme.png</webfeeds:icon>
 <webfeeds:logo>https://meshcn.net/images/meshtastic_china_meshcn_logo_png_light_theme.png</webfeeds:logo>
 <webfeeds:accentColor>0abab5</webfeeds:accentColor>
 <webfeeds:related layout="card" target="browser"/>

  
  <entry>
    <title>坑人的 Ubuntu：我的 MeshSense 折腾记</title>
    <link href="https://meshcn.net/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/"/>
    <id>https://meshcn.net/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/</id>
    <published>2026-06-01T02:00:00.000Z</published>
    <updated>2026-06-01T02:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<blockquote><p>投稿来自 MeshCN 社区读者 <em>YE2F4</em>。谢谢作者把这次 Ubuntu / WSL2 / Docker 的完整踩坑过程整理出来。MeshCN 在尽量保留原文语气的基础上，仅做了标题层级、代码块、图片说明和少量技术注释整理。</p></blockquote><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/ubuntu-linux-cover.webp" alt="Ubuntu 与 Linux"></p><h2 id="写在前面">写在前面</h2><p>在《<a href="/deploy-meshsense-with-docker/">5 分钟让 MeshSense 跑起来：Docker Compose 一键部署全攻略</a>》里，我们写过：</p><blockquote><p>把 MeshSense 常驻在一台服务器上，随时用浏览器查看 Meshtastic 网络拓扑、收发与信号质量，听起来是个很简单的事情。但现实里，端口占用、镜像架构不匹配、<code>ACCESS_KEY</code> 放哪儿、数据目录怎么弄，这些细节很容易把一次简单部署拖成一整晚的折腾。</p><p>你不需要先成为 Docker 专家，也不必为环境差异焦虑——跟着 <em>深圳南山-jinsu</em> 写的步骤完成安装、启动，最终在 <code>http://&lt;主机IP&gt;:5920</code> 登录即可。</p></blockquote><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/meshsense-dashboard-first-run.webp" alt="MeshSense 首次运行后的网页界面"></p><p>如果你也认为这样做是一件轻松的事情，那么不妨来看看我与 Ubuntu 斗智斗勇的——欢（技）乐（术）故（事）事（故）。</p><h2 id="前言">前言</h2><p>本文作为一篇教程，详细记录了我在部署 MeshSense 时踩过的各种坑，旨在帮助更多用户简单、便捷、一遍成功地完成部署。</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/ubuntu-what-is-upcoming.webp" alt="Ubuntu 安装过程中的提示界面"></p><h2 id="一、系统配置">一、系统配置</h2><table><thead><tr><th>项目</th><th>配置</th></tr></thead><tbody><tr><td>CPU</td><td>i5-10210U</td></tr><tr><td>运行内存</td><td>8GB LPDDR4</td></tr><tr><td>存储</td><td>1TB SSD + 9TB HDD</td></tr><tr><td>操作系统</td><td>Windows 10 22H2</td></tr><tr><td>Linux 环境</td><td>WSL2 - Ubuntu 24.04（已更换清华源）</td></tr></tbody></table><h2 id="二、暴风雨前的宁静">二、暴风雨前的宁静</h2><p>准备好后，二话不说直接开整。（请看 VCR）</p><h3 id="1-1-安装-Docker-和-Docker-Compose">1.1 安装 Docker 和 Docker Compose</h3><p>Linux（Ubuntu/Debian）：</p><pre><code class="hljs bash">sudo apt-get updatesudo apt-get install -y docker.io docker-composesudo systemctl <span class="hljs-built_in">enable</span> --now docker</code></pre><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/systemctl-enable-docker-systemd-error.webp" alt="执行 systemctl enable --now docker 后出现 systemd 错误"></p><p>翻译：系统未使用 systemd 作为初始化系统（PID 1）启动。无法操作。</p><p>连接总线失败：主机已关闭。</p><p>简单地说，就是——我的上司不是这个人！</p><p>噔、噔、咚！什么情况？堂堂一个大 Ubuntu 竟然没有 systemd？可笑！看我来搞定！</p><blockquote class="blockquote-note blockquote-note__info"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="16" viewBox="0 0 14 16"><path fill-rule="evenodd" d="M6.3 5.69a.942.942 0 0 1-.28-.7c0-.28.09-.52.28-.7.19-.18.42-.28.7-.28.28 0 .52.09.7.28.18.19.28.42.28.7 0 .28-.09.52-.28.7a1 1 0 0 1-.7.3c-.28 0-.52-.11-.7-.3zM8 7.99c-.02-.25-.11-.48-.31-.69-.2-.19-.42-.3-.69-.31H6c-.27.02-.48.13-.69.31-.2.2-.3.44-.31.69h1v3c.02.27.11.5.31.69.2.2.42.31.69.31h1c.27 0 .48-.11.69-.31.2-.19.3-.42.31-.69H8V7.98v.01zM7 2.3c-3.14 0-5.7 2.54-5.7 5.68 0 3.14 2.56 5.7 5.7 5.7s5.7-2.55 5.7-5.7c0-3.15-2.56-5.69-5.7-5.69v.01zM7 .98c3.86 0 7 3.14 7 7s-3.14 7-7 7-7-3.12-7-7 3.14-7 7-7z"></path></svg></div>编者注：WSL2 里的 systemd</div><div class="blockquote-note__content"><p>这类报错通常不是 Ubuntu 没装 systemd，而是当前环境没有把 systemd 作为 PID 1 启动。Windows + WSL2 用户如果想省心运行 Docker，通常有三条路线：使用 Docker Desktop 的 WSL 集成、启用 WSL 的 systemd 支持，或者像本文后面这样改用 <code>service docker start</code> 启动 Docker 服务。</p><p>本文保留作者的完整踩坑过程，方便遇到同类报错的读者对照排查。</p></div></blockquote><h2 id="三、与-systemctl-的抗衡">三、与 systemctl 的抗衡</h2><h3 id="Round-One：安……安上了？">Round One：安……安上了？</h3><p>气得我立马 <code>apt</code>：</p><pre><code class="hljs bash">apt install systemd -y</code></pre><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/apt-install-systemd-already-installed.webp" alt="安装 systemd 时提示已经安装"></p><p>什么？已经有了？</p><p>一定是我打开方式不正确。</p><pre><code class="hljs bash">apt install systemctl -y</code></pre><p>嘿，您猜怎么着？</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/apt-install-systemctl-missing-dependencies.webp" alt="安装 systemctl 时提示缺少依赖"></p><p>少依赖！</p><pre><code class="hljs bash">apt install systemd-sysv -y</code></pre><p>本以为这次可以万事大吉了，结果……</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/apt-install-systemd-sysv-installed.webp" alt="安装 systemd-sysv 后的终端输出"></p><p>安……安上了？</p><h3 id="Round-Two：铁拳出击！">Round Two：铁拳出击！</h3><p>三次受挫，气得我直接上狠活——<code>aptitude</code>。</p><p><code>aptitude</code> 是一个用于管理 Debian GNU/Linux 系统及其衍生版的 APT 包管理工具。它提供了命令行和全屏文本界面两种操作模式，主要功能包括软件包安装、升级和卸载，并能自动处理依赖关系。</p><pre><code class="hljs bash">aptitude install systemctl -y</code></pre><p>（Tips：记住红圈里的那个，一会儿会考。）</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/aptitude-install-systemctl.webp" alt="使用 aptitude 安装 systemctl"></p><p>Emm……这次看起来好多了！</p><p>再来！</p><pre><code class="hljs bash">systemctl <span class="hljs-built_in">enable</span> --now docker</code></pre><p>不是，哥们，你……</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/systemctl-enable-docker-still-fails.webp" alt="再次执行 systemctl enable --now docker 后仍然失败"></p><p>算了，跳过！</p><h2 id="四、焊死的窗户">四、焊死的窗户</h2><blockquote><p>上帝为你关上一扇门的同时，会为你打开一扇窗。</p><p>——《The Bible》</p></blockquote><h3 id="1-2-验证安装">1.2 验证安装</h3><pre><code class="hljs bash">docker --versiondocker-compose --version</code></pre><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/docker-version-compose-version.webp" alt="验证 Docker 和 Docker Compose 版本"></p><p>成果喜人！</p><h3 id="2-1-新建项目目录">2.1 新建项目目录</h3><pre><code class="hljs bash">mkdir meshsense-project<span class="hljs-built_in">cd</span> meshsense-project</code></pre><h3 id="2-2-编写-docker-compose-yml">2.2 编写 <code>docker-compose.yml</code></h3><p>使用以下内容创建文件，复制到项目目录：</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/docker-compose-yml.webp" alt="MeshSense 的 docker-compose.yml 配置内容"></p><p>高端的代码，往往只需要简单的编辑工具。</p><h3 id="3-配置修改（可选）">3. 配置修改（可选）</h3><p>由于只是临时测试，所以很多部分没有修改。自己掂量着来。</p><h3 id="4-1-启动容器">4.1 启动容器</h3><pre><code class="hljs bash">docker-compose up -d</code></pre><p><code>-d</code> 表示后台运行。</p><blockquote><p>上帝为你关上一扇门的同时，会为你焊死那扇为你打开的窗。</p><p>——《The Bubble》</p></blockquote><pre><code class="hljs text">docker.errors.DockerException: Error while fetching server API version: (&#x27;Connection aborted.&#x27;, FileNotFoundError(2, &#x27;No such file or directory&#x27;))</code></pre><p>翻译：获取服务器 API 版本时出错：连接中止，没有此类文件或目录。</p><p>上网查找才知道，这是因为 Docker 没有启动。</p><p>但是，网上给出的启动方法是：</p><pre><code class="hljs bash">systemctl start docker</code></pre><p>可是别忘了，与 <code>systemctl</code> 的战争还未结束！</p><h2 id="五、再一次出发">五、再一次出发</h2><p>既然显示已安装，那就卸载重装大法！</p><pre><code class="hljs bash">apt remove systemctl</code></pre><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/apt-remove-systemctl-not-installed.webp" alt="apt remove systemctl 时提示未安装"></p><p>好好好，现在又说我未安装？我倒要看看你是不是在跟我躲猫猫。</p><pre><code class="hljs bash">systemctl --version</code></pre><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/systemctl-version-systemd-present.webp" alt="systemctl version 显示 systemd 已存在"></p><p>很明显，<code>systemctl</code> 命令可以使用，而且也正确安装了 systemd，只不过它没有运行罢了。</p><p>无妨，启动一下即可。</p><h2 id="六、systemctl，启动！">六、systemctl，启动！</h2><p>先看看掌管你系统的上司是谁：</p><pre><code class="hljs bash">ps -p 1 -o comm=</code></pre><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/pid-one-init.webp" alt="PID 1 显示为 init"></p><p>是 <code>init</code>。</p><p>都 6025 年了，这种原始的启动方式怎么还会出现在 24.04 上？</p><p>更新一下配置看看？</p><pre><code class="hljs bash">sudo update-initramfs -u</code></pre><p>事实证明，然并卵。</p><p>但是，更新完以后还是有一些变化。</p><p>还记得那扇焊死的窗吗？它变成了：</p><pre><code class="hljs text">docker.errors.DockerException: error while fetching server API version: (&#x27;connection aborted.&#x27;, connectionrefusederror(111, &#x27;connection refused&#x27;))</code></pre><p>翻译：获取服务器 API 版本时出错：连接中止，连接被拒绝。</p><p>这就像是窗户上泼了 502，再加几把挂锁。</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/frustration-meme.webp" alt="作者配图：崩溃现场"></p><p>气得我呀：</p><pre><code class="hljs bash">apt remove systemctlapt remove systemdapt remove systemd-sysvaptitude remove systemctlaptitude remove systemdaptitude remove systemd-sysv</code></pre><p>嘿，您再猜猜怎么着？</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/apt-remove-systemd-sysv.webp" alt="卸载 systemd-sysv 时的终端输出"></p><p>正事不干，安一堆 NTP，真是服了。</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/tired-meme.webp" alt="作者配图：累了"></p><h2 id="七、退一步海阔天空">七、退一步海阔天空</h2><p>为什么不能就着它的意愿来呢？</p><p>既然上司是 <code>init</code>，那么为什么不用属于它的命令呢？</p><p><code>systemctl</code> 有自己的命令，<code>init</code> 也有！</p><pre><code class="hljs bash">service</code></pre><p>再次尝试启动 Docker：</p><pre><code class="hljs bash">service start docker</code></pre><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/service-start-docker-error.webp" alt="service start docker 命令格式错误"></p><p>吔！淦！怎么回事？</p><p>（此处省略 35 次重复操作……）</p><p>后来查资料得知，正确的命令格式是：</p><pre><code class="hljs bash">service docker start</code></pre><p>输入，然后：</p><p>Enter！</p><h2 id="八、上帝啊，以后用劲小一点！">八、上帝啊，以后用劲小一点！</h2><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/service-docker-start-success.webp" alt="service docker start 成功启动 Docker"></p><p>哈哈！成啦！</p><p>（此时的天堂）</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/heaven-meme.webp" alt="作者配图：此时的天堂"></p><p>（你猜他为啥看你？）</p><p>因为你高兴得太早了！</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/docker-iptables-error.webp" alt="Docker iptables 报错"></p><blockquote><p>你努力地挖坑，想从地下逃离困住你的地方。</p><p>上帝用大石头重重地把你刚挖好的坑堵上了。</p><p>——《The Bundle》</p></blockquote><p>但是，他没有注意到，这一下把门锁震掉了。</p><p>经过不懈的摸索和努力，终于找到了解决办法：</p><pre><code class="hljs bash">touch /etc/fstabupdate-alternatives --<span class="hljs-built_in">set</span> iptables /usr/sbin/iptables-legacyupdate-alternatives --<span class="hljs-built_in">set</span> ip6tables /usr/sbin/ip6tables-legacy</code></pre><p>执行，再试一次。</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/iptables-legacy-fix.webp" alt="切换 iptables legacy 后再次尝试"></p><p>What can I say？</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/what-can-i-say-meme.webp" alt="作者配图：What can I say"></p><h2 id="九、胜利，就在眼前">九、胜利，就在眼前</h2><p>（踹门，踹门，踹门！）</p><h3 id="4-1-启动容器-2">4.1 启动容器</h3><pre><code class="hljs bash">docker-compose up -d</code></pre><p><code>-d</code> 表示后台运行。</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/docker-compose-up-success.webp" alt="docker-compose up -d 成功启动 MeshSense 容器"></p><p>别看这幅图简单，这可是靠运气和耐心的。建议准备科学与魔法。</p><p>最后，见证时刻的奇迹！</p><pre><code class="hljs bash">docker-compose psdocker logs meshsense</code></pre><p>（门开了！）</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/docker-compose-ps-logs.webp" alt="查看 MeshSense 容器状态和日志"></p><p>我滴任务，完~成~辣~！Hiahiahia……</p><h2 id="写在最后">写在最后</h2><p>在《<a href="/meshtastic-solar-node-case-wrong-18650-21700-battery/">折腾太阳能节点的奇妙旅程</a>》里，我们曾经写过：</p><blockquote><p>相信对他来说，DIY 虽然累，但能看着自己的设备稳稳运行，那种成就感是无可替代的。他的故事是 Meshtastic DIY 的一个缩影，它告诉我们：DIY 不仅仅是动手实践，更是一场充满未知的冒险。虽然可能会遇到各种问题，但只要坚持下去，总能找到解决的办法。</p></blockquote><p>虽然经历了很多挫折，情绪几近崩溃，完成时也已经很晚了，但是看着屏幕上跳动的数据，我还是感到无比欣慰。</p><p>有志者事竟成，破釜沉舟，百二秦关终属楚。</p><p>苦心人天不负，卧薪尝胆，三千越甲可吞吴。</p><p>码海沉浮志未销，孤灯夜战，三千日夜终破局。</p><p>系统鏖兵心犹烈，百策苦研，九九难关自通途。</p><p>希望社区的广大网友也能不畏艰难，一往无前，迎风而上，勇攀高峰！</p><p><img src="/meshsense-ubuntu-wsl-docker-deployment-troubleshooting/meshsense-final-dashboard.webp" alt="MeshSense 最终运行界面"></p><p>Ps：终于看见 1RHJ 了！</p><p>吐槽：OpenStreetMap 为什么总是加载不出来呢……</p>]]></content>
    
    
    <summary type="html">在 Windows 10 + WSL2 Ubuntu 24.04 上部署 MeshSense，本以为 Docker Compose 一把梭，结果 systemd、systemctl、Docker daemon 和 iptables 连环拦路。社区读者 YE2F4 记录了一次从崩溃到成功的 MeshSense 折腾记。</summary>
    
    
    
    <category term="教程" scheme="https://meshcn.net/categories/%E6%95%99%E7%A8%8B/"/>
    
    
    <category term="Docker" scheme="https://meshcn.net/tags/Docker/"/>
    
    <category term="MeshSense" scheme="https://meshcn.net/tags/MeshSense/"/>
    
    <category term="Ubuntu" scheme="https://meshcn.net/tags/Ubuntu/"/>
    
    <category term="WSL2" scheme="https://meshcn.net/tags/WSL2/"/>
    
  </entry>
  
  <entry>
    <title>果粉视角：Meshtastic 苹果客户端到底支持哪些 Apple 功能</title>
    <link href="https://meshcn.net/meshtastic-apple-ecosystem-features/"/>
    <id>https://meshcn.net/meshtastic-apple-ecosystem-features/</id>
    <published>2026-05-07T09:05:30.000Z</published>
    <updated>2026-05-07T09:05:30.000Z</updated>
    
    <content type="html"><![CDATA[<p>我是一个巨大的果粉。</p><p>所以每次看 Meshtastic Apple 客户端的新功能时，我的关注点不只是它能不能连上 LoRa 节点、能不能发消息、能不能改配置。我更在有没有把 Apple 生态真正用起来。</p><p>很多人第一次接触 Meshtastic，会先看硬件。哪块板子更便宜，哪根天线更远，哪个节点带不带 GPS，哪个外壳更适合户外。但如果你是 iPhone、iPad、Mac、Apple Watch 用户，Meshtastic 的苹果客户端其实已经不只是一个配置工具。</p><p>它更像是把 LoRa mesh 接进了 Apple 生态里。</p><p>Meshtastic Apple 客户端不是用一个跨平台壳子比如 Flutter 那样勉强套出 iOS 版本，而是在沿着 Apple 自己推荐的方向做应用。</p><p>对普通用户来说，这意味着界面、图标、数据存储和多设备体验都会更贴近 Apple 平台本身。你在 iPhone 上配置节点，在 iPad 上看更大的地图，在 Mac 上管理消息和设置，本质上都来自同一套苹果客户端工程。</p><h2 id="没有-GPS-的节点，也能借-iPhone-定位">没有 GPS 的节点，也能借 iPhone 定位</h2><p>如果只挑一个最实用的 Apple 功能，我会先讲手机 GPS。</p><p>很多低成本 Meshtastic 节点，比如 yaoyao 大佬的 TinyLoRa V2，为了省电、省钱、减小体积，本身并没有 GPS 或 GNSS 模块。比如一些低成本固定节点，它的主要任务就是常在线、转发、补覆盖，并不一定需要自己长期抓卫星。问题是，一旦你希望它在 mesh 里广播当前位置，硬件上没有 GPS 就会变成限制。</p><p>Apple 客户端这里做得很实用：它可以用 iPhone 或 iPad 的定位，作为节点的位置来源。</p><p>在 App 的初始设置里，在 Phone Location 界面打开 Share Location，使用手机 GPS 给节点发送位置，而不是依赖节点上的硬件 GPS。用户打开这个开关后，App 会按固定间隔把手机定位送给已连接的节点。</p><p>打开后，即使节点自己没有 GPS，也可以通过 iPhone 或 iPad 拿到当前位置，并把这个位置广播到 mesh 网络里。</p><p>这对新手很友好。你可以先买更便宜、更省电、硬件更简单的节点，把它作为家里、办公室、阳台上的补点；真正需要位置时，让 iPhone 或 iPad 通过蓝牙连接后提供定位。</p><h2 id="开车时，Meshtastic-也能进-CarPlay">开车时，Meshtastic 也能进 CarPlay</h2><p>CarPlay 是这次最容易让果粉眼前一亮的部分。</p><p>Meshtastic 的 CarPlay 功能用于开车时的免手持 mesh 消息，车机界面有 Channels 和 Direct Messages 两个标签页。频道页列出当前 mesh 频道，私聊页列出收藏联系人和最近联系人。如果没有连接 Meshtastic 设备，CarPlay 会显示 Not Connected，并提示打开 App。</p><p>这不是简单把手机屏幕投到车机上，而是专门为 CarPlay 做了一个更克制的消息界面。它把你开车时最可能需要的两个入口留下来：频道消息和私聊消息。</p><p><img src="/meshtastic-apple-ecosystem-features/carplay-meshtastic-app.webp" alt="Meshtastic CarPlay 界面展示频道和私聊入口"></p><p>更关键的是，它没有鼓励你开车时盯着屏幕聊天。点频道或联系人后，准备要输入消息的时候，流程会进入 Siri compose 进行语音识别转文字。这个功能让你在车上少碰手机，hands free 地靠语音完成消息收发。</p><p>Siri 发送的消息限制在 200 bytes 以内，只支持单个收件人，不支持群组私聊；emoji-only 消息和 admin 消息不会进 CarPlay。这个限制反而合理，因为 LoRa mesh 的带宽本来就不适合长篇大论，开车场景也不应该变成复杂聊天窗口。</p><p>Live Activity 也利用上了。CarPlay 连接并且节点在线时，iPhone 可以在灵动岛和锁屏上显示节点名称、短名称、在线节点数、频道利用率、airtime、收发包和转发统计，还带一个 15 分钟倒计时。</p><p>群友武汉-TWT 的实机截图里，锁屏上的 Meshtastic 即时动态会先请求系统授权。允许之后，它就能在锁屏上持续显示当前连接节点的状态，比如在线节点数量、频道利用率、airtime、收发包数量、转发数量、错误率和下一次更新时间。</p><p><img src="/meshtastic-apple-ecosystem-features/live-activity-lock-screen-permission.webp" alt="iPhone 锁屏上的 Meshtastic Live Activity 会请求即时动态权限并显示节点统计"></p><p>同一套系统能力也会和通知中心结合起来。比如发起 traceroute 之后，完成结果可以作为 Meshtastic 通知出现；上方的 Live Activity 则继续展示 mesh 当前状态。对移动中的用户来说，这比每次解锁进 App 看统计要自然很多。</p><p><img src="/meshtastic-apple-ecosystem-features/live-activity-lock-screen-traceroute.webp" alt="Meshtastic Live Activity 和 traceroute 完成通知可以同时出现在 iPhone 锁屏通知中心"></p><h2 id="Siri-不是摆设">Siri 不是摆设</h2><p>很多 App 都说自己支持 Siri，但实际只能打开 App 或触发一个很浅的动作。Meshtastic 这里更接近真正的系统集成。</p><p>Meshtastic 接入的是 Apple 的消息类 Siri 能力，而不是只让 Siri 打开 App。它可以识别你要发给谁、发到哪个频道、消息内容是什么，也会检查当前是否真的连着节点。</p><p>如同平时发 Meshtastic 消息一样，用 Siri 语音发消息不能超过 200 字节。这个限制对中文用户尤其值得注意，因为中文字符通常比英文更占字节数，短句会比长段落更适合通过 LoRa 发出去。</p><p>这意味着 Siri 在这里不是一个装饰。你可以把它理解成 Meshtastic 消息系统接入了 iOS 的语音消息能力。开车时、手上拿着东西时、临时不方便打开 App 时，这类能力才有价值。</p><h2 id="快捷指令让-Meshtastic-变成自动化零件">快捷指令让 Meshtastic 变成自动化零件</h2><p>如果说 Siri 是语音入口，那快捷指令（Shortcut）就是自动化入口。</p><p>Meshtastic 暴露给快捷指令的能力不算少。你可以在 iPhone 的快捷指令 App 里新建一个快捷指令，然后搜索 Meshtastic，就能看到它提供的动作。官方文档列出的能力包括添加联系人、发送私聊、发送 waypoint、发送频道消息、获取节点位置、关闭节点、重启节点、恢复出厂设置、保存频道配置，以及断开当前节点连接。</p><p><img src="/meshtastic-apple-ecosystem-features/shortcuts-meshtastic-actions-list.webp" alt="iPhone 快捷指令里可以搜索到 Meshtastic 提供的动作"></p><p>为了让大家更容易判断这些动作能拿来做什么，我把目前支持的快捷指令接口整理成一张表：</p><table><thead><tr><th>快捷指令动作</th><th>支持的信息</th><th>适合场景</th><th>注意点</th></tr></thead><tbody><tr><td>Add Contact</td><td>Meshtastic 联系人链接</td><td>活动入网、现场交换节点身份、把队友节点快速加入列表</td><td>需要拿到正确的联系人链接</td></tr><tr><td>Send a Direct Message</td><td>目标节点编号和文本消息</td><td>私聊队长、车台、固定中继维护者，发送少量关键消息</td><td>不适合长消息，最好提前做短句模板</td></tr><tr><td>Send a Waypoint</td><td>名称、描述、图标、经纬度、是否锁定、过期时间</td><td>标记停车点、营地、水源、集合点、风险位置</td><td>位置要准确，避免把临时测试点误当成长期点位</td></tr><tr><td>Send a Group Message</td><td>频道编号和文本消息</td><td>向团队频道发送测试、到达、撤收、求助等固定格式消息</td><td>公共频道不要频繁自动发送</td></tr><tr><td>Get Node Position</td><td>节点编号</td><td>出门前查看固定节点、车载节点、关键队员最后位置</td><td>前提是目标节点有有效位置</td></tr><tr><td>Shut Down</td><td>当前连接节点</td><td>演示结束、临时关闭节点、节省电量</td><td>远程或关键节点不要误触</td></tr><tr><td>Restart</td><td>当前连接节点</td><td>保存配置后重启、现场排障、恢复异常连接</td><td>重启期间节点会短暂离线</td></tr><tr><td>Factory Reset</td><td>当前连接节点和重置选项</td><td>设备交接、彻底清理配置、重新部署前恢复初始状态</td><td>高风险动作，建议单独放在维护快捷指令里</td></tr><tr><td>Save Channel Settings</td><td>Meshtastic 频道链接</td><td>活动前快速导入频道、统一团队配置</td><td>导入前确认频道来源可信</td></tr><tr><td>Disconnect Node</td><td>当前连接节点</td><td>换设备配对、演示结束、避免手机继续占用连接</td><td>只是断开 App 连接，不是关闭节点</td></tr></tbody></table><p>这些动作单独看，好像只是把 App 里的按钮搬到快捷指令里。但一旦放到真实场景里，就会有意思很多。</p><p>比如第一次组队入网时，别人发给你一个 Meshtastic 联系人链接或频道链接，你可以用快捷指令把它保存进 App，而不是每次都手动打开、复制、导入。对活动组织者来说，这很适合做成一个入网准备快捷指令：先保存频道设置，再添加几个核心联系人，最后打开 Meshtastic 的连接页面检查节点是否在线。露营、骑行、搜救演练、展会体验区，都能少很多现场解释成本。</p><p>外出时，发送 waypoint 会很实用。你到了停车点、营地、水源、集合点，或者发现一处危险路段，可以用快捷指令快速丢一个 waypoint 到 mesh 里。它不只是给自己做标记，而是让同一网络里的其他人也能看到这个位置。相比打开 App、找地图、点菜单、填写名称，快捷指令更适合现场快速记录。</p><p>消息也可以做成模板。比如测试网络时发一条固定的频道消息，内容可以是当前位置已到达、准备开始测试、撤收完毕、需要协助这类短句。给指定节点发私聊也适合做成固定流程，比如只通知队长、车台或某个固定中继维护者。这里要克制一点，LoRa 网络带宽有限，自动化不应该变成定时刷屏。更合理的做法，是把它用在少量、高价值、格式固定的消息上。</p><p><img src="/meshtastic-apple-ecosystem-features/shortcuts-dictation-channel-message.webp" alt="用听写文本组合 Meshtastic 发送频道消息动作"></p><p>获取节点位置这个动作也很适合和日常路线结合。比如出门前看一下家里固定节点或车载节点最近一次位置；测试网络覆盖时，快速检查某个节点最后出现在哪里；活动结束后，确认关键节点有没有回到集合点附近。它不是魔法追踪器，前提仍然是对方节点有有效位置，但把这个动作放进快捷指令之后，查询门槛会低很多。</p><p>节点维护类动作则更适合管理员。重启节点、关闭节点、断开连接，这些都可以做成快捷按钮。比如你刚保存完配置，需要重启节点；临时演示结束，要关闭当前连接的节点；或者你把手机交给另一台设备配对前，先断开当前连接。恢复出厂设置也在快捷指令能力里，但这类动作风险很高，最好只放在明确标注、需要确认的维护快捷指令里，不要和日常动作混在一起。</p><p>快捷指令还可以和 Siri 配合。官方已经给出几类语音短语：关机、重启、发送频道消息、断开连接。实际使用时，它的价值不是炫技，而是免手持。你在车上、戴手套、拿着设备爬楼顶、或者正在调天线时，说一句让 Meshtastic 重启节点或给频道发消息，比掏出手机点菜单自然很多。</p><p>更进阶的玩法，是把这些动作和 iOS 快捷指令里的时间、位置、NFC、专注模式、菜单、条件判断组合起来。到达营地时弹出菜单，让你选择发送 waypoint、打开位置共享、进入地图页；靠近某个 NFC 标签时，自动打开对应节点或频道；开启驾驶专注模式时，把 Meshtastic 的 CarPlay 和频道消息入口放到最前面；做设备测试时，用一个菜单选择重启节点、发送测试消息、查看节点位置。这样一来，Meshtastic 不只是一个 App，而是可以嵌进你整套 iPhone 工作流里的工具。</p><p>App 内跳转链接也能和快捷指令配合。你可以让快捷指令直接跳到消息、地图、节点详情、位置配置、Store &amp; Forward、TAK 或调试日志页面。这样就不用每次从首页一层层点进去。对新手来说，这只是少点几下；对经常维护节点的人来说，这会明显提高效率。</p><h2 id="Apple-Watch-不只是-Foxhunt">Apple Watch 不只是 Foxhunt</h2><p>Apple Watch 这部分，是我最喜欢的果粉玩法。</p><p>Meshtastic 的 Watch App 不是简单把 iPhone 通知搬到手表上。它有独立的 watchOS App，会从 iPhone 同步 mesh 节点数据。</p><p>从武汉-TWT 的截图看，手表端收到 Meshtastic 消息时，可以直接在腕上看到发送节点和消息内容。下面这张里，来自 BlackBerry Z10 的消息显示为“超限了”，手表下方还给出了 watchOS 风格的快捷回复入口，适合回一个很短的确认。</p><p><img src="/meshtastic-apple-ecosystem-features/apple-watch-message-reply.webp" alt="Apple Watch 上的 Meshtastic 消息通知和快捷回复入口"></p><p>另一张截图则更像 Apple Watch 上的 Meshtastic 即时摘要：它把在线节点数量和频道利用率压成很小的信息块，必要时再跳回 iPhone 继续操作。它不承担复杂管理，但很适合抬腕快速确认网络有没有人在、信道是不是太拥挤。</p><p><img src="/meshtastic-apple-ecosystem-features/apple-watch-meshtastic-summary.webp" alt="Apple Watch 上的 Meshtastic 即时摘要显示在线节点数量和频道利用率"></p><p>iPhone 会检查你是否配对了 Apple Watch、手表上是否安装了 Meshtastic Watch App，然后把节点列表和位置信息同步过去。如果你在 iPhone 上指定某个节点作为 foxhunt target，手表也会收到这个目标。</p><p>手表上会列出半英里，也就是约 805 米内有位置的节点。被 iPhone 指定为 foxhunt target 的节点，即使超过这个距离，也会被保留在列表里。点进去之后，就是一个专门为手表设计的 Foxhunt 罗盘界面。</p><p>这个 Foxhunt compass 会用 Apple Watch 自己的当前位置和航向，计算你到目标节点的方位和距离。界面上有旋转罗盘、指向目标的箭头、距离显示、冷热颜色提示；当你和目标方向对齐到 10 度以内时，手表还会给触感反馈。手表如果有磁力计，就用指南针；没有的话，会退回到 GPS course，也就是移动方向。</p><p>这个设计很 Apple Watch。它不是把手机上的复杂地图塞进小屏幕，而是把手表最擅长的东西拿出来：抬腕、方向、距离、触感反馈。真正去找节点、找信号源、做近距离方向判断时，它比手机地图更顺手。</p><p>当然，Foxhunt 依赖目标节点有有效位置，也依赖手表自身定位和航向足够可靠。</p><h2 id="还有一些藏得更深的-Apple-能力">还有一些藏得更深的 Apple 能力</h2><p>除了上面这些大功能，Apple 客户端里还有一些容易被忽略的系统能力。</p><p>链接跳转是一个。Meshtastic 支持一整套 App 内跳转链接，可以直接打开消息、连接页、节点、地图、waypoint 和各种设置项。对普通用户来说，这意味着通知、快捷指令、网页和其它 App 都有机会直接把你带到 Meshtastic 的具体页面。</p><p>Apple 地图能力也是一个。Meshtastic 的地图、节点位置、路线、waypoint、发现扫描等功能都围绕地图展开。对于 iPad 和 Mac 用户来说，这种大屏地图体验会比小手机更舒服。</p><p>NFC 也有用武之地。Apple 客户端可以把节点联系人写进 NFC 标签。对现场活动、设备交接、快速分享节点信息来说，这比手动复制链接更自然。</p><p>还有本地网络发现。换句话说，除了蓝牙，Apple 客户端也在利用 Apple 平台的本地网络能力发现和连接节点。</p><h2 id="为什么这件事重要">为什么这件事重要</h2><p>很多开源硬件项目的问题，不是硬件不够酷，而是普通用户很难把它融入日常使用。</p><p>Meshtastic 的硬件世界非常丰富，从低成本开发板、太阳能中继，到成品手持设备、固定高位节点，各种形态都有人在做。但如果客户端体验跟不上，普通用户很容易停在第一次配对、第一次改频道、第一次看不到消息的挫败感里。</p><p>Apple 客户端把 iPhone、iPad、Mac、Apple Watch、CarPlay、Siri、快捷指令、动态岛、地图、NFC、本地网络发现这些能力接进来，本质上是在降低这种摩擦。</p><p>你不一定每个功能都会用。有人只需要 iPhone 配节点，有人会喜欢 iPad 大屏地图，有人会把 Mac 当长期管理端，有人会在车上试 CarPlay，有人会拿 Apple Watch 做 Foxhunt，也有人会在快捷指令里写一套自己的小自动化。</p><p>但这正是 Apple 生态的魅力：同一个 Meshtastic 网络，不同设备可以承担不同角色。</p><p>如果你也是果粉，Meshtastic Apple 客户端值得单独拿出来看。它不是 Android 客户端的简单替代品，也不是只负责蓝牙配置的工具。它已经在把 LoRa mesh 变成 Apple 生态里的一等公民。</p><p>这对 Meshtastic 在普通用户里的传播很重要。毕竟，硬件能不能跑起来决定你会不会入门，而日常体验够不够顺，决定你会不会一直用下去。</p>]]></content>
    
    
    <summary type="html">Meshtastic 已经接入 iPhone、iPad、Mac、Apple Watch、CarPlay、Siri、快捷指令、动态岛和手机 GPS 等 Apple 生态能力。</summary>
    
    
    
    <category term="教程" scheme="https://meshcn.net/categories/%E6%95%99%E7%A8%8B/"/>
    
    
    <category term="Meshtastic" scheme="https://meshcn.net/tags/Meshtastic/"/>
    
    <category term="Apple" scheme="https://meshcn.net/tags/Apple/"/>
    
    <category term="iOS" scheme="https://meshcn.net/tags/iOS/"/>
    
    <category term="CarPlay" scheme="https://meshcn.net/tags/CarPlay/"/>
    
    <category term="Siri" scheme="https://meshcn.net/tags/Siri/"/>
    
  </entry>
  
  <entry>
    <title>远程管理前先留后路：Meshtastic 设备公私钥备份与恢复</title>
    <link href="https://meshcn.net/meshtastic-security-keys-backup-restore/"/>
    <id>https://meshcn.net/meshtastic-security-keys-backup-restore/</id>
    <published>2026-04-19T08:41:00.000Z</published>
    <updated>2026-04-19T08:41:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>上一篇 <a href="/remote-node-admin-meshtastic-tutorial/">《山顶节点不用再爬山：Meshtastic 远程管理节点教程》</a> 发出来之后，很多群友的第一反应是：这个功能确实能省掉不少爬楼、爬山、拆盒子的麻烦。</p><p>但紧接着就会出现另一个问题：如果我手里的控制端节点重新刷了固件，公钥变了，那山上或者楼顶那台节点是不是就不认我了？</p><p>答案是：是的，很可能就不认了。</p><p>新版 Remote Node Admin 的授权逻辑是把控制端的 Public Key 写进被控端的 Admin Key。被控端并不是认你的手机，也不是认你的啥账号，而是认控制端这台 Meshtastic 节点的那一对公私钥。</p><p>在 Meshtastic 里，只要你擦除并重新安装固件，设备里的 Public Key 和 Private Key 就可能丢失并重新生成。新钥匙和旧钥匙不是同一个身份，远端节点自然不会把它当成原来的管理员。</p><p>这篇文章就是给上一篇远程管理教程补上一个很重要的运维习惯：一定要把控制端的钥匙备份好，以及如何恢复到备份过的钥匙。</p><blockquote class="blockquote-note blockquote-note__warning"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="12" height="16" viewBox="0 0 12 16"><path fill-rule="evenodd" d="M5.05.31c.81 2.17.41 3.38-.52 4.31C3.55 5.67 1.98 6.45.9 7.98c-1.45 2.05-1.7 6.53 3.53 7.7-2.2-1.16-2.67-4.52-.3-6.61-.61 2.03.53 3.33 1.94 2.86 1.39-.47 2.3.53 2.27 1.67-.02.78-.31 1.44-1.13 1.81 3.42-.59 4.78-3.42 4.78-5.56 0-2.84-2.53-3.22-1.25-5.61-1.52.13-2.03 1.13-1.89 2.75.09 1.08-1.02 1.8-1.86 1.33-.67-.41-.66-1.19-.06-1.78C8.18 5.31 8.68 2.45 5.05.32L5.03.3l.02.01z"></path></svg></div>先记住这句话</div><div class="blockquote-note__content"><p>只保存 Public Key 不够。远端节点保存的是你的公钥，但真正证明「我是我本人🐕」的，是控制端手里的私钥。公钥可以公开，私钥必须自己保存好。丢了私钥，就不能靠旧公钥继续证明身份。</p></div></blockquote><h2 id="为什么刷机后会失去远程管理权限">为什么刷机后会失去远程管理权限</h2><p>Meshtastic 2.5 之后的远程管理，主要依赖 PKC，也就是公开密钥加密。你可以简单理解为：控制端有一对钥匙，一把是 Public Key，一把是 Private Key。Public Key 可以给别人看，Private Key 只能留在自己设备里。</p><p>当你把控制端的 Public Key 填进山顶节点的 Admin Key 时，山顶节点就相当于在自己的授权名单里记了一条：以后这个公钥对应的设备，可以通过 Mesh 网络发管理命令过来。后面你在手机 App 或 CLI 里远程修改配置时，控制端会用自己的私钥证明身份，远端节点再用之前保存的公钥来验证。</p><p>问题就出在重新刷机这里。普通升级固件不一定会擦掉设备配置，但如果你执行了 erase、full erase、factory reset、重新安装时清空了设备存储，或者换了一块新控制端，那么原来的公私钥就没了。设备会生成一对新的钥匙。这个新公钥没有写进山顶节点的 Admin Key 里，山顶节点也无法知道它其实还是你。</p><p>所以最后就会出现一个很尴尬的场景：你明明还看得到远端节点，也知道它在那里，但 Remote Admin 操作发过去就是没有权限。要修这个问题，要么你能把旧钥匙恢复回控制端，要么就只能找另一台已经授权的控制端，或者亲自去接触远端节点，把新的公钥重新写进去。</p><h2 id="大多数人会先用-App：手动备份公钥和私钥">大多数人会先用 App：手动备份公钥和私钥</h2><p>从完整性来说，Meshtastic 更推荐用 CLI 导出配置。但现实情况是，很多读者平时就是拿手机 App 配节点，不一定会为了备份钥匙专门打开电脑、装 Python、装 CLI。所以这篇文章先讲 App 方法，门槛最低，符合大多数读者的使用习惯。</p><p>在 App 的 Security 页面里，你至少应该把 Public Key 和 Private Key 都保存下来，而且要把它们当成一对保存。不要只存 Public Key，也不要把 A 设备的 Public Key 和 B 设备的 Private Key 混在一起。</p><p>Public Key 可以复制给远端节点作为 Admin Key；Private Key 则必须放到安全位置。最好的位置是密码管理器，比如 1Password、Bitwarden、iCloud 钥匙串这些常用的密码管理器 App。</p><p>截图也可以作为最基础的兜底办法，但它的问题很明显：截图容易丢、容易被相册同步到不该同步的地方，也可能因为截得不完整而漏掉一部分钥匙。如果只能截图，至少确认 Public Key 和 Private Key 都完整出现在图片里。</p><p>要手动恢复时，就回到 App 的 Security 页面，把同一份备份里的 Public Key 和 Private Key 分别粘贴回对应字段，并保存。这里的关键点是「成对恢复」：这两个值必须来自同一台设备、同一次备份，最好在同一次操作里一起粘贴回去。如果你只粘贴 Public Key，没有恢复对应的 Private Key，控制端看起来可能显示了旧公钥，但它没有那把能证明身份的私钥，远端节点仍然不会认它。如果你只粘贴 Private Key，或者粘贴了一对不匹配的钥匙，也会出现身份对不上的问题。</p><p>恢复完成后，同样建议检查 App 里显示的 Public Key 是否和远端节点 Admin Key 里保存的那一串一致。只要 Public Key 和 Private Key 这对钥匙都恢复成功，控制端的远程管理身份就回来了。</p><h2 id="更完整的方法：用-CLI-导出完整配置">更完整的方法：用 CLI 导出完整配置</h2><p>如果你愿意用电脑操作，官方更推荐的备份方式，是使用 Meshtastic CLI 导出配置。这个方法的好处是最完整，不只是保存公钥和私钥，也会把设备当前配置一起导出成一个 YAML 文件。以后恢复时，一条命令就能把设备尽量恢复到原来的状态。</p><p>如果你还没有安装 CLI，可以先看官方的 <a href="https://meshtastic.org/docs/software/python/cli/">Meshtastic CLI 文档</a>。安装好之后，用 USB 连接你准备作为控制端的那台节点，在终端里执行：</p><pre><code class="hljs bash">meshtastic --export-config &gt; config_backup.yaml</code></pre><p>执行完成后，当前目录会多出一个 <code>config_backup.yaml</code> 文件。这个文件就是你的设备配置备份，里面包含 Public Key 和 Private Key。也正因为它包含私钥，所以不要把它随便发到微信群、论坛、GitHub 仓库或者公开网盘里。它应该像密码一样保存。</p><p>比较稳妥的做法，是把这个 YAML 文件放进你平时真正会用的备份体系里，比如群友最爱用的飞牛 NAS 系统。文件名也建议写清楚一点，例如：</p><pre><code class="hljs text">meshtastic-control-node-bg2xxx-2026-04-19.yaml</code></pre><p>以后你看到这个文件名，就能知道它是哪台控制端、什么时候导出的配置。等你手里有多台控制端时，这个习惯会非常省事。</p><h2 id="恢复钥匙：让控制端重新变回原来的身份">恢复钥匙：让控制端重新变回原来的身份</h2><p>如果控制端已经被擦除重刷，或者你换了同型号设备但希望它继续拥有原来的远程管理身份，可以用之前导出的 YAML 恢复配置：</p><pre><code class="hljs bash">meshtastic --configure config_backup.yaml</code></pre><p>这条命令会把备份文件里的配置写回当前连接的设备。恢复完成后，建议重新打开 App 或 CLI 读取一下 Security 里的 Public Key，和备份前记录的旧公钥对比一下。只要公钥一致，远端节点原来保存的 Admin Key 就还能继续匹配，你就不需要再跑到山顶或楼顶重新授权。</p><p>这里要注意，恢复配置不是一个「随便导入到任何节点都没有影响」的动作。YAML 里可能包含频道、蓝牙、LoRa、模块、节点名称等设置。如果你只是想恢复某台控制端的身份，最好把它恢复到原本那台设备，或者至少先确认你愿意让当前设备继承这份配置。不要拿一份控制端备份到处给别的设备导入，否则很容易把多个节点搞成同一个身份或同一套配置。</p><h2 id="已经丢了钥匙怎么办">已经丢了钥匙怎么办</h2><p>如果控制端已经擦除重刷，而之前没有备份 Private Key，那就不要再纠结能不能从旧 Public Key 反推出私钥了。按现代公开密钥加密的设计，这条路就是走不通的。</p><p>这时你还有三个现实选项。</p><p>第一，看看被控节点的 Admin Key 里有没有授权过第二台控制端。如果有，就用那台还能管理的设备连过去，把新控制端的 Public Key 加进去。Meshtastic 的 Admin Key 通常有多个槽位，上一篇远程管理教程里也提到过，最多可以授权 3 台不同控制端。这个设计在这里就很有价值。</p><p>第二，如果远端节点还有本地可达方式，比如它其实在楼顶但还能通过 USB、蓝牙或局域网 TCP 接触到，那就直接连上它，把新控制端的 Public Key 写进 Admin Key。</p><p>第三，如果前两条都没有，那就只能现场维护。对山顶太阳能节点、塔杆节点、楼顶防水盒来说，这就是大家最不想遇到的情况：不是因为远程管理功能不好用，而是因为最开始没有给控制端留后路。</p><h2 id="给长期部署节点的一套习惯">给长期部署节点的一套习惯</h2><p>长期部署的节点，最好把钥匙备份当成部署流程的一部分：先刷好控制端并完成基础设置，再备份这台控制端的 Public Key 和 Private Key，最后再把它的 Public Key 写进远端节点的 Admin Key。</p><p>如果远端节点很难接触，不要只授权一台控制端。每个被控端最多可以添加 3 个控制端的 Admin Key，我建议山上、楼顶这类节点尽量把 3 个额度都用满。这样就算其中一台控制端坏了、丢了，或者公私钥没有备份好，仍然还有另外两台设备可以远程访问。备份文件和截图也不要随手外发，它们的价值和密码差不多，目标是自己能找回、别人拿不到。</p><h2 id="总结">总结</h2><p>Remote Node Admin 解决的是「远端节点不用再爬上去改设置」的问题，但它有一个前提：控制端的身份要稳定。对于 Meshtastic 来说，这个身份就是设备里的公私钥。</p><p>所以在启用远程管理之前，先做一次钥匙备份。大多数读者会更习惯用 App：进入 Security 页面，把同一对 Public Key 和 Private Key 保存到密码管理器里；以后恢复时，也把这一对钥匙一起粘贴回对应字段。</p><p>如果你愿意用电脑，Meshtastic 更推荐 CLI 的完整导出方式：</p><pre><code class="hljs bash">meshtastic --export-config &gt; config_backup.yaml</code></pre><p>CLI 恢复时使用：</p><pre><code class="hljs bash">meshtastic --configure config_backup.yaml</code></pre><p>只要这一步做了，将来控制端重刷固件、换设备、误清空配置时，你还有机会把原来的身份恢复回来。否则等山顶节点只认旧公钥，而你手里只剩新公钥时，远程管理就会重新变成现场维护。</p>]]></content>
    
    
    <summary type="html">Remote Node Admin 很好用，但控制端一旦擦除重刷，公钥和私钥可能会重新生成，原来授权过的山顶节点就不认你了。本文讲清楚为什么会这样，以及如何用 CLI、密码管理器或截图备份并恢复 Meshtastic 设备钥匙。</summary>
    
    
    
    <category term="教程" scheme="https://meshcn.net/categories/%E6%95%99%E7%A8%8B/"/>
    
    
    <category term="CLI" scheme="https://meshcn.net/tags/CLI/"/>
    
    <category term="远程管理" scheme="https://meshcn.net/tags/%E8%BF%9C%E7%A8%8B%E7%AE%A1%E7%90%86/"/>
    
    <category term="安全" scheme="https://meshcn.net/tags/%E5%AE%89%E5%85%A8/"/>
    
    <category term="PKC" scheme="https://meshcn.net/tags/PKC/"/>
    
  </entry>
  
  <entry>
    <title>如何读取漏掉的消息：Meshtastic 存储与转发功能教程</title>
    <link href="https://meshcn.net/store-and-forward-meshtastic-tutorial/"/>
    <id>https://meshcn.net/store-and-forward-meshtastic-tutorial/</id>
    <published>2026-04-02T03:20:00.000Z</published>
    <updated>2026-04-02T03:20:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>很多人刚开始用 Meshtastic 的时候，会默认以为消息天然就会一直在那里等着自己。可它更像电视直播，而不是点播视频。你要在电视开着的时候，才能看到当下正在播的节目；如果那时候电视没开，节目播过去了，后面就不会自动补给你看。</p><p>Meshtastic 里的消息，在很多时候也是类似的逻辑。你在线时收到，离线时没收到，那一段内容很可能就这么过去了。可一旦你开始认真部署节点，尤其是山顶节点、楼顶节点、车载节点、手持节点混着用的时候，这个问题很快就会冒出来。比如你刚好下山、进楼、进电梯，或者一段时间离开了 LoRa 覆盖范围，等你重新回到网络里时，就会发现中间那段消息已经不在自己设备的缓存里了。</p><p>Store &amp; Forward 模块解决的，正是这种临时掉线后的补消息问题。简单说，它允许一台专门的服务器节点帮你暂存收到的文本消息；当客户端设备重新回到覆盖范围内，就可以向这台服务器请求历史消息，把自己错过的那一段补回来。</p><p>这个功能不是每个人都必须开，但如果你的网络里已经有固定常在线的高位节点，或者你经常让部分设备临时离网再回来，它就会非常有价值。很多人搭了基础设施节点之后，最先补上的往往不是更远的天线，而是这一类让网络更像网络的辅助能力。</p><h2 id="Store-Forward-到底是做什么的">Store &amp; Forward 到底是做什么的</h2><p>Store &amp; Forward 的核心思路并不复杂。网络里有一台特殊的 Store &amp; Forward Server，它会把自己收到的文本消息存起来。当某台客户端设备回来之后，它可以向这台服务器请求一段时间窗口内的历史消息，服务器再通过 LoRa 把这些文本消息重新发出来。</p><p>这件事和设备本地那几十条左右的普通缓存不是一回事。自从 Meshtastic 2.4 之后，当你用客户端 App 连接到 Store &amp; Forward Server 本机时，历史消息会自动拉取回来，容量通常也会比设备本地默认缓存大得多。所以它更像是给网络加了一个专门负责补课的消息中转站，而不是单纯把缓存再做大一点。</p><p><img src="./store_and_forward-overview.webp" alt="Store &amp; Forward 工作原理示意图"></p><p>Store &amp; Forward 并非万能，有两点要注意</p><ol><li>Store &amp; Forward 只知道自己收到了哪些消息，并不知道你到底漏了哪几条，所以补回来的内容可能会有重复</li><li>第二，请求历史消息时，服务器可能在短时间内重发很多文本消息，这会给整张 Mesh 带来一波额外负载，因此不能毫无节制地频繁拉历史。</li></ol><p>这个功能最适合的，不是完全静止不动的单机使用，而是网络里已经有一个相对稳定的常在线节点（比如枢纽节点），另一部分节点会临时离开覆盖范围再回来（比如手持节点）。</p><p>最典型的例子，就是楼顶或者山顶放着一台常年在线的节点做基础设施，手里的手持节点白天移动、晚上回来；又或者你有一台阳台基站常年在线，出门携带的设备中途经过信号盲区，回家以后再把错过的文本消息补回来。再比如测试环境里两台普通客户端互相发消息，第三台固定服务器节点帮忙存档，这样其中一台临时掉线后，回来还能主动索取历史。</p><p>如果你的网络里没有常在线节点，或者服务器自己也经常离线，那 Store &amp; Forward 的效果就会打折。因为服务器一旦自己漏收消息，它当然也就没法帮你补回来。</p><p>Store &amp; Forward Server 不是随便一款 Meshtastic 设备都能做。它必须是基于 ESP32 的设备，并且板载带有 PSRAM。</p><p>如果设备没有这部分硬件条件，就不要先急着在配置里找开关，因为就算你把模块打开了，它也不一定能稳定承担服务器角色。</p><p>Store &amp; Forward 是给有条件的基础设施节点准备的功能，而不是给所有手持和低功耗节点默认打开的通用模块。</p><h2 id="这个功能大概怎么搭起来">这个功能大概怎么搭起来</h2><p>如果你想通过 LoRa 方式直接测试 Store &amp; Forward（简称 SF），最好准备至少三台设备。</p><p>一台是带 PSRAM 的 ESP32 节点，用来做 SF 服务器；另外两台是普通客户端 <code>client</code>。其中一台在另一台不在线的时候发文本消息，等离线那台重新回到范围后，再向服务器请求历史消息，看能不能把漏掉的内容补回来。</p><p>如果你是配合手机客户端来体验这个功能，最少两台设备也够。一台是 Store &amp; Forward Server，另一台负责在你没有连接 App 到服务器时发送文本消息。之后你再用 App 连接到这台服务器，自 2.4 之后，历史消息会自动被取回并显示出来。</p><p>无论哪种用法，服务器节点都应该尽量保持长期在线。Store &amp; Forward 不是一个适合轮流开关机的功能，服务器自己漏消息越多，客户端能补回来的内容就越不完整。</p><h2 id="服务器怎么配置">服务器怎么配置</h2><p>你可以在模块里直接把 <code>store_forward.is_server</code> 设为 <code>true</code>，也可以把节点配置成 <code>ROUTER</code>。</p><p>我会建议先从 <code>store_forward.is_server</code> 设置开始。</p><p>两种思路都能让这台节点承担服务器角色，而 <code>is_server</code> 这种方式是 2.4 之后才有的。</p><p>更实用的建议是，给这台节点起一个一眼就能认出的名字，比如在节点名里带上 <code>S&amp;F</code> 或者 <code>Store</code>，这样以后在节点列表里比较容易认出来。</p><p>真正要开的基础配置其实不多，最关键的是先启用模块：</p><pre><code class="hljs bash">meshtastic --<span class="hljs-built_in">set</span> store_forward.enabled <span class="hljs-literal">true</span></code></pre><p>如果你确定客户端已经知道这台服务器是谁，或者你主要是通过 App 直接连接到服务器本机来取历史，而不是靠它在网络里持续广播存在感，那还可以考虑关闭 heartbeat，减少额外流量：</p><pre><code class="hljs bash">meshtastic --<span class="hljs-built_in">set</span> store_forward.heartbeat <span class="hljs-literal">false</span></code></pre><p>heartbeat 默认会周期性告诉网络里其他设备，附近有一台 Store &amp; Forward Server 在监听消息。这个机制有用，但在一些本来就比较忙的网络里，能少一类周期广播就少一类，所以很多人实际部署时会把它关掉。</p><h2 id="客户端怎么取回历史消息">客户端怎么取回历史消息</h2><p>现在这个功能在 Android 和 Apple 客户端上都已经有可用支持，文档里提到的版本门槛是 2.2.23 及以上。</p><p>Android 的做法比较直接。如果你要通过 LoRa 主动向服务器索取历史，需要给那台 Store &amp; Forward Server 发一条私信，内容就是 <code>SF</code>。服务器收到之后，就会把你请求范围内的历史文本消息重新发出来。</p><p>苹果端的体验更图形化一些。只要设备先听到了服务器的 heartbeat，它就能在节点列表里把这台节点显示为 Store &amp; Forward Server。之后你可以长按这个节点，选择 <code>Client History</code> 来请求历史消息。</p><p>另外，自从 2.4 之后，如果你不是通过 LoRa 命令去索取，而是客户端 App 直接连接到了 Store &amp; Forward Server 本机，那么历史消息会自动取回并显示出来。这也是为什么很多人把它和固定基站放在一起用时，体验会明显比纯设备本地缓存更好。</p><p>需要注意的是，通过 LoRa 请求历史消息这件事，在默认公共频道上并不可用。所以如果你准备认真测试，最好是在自己的网络环境里做，不要直接拿默认公共频道去试。</p><h2 id="配置项到底该怎么理解">配置项到底该怎么理解</h2><p>Store &amp; Forward 的配置项不算多，但每一个都和网络负载或者消息保留能力直接相关，所以值得单独讲清楚。</p><p><code>Enabled</code> 很简单，就是开关本身，决定这个模块是否启用。</p><p><code>Heartbeat</code> 控制服务器是否周期性往网络里发送存在告知。它的意义是让 Android、iOS、Web 这一类客户端知道附近有可用的 Store &amp; Forward Server，但代价就是会增加一点周期性流量。</p><p><code>History Return Max</code> 是客户端每次请求历史时，服务器最多返回多少条消息。默认值写成 <code>0</code> 时，实际表示使用默认上限，也就是 25 条。这个值越大，单次补回来的消息越多，但给网络带来的瞬时压力也越大。</p><p><code>History Return Window</code> 是客户端允许请求的时间窗口，单位是分钟。默认 <code>0</code> 表示 240 分钟，也就是 4 小时。你可以理解成，客户端一次最多能向服务器追溯多长时间范围内的消息。</p><p><code>Records</code> 决定服务器最多保存多少条记录。默认写成 <code>0</code> 时，模块会自动使用设备可用 PSRAM 的三分之二。文档给出的量级大约是 11000 条记录，这也是为什么服务器必须依赖带 PSRAM 的设备。</p><p><code>Is Server</code> 是把这台节点直接指定为 Store &amp; Forward Server 的开关。它是把节点设为 <code>ROUTER</code> 之外的另一种配置方式，只在 2.4 及以后的版本里可用。</p><p>参数怎么取值，并没有适合所有网络的一套万能答案。节点少、消息少的网络，可以放宽一点；节点多、流量重的网络，通常就该保守一些，尤其别把历史窗口和返回上限同时拉得太夸张。</p><h2 id="不同客户端从哪里配置">不同客户端从哪里配置</h2><p>Android 端已经提供 Store &amp; Forward 的配置页面，入口在 <code>Settings &gt; Store &amp; Forward</code>。</p><p>Apple 端在 iOS、iPadOS 和 macOS 上都提供完整配置，入口是 <code>Settings &gt; Module Configuration &gt; Store &amp; Forward</code>。</p><p>Web 端同样可以配置全部相关选项，位置在 <code>Config &gt; Module Config &gt; S&amp;F</code>。</p><p>CLI 则最适合做精确控制，尤其是你已经习惯用命令行改模块参数的时候。对应的主要字段如下：</p><table><thead><tr><th>配置项</th><th>可接受值</th><th>默认值</th></tr></thead><tbody><tr><td><code>store_forward.enabled</code></td><td><code>true</code> / <code>false</code></td><td><code>false</code></td></tr><tr><td><code>store_forward.heartbeat</code></td><td><code>true</code> / <code>false</code></td><td><code>false</code></td></tr><tr><td><code>store_forward.history_return_max</code></td><td><code>integer</code></td><td><code>0</code>，表示默认 25 条</td></tr><tr><td><code>store_forward.history_return_window</code></td><td><code>integer</code></td><td><code>0</code>，表示默认 240 分钟</td></tr><tr><td><code>store_forward.records</code></td><td><code>integer</code></td><td><code>0</code>，约 11000 条记录</td></tr><tr><td><code>store_forward.is_server</code></td><td><code>true</code> / <code>false</code></td><td><code>false</code></td></tr></tbody></table><p>文档里还特别提醒了一点：CLI 每发一条配置命令，设备通常都会重启一次。所以如果你要连续改同一组配置，最好把命令串起来一次发完，不然来回重启会很拖，也容易出错。比如：</p><pre><code class="hljs bash">meshtastic --<span class="hljs-built_in">set</span> store_forward.enabled <span class="hljs-literal">true</span> --<span class="hljs-built_in">set</span> store_forward.history_return_max 0</code></pre><h2 id="实际部署时最容易踩的坑">实际部署时最容易踩的坑</h2><p>第一个坑，是把一台并不稳定在线的节点当成服务器。Store &amp; Forward 的前提就是服务器比别人更稳定，如果它自己也时断时续，那你指望它帮别人补消息，效果自然不会好。</p><p>第二个坑，是忽视网络负载。服务器需要把大量信息通过 LoRa 发一遍。你把窗口开太大、返回条数设太高，短时间内就可能让 mesh 网络过载。</p><p>第三个坑，是误以为它能精确知道你漏了哪些消息。实际上服务器只会按请求条件重发自己存到的文本消息，它并不知道客户端到底缺哪几条，所以收到重复消息是正常现象，不是功能出错。</p><p>第四个坑，是在默认公共频道上测试 LoRa 历史请求。文档已经明确写了，这种请求方式在默认公共频道上不可用。</p><h2 id="总结">总结</h2><p>Store &amp; Forward 不是那种装上就立刻让信号变远的功能，但它能明显改善网络的可用性。</p><p>尤其是当你的网络里已经有一两台长期在线的固定节点，而其他节点会临时离网再回来时，它能把很多原本会断掉的文本消息重新补回来。</p>]]></content>
    
    
    <summary type="html">Store &amp; Forward 是 Meshtastic 里一个很容易被忽略，但在高位基站、固定中继和临时离线场景里非常实用的功能。本文把它的工作原理、服务器要求、客户端取回历史消息的方法，以及 Android、苹果、CLI、Web 的配置入口一次讲清楚。</summary>
    
    
    
    <category term="教程" scheme="https://meshcn.net/categories/%E6%95%99%E7%A8%8B/"/>
    
    
    <category term="CLI" scheme="https://meshcn.net/tags/CLI/"/>
    
    <category term="ESP32" scheme="https://meshcn.net/tags/ESP32/"/>
    
    <category term="Store and Forward" scheme="https://meshcn.net/tags/Store-and-Forward/"/>
    
    <category term="模块" scheme="https://meshcn.net/tags/%E6%A8%A1%E5%9D%97/"/>
    
  </entry>
  
  <entry>
    <title>山顶节点不用再爬山：Meshtastic 远程管理节点教程</title>
    <link href="https://meshcn.net/remote-node-admin-meshtastic-tutorial/"/>
    <id>https://meshcn.net/remote-node-admin-meshtastic-tutorial/</id>
    <published>2026-04-01T03:30:00.000Z</published>
    <updated>2026-04-01T03:30:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>随着群友的山顶太阳能节点和楼顶太阳能节点越来越多，一个问题也越来越常见：能不能不跑到现场，也不拿着手机贴着蓝牙去改设置？毕竟有些节点装在楼顶，有些节点架在山上，平时部署一次就已经不轻松了，如果每次想改个参数、开个模块、修个配置都得再爬一趟，维护成本确实很高。</p><p>这正是 Meshtastic 的 Remote Node Admin 要解决的问题。它允许你通过 Mesh 网络，去远程读取和修改另一个节点的设置。换句话说，只要链路还通，你就可以在自己的控制节点上，像平时改本地节点一样，对远端节点做管理，而不必依赖现场蓝牙、USB 串口或者局域网 TCP。</p><p>社区里以前已经有大佬写过旧版远程管理，也就是 legacy Admin channel 的介绍文章。如果你想了解早期方案，可以先看这篇 <a href="/remote-management-pkc-tutorial-meshtastic/">【超越蓝牙、WiFi、串口】使用 Meshtastic mesh 网络远程管理节点</a>。不过从现在的使用角度来看，Meshtastic 2.5 之后的新版远程管理已经简单很多，也更安全，绝大多数用户应该优先用新版方法。</p><blockquote class="blockquote-note blockquote-note__warning"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="12" height="16" viewBox="0 0 12 16"><path fill-rule="evenodd" d="M5.05.31c.81 2.17.41 3.38-.52 4.31C3.55 5.67 1.98 6.45.9 7.98c-1.45 2.05-1.7 6.53 3.53 7.7-2.2-1.16-2.67-4.52-.3-6.61-.61 2.03.53 3.33 1.94 2.86 1.39-.47 2.3.53 2.27 1.67-.02.78-.31 1.44-1.13 1.81 3.42-.59 4.78-3.42 4.78-5.56 0-2.84-2.53-3.22-1.25-5.61-1.52.13-2.03 1.13-1.89 2.75.09 1.08-1.02 1.8-1.86 1.33-.67-.41-.66-1.19-.06-1.78C8.18 5.31 8.68 2.45 5.05.32L5.03.3l.02.01z"></path></svg></div>先看风险提示</div><div class="blockquote-note__content"><p>Remote Node Admin 是一个很实用，但也确实有风险的高级功能。因为你修改的是远端节点的无线参数、角色、频道、安全设置，一旦改错，节点可能直接从当前 Mesh 里掉线。</p><p>最典型的例子就是把频道、区域、LoRa 参数或者管理员权限改乱后，你自己就无法再连过去了。</p><p>如果是第一次用，最好先拿一台测试节点练手，确认流程没问题，再碰那些挂在高处、平时不方便接触的正式节点。</p></div></blockquote><h2 id="Remote-Node-Admin-到底是什么">Remote Node Admin 到底是什么</h2><p>默认情况下，Meshtastic 节点只会响应来自本地接口的管理指令，比如 USB、蓝牙或者 TCP。这个设计本身就是一种基础安全措施，避免任何能收到无线数据的人都来尝试改你的节点。</p><p>Remote Node Admin 的区别在于，管理命令不是从本地接口发过去，而是以加密的管理消息形式，通过 Mesh 网络发送给远端节点。也就是说，表面上看你是在远程改设置，但本质上还是 Meshtastic 在网络里安全地传递管理命令。</p><h2 id="先分清楚：你用的是新版还是旧版">先分清楚：你用的是新版还是旧版</h2><p>这个功能最容易让人混淆的点，就是不同固件版本的实现方式不一样。</p><p>如果你的节点固件是 <strong>2.5 及以后版本</strong>，远程管理的主流方法是 <strong>PKC 公钥授权</strong>。</p><p>做法很简单：把控制节点的 Public Key，填进被控节点的 Security 配置里的 Admin Key 字段中。被控节点最多可以保存 3 个不同的 Admin Key，也就是说，最多可以授权 3 台不同的控制节点去管理它。</p><p>如果你的节点还是 <strong>2.4.x 及更早版本</strong>，那就不能用这个新方法，而是要走老方案：额外建一个名为 <code>admin</code> 的二级频道，并共享同一把 PSK。这个方法就是大家以前常说的 Legacy Admin channel。它现在在 2.5 之后的固件里依然还留着，但主要用途只是为了兼容去管理老节点。<strong>2.5 及以后的节点，不能靠 Legacy Admin channel 被管理。</strong></p><p>目前应该大部分读者都在用 2.5 后的版本。</p><h2 id="使用前你需要准备什么">使用前你需要准备什么</h2><p>正式开始之前，先确认几件事。</p><p>第一，你至少要有两台节点，一台是你手上的控制节点，另一台是准备被远程管理的目标节点。</p><p>第二，这两台节点要已经能在同一个 Mesh 网络里互相看见，至少链路基本通畅，否则你权限配好了也发不过去。</p><p>第三，建议先确认两台节点的固件版本，避免你以为自己在配新版，两个设备固件版本都要 2.5 及以后。</p><p>第四，如果你准备远程改比较核心的参数，比如频道、区域、LoRa 预设、角色，最好先备份一下配置。</p><h2 id="新版-Remote-Admin：PKC-公钥授权怎么配">新版 Remote Admin：PKC 公钥授权怎么配</h2><p>新版方法的核心逻辑其实只有一句话：把控制端的公钥，写进被控端的 Admin Key。</p><p>你可以把它理解成给远端节点发一张授权名单。谁的公钥在名单里，谁就有资格通过 Mesh 网络给这台节点发送管理命令。这个思路比早年的共享 <code>admin</code> 频道安全得多，因为不再是谁拿到频道 PSK 谁就都能管，而是明确到具体某一台节点。</p><h3 id="Android-用户">Android 用户</h3><p>如果你用的是 Android，先连接到将来要作为控制端的那台本地节点。进入设置里的 Security 页面，找到它的 Public Key，复制下来。</p><p>然后切换连接到那台准备被远程管理的目标节点，进入同一个 Security 页面，点击新增，把刚才复制的 Public Key 粘贴到 Admin Key 字段里并保存。最多可以填 3 个不同的 Admin Key，对应最多 3 台控制节点。</p><p>授权配好之后，再重新连接回控制端节点。打开节点列表，点选你要管理的远端节点，进入详细页面，在齿轮旁边找到 Remote Administration。进入之后，常见的 Radio 和 Module 配置项就都可以像本地操作那样去修改了。</p><h3 id="苹果用户">苹果用户</h3><p>苹果端的逻辑和 Android 类似，但入口位置稍有不同。先连接到控制端节点，在 <code>Settings &gt; App Settings</code> 里把 Administration 打开。然后进入 <code>Settings &gt; Radio Configuration &gt; Security</code>，找到这台控制节点的 Public Key，复制下来。</p><p>接着连接到被控节点，在 <code>Settings &gt; Radio Configuration &gt; Security</code> 里，把控制端的公钥添加到 Admin Key。这里同样最多可以保存 3 个控制端公钥。</p><p>完成后，再切回控制端节点，进入 <code>Settings</code>，在 <code>Settings &gt; Configure Node</code> 中选择你要管理的远端节点。此时应用会把支持的 Radio 和 Module 设置展示出来，你就在这里直接改远端节点的配置即可。管理结束后，记得再切回你自己的本地节点，避免后面以为自己改的是本机，实际改的是远端。</p><h3 id="CLI-用户">CLI 用户</h3><p>如果你更习惯命令行，这个功能其实也很好用，而且特别适合做批量运维或者临时抢修。</p><p>先用 USB 连上控制端节点，取出它的公钥：</p><pre><code class="hljs bash">meshtastic --get security.public_key</code></pre><p>把这段公钥保存好之后，再用 USB 连上被控节点，把控制端公钥写进它的 Admin Key：</p><pre><code class="hljs bash">meshtastic --<span class="hljs-built_in">set</span> security.admin_key <span class="hljs-string">&quot;base64:PASTEPUBLICKEYHERE&quot;</span></code></pre><p>之后就可以从控制端对远端节点发起读写操作了。CLI 下远程管理的关键，是在命令里加上 <code>--dest</code>，后面跟目标节点的 <code>!nodeid</code>。目前远程管理主要支持 <code>--get</code> 和 <code>--set</code>。例如：</p><pre><code class="hljs bash">meshtastic --<span class="hljs-built_in">set</span> security.admin_key <span class="hljs-string">&quot;PASTEPUBLICKEYHERE&quot;</span> --dest <span class="hljs-string">&#x27;!28979058&#x27;</span></code></pre><p>如果你用的是 Linux 或 macOS，<code>!nodeid</code> 最好放在单引号里；Windows 下通常可以直接写，不一定需要引号。</p><h3 id="Web-用户">Web 用户</h3><p>如果你用的是 Meshtastic Web Client，它目前能做的是帮你完成授权这一步，但还不能真正执行远程管理命令。</p><p>做法是先连接到控制端节点，进入 <code>Config &gt; Radio Config &gt; Security</code>，找到控制端的 Public Key，复制出来。然后连接到被控节点，在同样的 Security 页面里把这个公钥填到 Admin Key 并保存。</p><p>需要注意的是，当前 Web 界面一次只能填一个 Admin Key，所以它更适合做简单授权，不太适合做多控制端管理。另外，Web Client 目前不支持直接发送 Remote Admin 操作命令，所以真正要远程改配置，还是得回到 Android、苹果 App 或 CLI。</p><h2 id="旧版-Legacy-Admin-channel-什么时候还会用到">旧版 Legacy Admin channel 什么时候还会用到</h2><p>如果你的网络里还有 2.4.x 或更早版本的老节点，这时 Legacy Admin channel 依然有用。方法就是额外建立一个名为 <code>admin</code> 的二级频道，并让相关节点共享同一把 PSK。随后在 Security 配置里启用 Legacy Admin channel，具体操作可以参考 <a href="/remote-management-pkc-tutorial-meshtastic/">【超越蓝牙、WiFi、串口】使用 Meshtastic mesh 网络远程管理节点</a>。</p><p>但这里要强调一次，这个方法的定位已经变了。它现在主要是为了兼容老固件，而不是推荐的新方案。因为只要一个节点加入了这个 <code>admin</code> 频道，并且知道频道 PSK，它理论上就具备管理能力，这和新版按公钥逐台授权的安全模型不是一个级别。</p><p>如果你要用 CLI 启用 Legacy Admin，可执行：</p><pre><code class="hljs bash">meshtastic --<span class="hljs-built_in">set</span> security.admin_channel_enabled</code></pre><p>还是那句话，这条路只建议在必须兼容旧节点的前提下走。只要目标节点已经是 2.5 或更新版本，就不要再指望用这个办法去管理它。</p><h2 id="实战里最容易踩的坑">实战里最容易踩的坑</h2><p>真正麻烦的往往不是不会配，而是配对了但把远端节点配没了。</p><p>第一个常见坑，是远端节点虽然已经加了你的 Admin Key，但链路并不稳定。权限没问题，不代表命令一定传得过去。所以在你准备远程修改参数之前，最好先确认这个远端节点平时的信号、跳数和连接质量是可用的。</p><p>第二个坑，是一次性去改太多核心参数。比如你在远端直接改频道、区域、LoRa 预设，甚至顺手把自己控制端的 Admin Key 也删了，这些操作都可能让节点瞬间脱网。稳妥的做法是分步骤改，每改完一项先确认节点还在线，再继续下一项。</p><p>第三个坑，是把新版和旧版方法混在一起理解。现在很多新用户看到 admin 这个词，第一反应还是去建 <code>admin</code> channel，但如果目标节点本来就是 2.5 之后的新固件，这条路本身就不是正解。你应该先检查的是 Security 里的 Admin Key 有没有配好，而不是频道里有没有 <code>admin</code>。</p><p>第四个坑，是苹果端用户在管理完远端节点后忘了切回本地节点。这样后面你看到设置页面还在，以为改的是自己手里的机器，实际可能还在操作远端。这个小坑很常见，尤其是在你一边测一边改的时候。</p><h2 id="这项功能最适合哪些场景">这项功能最适合哪些场景</h2><p>如果你的节点只是放在桌边，蓝牙一连就能改，那 Remote Node Admin 当然不是刚需。但一旦节点进入装上去就不想再碰的状态，它就会从一个高级功能，直接变成一个非常实用的维护工具。</p><p>最典型的场景就是山顶太阳能节点、楼顶中继节点、阳台常电节点、挂杆节点和长期无人值守节点。你可能只是想改一个广播间隔、调一个模块开关、换一个节点角色，或者临时补一个管理员权限，如果没有远程管理，这些小调整都会变成一次实体维护。</p><p>从这个角度看，Remote Node Admin 的价值并不只是高级，而是它真正把 Meshtastic 网络从能通信推进到了能运维。尤其是当你的网络开始有固定基础设施节点之后，这个功能基本就值得尽早配上。</p><h2 id="Managed-Mode：高位固定节点常见的配合功能">Managed Mode：高位固定节点常见的配合功能</h2><p>如果你的节点已经不是随手就能摸到的设备，而是长期挂在高山、楼顶、塔杆或者阳台外侧，除了开启 Remote Node Admin，很多人还会再配合打开 Managed Mode。</p><p>Managed Mode 的取值只有 <code>true</code> 和 <code>false</code>。它的作用不是让远程管理生效，而是限制客户端应用直接写入电台配置。开启之后，普通客户端依然可以读取这台节点的配置，但不能直接修改配置。</p><p>这时如果还想改这台节点的配置，就只能走管理员通道。在 2.5 及以后固件上，必须通过 PKC Remote Admin 消息来改；在 2.5 之前的老固件上，则只能通过 legacy Admin channel 去改。所以对于很多高山节点、楼顶节点和长期无人值守节点来说，Remote Node Admin 负责解决远程维护问题，Managed Mode 负责把配置权限收紧，两者经常一起使用。</p><p>不过要注意，Managed Mode 不是 Remote Node Admin 的必需条件。不开它，远程管理照样能用。它更像是一个额外的安全和运维策略，适合那些已经固定部署、不希望被日常客户端误改配置的节点。</p><p>真正需要小心的是锁死风险。在开启 Managed Mode 之前，一定要先确认这台节点已经可以被 Remote Admin 正常控制，或者老固件节点已经能通过 legacy Admin channel 管理，而且当前远程读写配置都能正常工作。先确认链路和权限没有问题，再打开 Managed Mode，会稳妥很多。</p><h2 id="总结">总结</h2><p>新版 Meshtastic 远程管理的核心思路其实非常简单：对于 2.5 及以后版本，把控制端的 Public Key 写入被控端的 Admin Key；对于 2.4.x 及更早版本，才考虑 Legacy Admin channel。只要你先把这条版本分界线看清楚，后面的操作就不会乱。</p><p>如果你现在群里正好有几个山顶节点、楼顶太阳能节点，或者你自己已经开始搭长期在线的阳台节点，我的建议是尽早把 Remote Node Admin 配好，而且先拿测试节点演练一遍。这样下次再有人问这个参数能不能不去现场改，答案就不是得爬上去，而是可以，前提是你一开始就把远程管理权限配对了。</p>]]></content>
    
    
    <summary type="html">群里经常有人问，山顶太阳能节点、楼顶节点能不能不去现场就改设置？答案是可以，这就是 Meshtastic 的 Remote Node Admin。本文用中文把新版远程管理的原理、适用固件版本、Android、苹果、CLI 和 Web 的配置方法一次讲清楚。</summary>
    
    
    
    <category term="教程" scheme="https://meshcn.net/categories/%E6%95%99%E7%A8%8B/"/>
    
    
    <category term="CLI" scheme="https://meshcn.net/tags/CLI/"/>
    
    <category term="远程管理" scheme="https://meshcn.net/tags/%E8%BF%9C%E7%A8%8B%E7%AE%A1%E7%90%86/"/>
    
    <category term="安全" scheme="https://meshcn.net/tags/%E5%AE%89%E5%85%A8/"/>
    
    <category term="PKC" scheme="https://meshcn.net/tags/PKC/"/>
    
  </entry>
  
  <entry>
    <title>【硬核】基于 TinyLora V3 的高可靠大功率太阳能一体机整体方案</title>
    <link href="https://meshcn.net/tinylora-v3-high-reliability-high-power-solar-all-in-one-solution/"/>
    <id>https://meshcn.net/tinylora-v3-high-reliability-high-power-solar-all-in-one-solution/</id>
    <published>2026-03-28T04:00:00.000Z</published>
    <updated>2026-03-28T04:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<blockquote><p>这篇方案由 <a href="/contact">MeshCN 社区微信群</a> 成员 <em>太原-坎川工业</em> 与 <em>武汉-yaoyao</em> 共同整理，感谢他们把完整的实做过程分享出来。</p></blockquote><p>如果你在 MeshCN 微信群里，肯定听过 yaoyao 的大名。几乎每一个新进群的群友，都会被其他群友推荐使用 yaoyao 的 TinyLora 作为第一个入门设备。以往大家玩 TinyLora，通常都是怎么简单怎么来，先把设备跑起来、先连上网、先体验到 Meshtastic 的基本乐趣。</p><p>今天这篇文章想介绍的，就不是最省事的用法了，而是看看怎么把 TinyLora 玩出花样，把它进一步折腾成一个防水、专业、适合长期户外部署的太阳能节点。</p><p>如果你想做一台真正能长期挂在户外的 Meshtastic 节点，那么光把开发板塞进盒子里通常还不够。天线、供电、外壳强度、防水、安装方式，这几个环节只要有一处处理得不够稳，设备就很难在室外环境里长时间正常工作。</p><p>这篇文章整理的是一套基于 TinyLora V3 的高可靠大功率太阳能一体机方案。原始资料本身已经把关键步骤都记录下来了，但更像是一份现场施工记录。这里我在不减少信息量的前提下，把整套流程重新整理成更适合阅读和照着做的版本，方便后来者直接参考。</p><h2 id="1-物料清单">1. 物料清单</h2><p>先看整套方案里实际用到的物料。这里既包括核心电子部分，也包括外壳、紧固件和安装配件。做这类户外一体机时，很多人会把注意力都放在开发板和太阳能板上，但真正决定成品稳定性的，往往反而是这些看起来不起眼的小零件。</p><p><img src="./01-materials-overview.webp" alt="物料全家福"></p><table><thead><tr><th>名称</th><th>价格</th></tr></thead><tbody><tr><td>温湿度版 tinylora_v3 开发板</td><td>114</td></tr><tr><td>立创开源 tinylora_v3 白 piao 电路板</td><td>0</td></tr><tr><td>12W 多晶带线/支架/接线盒/转换器太阳能板</td><td>15</td></tr><tr><td>dyson 拆机魔力 18650 防冻电池（-40 度可用）</td><td>1.8</td></tr><tr><td>470-510Mhz 玻璃钢天线</td><td>25</td></tr><tr><td>SMA 内螺内针转 N 母转接头</td><td>2.5</td></tr><tr><td>SMA 内螺内针转外螺内孔 0.08m 转接线</td><td>3.12</td></tr><tr><td>42<em>29</em>95mm 铝合金外壳</td><td>5.6</td></tr><tr><td>250mm 防水箱抱箍横杆</td><td>2.5</td></tr><tr><td>20mm R 型电缆固定夹</td><td>0.47</td></tr><tr><td>5<em>8.5</em>7.4mm T 型护线圈</td><td>0.1</td></tr><tr><td>M3<em>20mm 固定铜柱</em>4</td><td>1</td></tr><tr><td>M2.3<em>6mm 螺丝</em>8</td><td>0.08</td></tr></tbody></table><h2 id="2-制作过程">2. 制作过程</h2><p>整套制作过程可以理解为四件事：先把开发板固定起来，再把铝合金外壳加工到合适尺寸，然后完成供电与天线连接，最后再把整机固定到太阳能板组件上。顺着这个思路往下看，步骤会更清楚。</p><blockquote class="blockquote-note blockquote-note__warning"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="12" height="16" viewBox="0 0 12 16"><path fill-rule="evenodd" d="M5.05.31c.81 2.17.41 3.38-.52 4.31C3.55 5.67 1.98 6.45.9 7.98c-1.45 2.05-1.7 6.53 3.53 7.7-2.2-1.16-2.67-4.52-.3-6.61-.61 2.03.53 3.33 1.94 2.86 1.39-.47 2.3.53 2.27 1.67-.02.78-.31 1.44-1.13 1.81 3.42-.59 4.78-3.42 4.78-5.56 0-2.84-2.53-3.22-1.25-5.61-1.52.13-2.03 1.13-1.89 2.75.09 1.08-1.02 1.8-1.86 1.33-.67-.41-.66-1.19-.06-1.78C8.18 5.31 8.68 2.45 5.05.32L5.03.3l.02.01z"></path></svg></div>注意个人防护</div><div class="blockquote-note__content"><p>操作电动工具时会有碎屑飞溅并伴有粉尘污染，务必佩戴护目镜、手套和口罩操作！</p></div></blockquote><h3 id="外壳与主板定位">外壳与主板定位</h3><p>先从开发板本体开始。第一步是把 4 条固定铜柱拧紧到开发板上，注意要预先在螺柱涂螺丝胶，防止后续出现共轴旋转的问题。这个小动作看起来不起眼，但后面反复拆装、试位、拧紧时会省掉很多麻烦。</p><p><img src="./02-mainboard-with-standoffs-and-threadlocker.webp" alt="安装固定铜柱"></p><p>接下来处理铝合金外壳挡板固定用的翻边。原做法是沿折弯的边线切割，转速不宜太高，也不要试图一次切透，而是从右至左轻轻多次切割，深度超过一般厚度之后停止，再用虎钳一点点沿边线掰掉。这样做的目的，是尽量减少变形并让切口更可控。</p><p><img src="./03-cutting-front-and-rear-panel-flanges.webp" alt="切除挡板翻边"></p><p>翻边处理完以后，将开发板 SMA 接口边缘用记号笔涂黑。这个记号不是装饰，而是为了后续试装时在挡板内壁留下准确的开孔参考。</p><p><img src="./04-marking-sma-position-on-board.webp" alt="SMA 接口边缘做标记"></p><p>随后把开发板对齐中间位置，缓慢推入只装前挡板的假组外壳中，直到推不动为止。拉出开发板后，前挡板内壁就会出现一圈清晰的开孔标记，后面的钻孔位置就靠它来确定。</p><p><img src="./05-test-fit-board-into-enclosure.webp" alt="将开发板推入外壳试位"></p><p><img src="./06-sma-hole-mark-left-on-front-panel.webp" alt="前挡板留下的开孔标记"></p><p>确认好位置之后，用电钻安装 6mm 钻头对准标记处开孔。实际操作时建议先低速打出凹坑定位，再高速打出通孔，这样不容易跑偏。</p><p><img src="./07-drilling-front-panel-sma-hole.webp" alt="为 SMA 接口开孔"></p><p>孔位打好后，再对加工完的前后挡板使用砂轮机打磨抛光，包括开的通孔边缘，以及之前切除翻边后留下的边缘。到这里，前后挡板的加工就基本告一段落了。</p><p><img src="./08-grinding-and-polishing-panels.webp" alt="挡板边缘打磨抛光"></p><p><img src="./09-finished-front-and-rear-panels.webp" alt="前后挡板加工完成效果"></p><p>接下来处理上盖。先用开发板比对外壳上盖，预留出 SMA 接口边缘厚度并做标记；然后拿白 piao 的电路板上边缘对齐这个厚度标记，再把它移到外壳上盖板中间位置，在电路板四个螺丝孔内做标记。这样做的好处是，即使不直接拿主板去反复比划，也能比较准确地把安装孔定位出来。</p><p><img src="./10-marking-sma-clearance-on-top-cover.webp" alt="在上盖上预留 SMA 接口位置"></p><p><img src="./11-marking-top-cover-mounting-holes-with-pcb.webp" alt="用空电路板标出四个螺丝孔"></p><p>有了定位点之后，用电钻安装 3.5mm 钻头，对电路板螺丝孔标记处开孔。完成后再检查一次孔位与边缘距离，确认没有偏差过大。</p><p><img src="./12-drilling-top-cover-mounting-holes.webp" alt="为固定螺丝开孔"></p><p><img src="./13-finished-top-cover-holes.webp" alt="上盖开孔完成效果"></p><h3 id="走线、焊接与壳体装配">走线、焊接与壳体装配</h3><p>外壳孔位全部处理好以后，就可以开始处理供电走线。先把 T 型护线圈穿过后挡板开孔，这个零件的作用是避免线材直接与金属边缘摩擦。</p><p><img src="./14-installing-t-grommet-on-rear-panel.webp" alt="安装 T 型护线圈"></p><p>然后把太阳能板原装电源线从接线盒起算，量出 25cm 后剪断并剥线，再把电源线穿过 T 型护线圈，并在内部打一节，防止外部受力时把线直接拉脱。</p><p><img src="./15-cutting-solar-panel-power-cable-to-length.webp" alt="裁剪太阳能板电源线"></p><p><img src="./16-routing-cable-through-grommet-and-tying-knot.webp" alt="电源线穿线并打节防拉脱"></p><p>线材固定好后，用电烙铁在开发板 MPPT 焊盘处焊接电源线正极，在 GND 焊盘处焊接电源线负极。这里极性不要搞错，焊完以后也建议先做一次目视检查，再继续下一步。</p><p><img src="./17-soldering-power-cable-to-mppt-and-gnd.webp" alt="在开发板上焊接电源线"></p><p>焊接完成后先拧紧后挡板，再把开发板的 SMA 接口穿过前挡板过孔，装上固定弹簧垫片与螺母并拧紧前挡板。到这里，主板就已经被比较稳固地固定在壳体内部了。</p><p><img src="./18-tightening-rear-panel-after-soldering.webp" alt="拧紧后挡板"></p><p><img src="./19-fixing-front-panel-and-sma-connector.webp" alt="固定前挡板与 SMA 接口"></p><p>随后把 SMA 内螺内针转外螺内孔转接线拧紧到开发板 SMA 接口上。这里原作者特别提醒了一句：天线一定要先接再装电池，防止烧毁开发板 LoRa 模组，这一点务必要照做。</p><p><img src="./20-connecting-sma-pigtail-to-enclosure.webp" alt="连接 SMA 转接线"></p><p>接下来安装 18650 电池到电池座，极性一定不要装反，装反必烧。确认电池方向无误后，再用环氧密封胶沿着外壳上盖双侧接缝打胶，注意不要打太多，只需要确保接缝位置有连续的密封层即可。</p><p><img src="./21-installing-18650-cell-into-battery-holder.webp" alt="安装 18650 电池"></p><p><img src="./22-applying-epoxy-sealant-along-top-cover-seam.webp" alt="沿上盖接缝打环氧密封胶"></p><p>打胶完成后，把外壳上盖盖上，并拧紧用于固定电路板的螺丝。到这里，一体机主机部分基本就成型了。</p><p><img src="./23-closing-top-cover-and-fastening-screws.webp" alt="盖上上盖并锁紧螺丝"></p><h3 id="固定到太阳能板组件">固定到太阳能板组件</h3><p>主机装好以后，剩下的工作就是把它和太阳能板、天线、安装横杆组合起来。先用切割机沿着外壳底部第一道槽，在后挡板双侧开槽，给横杆卡位预留结构。</p><p><img src="./24-cutting-side-slots-for-crossbar-mount.webp" alt="在外壳底部开槽"></p><p>随后将主机本体对准横杆凹槽滑入并卡紧。这里的配合精度比较重要，所以前面外壳加工阶段做得越准，后面这一步越轻松。</p><p><img src="./25-sliding-main-unit-into-crossbar-slot.webp" alt="主机滑入横杆凹槽"></p><p>主机卡入横杆后，用电钻安装台阶钻头，比对横杆与太阳能板铝合金边框边缘交叉处，在双侧开孔，穿过螺丝将横杆结实固定在太阳能板铝合金边框底部。同时，也别忘了在太阳能板铝合金边框底边开排水孔，给长期户外使用留出排水通道。</p><p><img src="./26-drilling-crossbar-to-solar-frame-mounting-holes.webp" alt="横杆固定到太阳能板边框"></p><p>接着把太阳能板支架的手拧螺丝拆掉，让天线穿过固定夹，固定夹再穿过螺杆并重新拧紧手拧螺丝。这样天线就能与整套支架结构结合在一起。</p><p><img src="./27-clamping-antenna-to-solar-panel-bracket.webp" alt="利用固定夹安装天线"></p><p>最后，把 SMA 内螺内针转 N 母转接头安装到天线末端，再用 SMA 内螺内针转外螺内孔转接线连接天线末端。确认所有接口都已经拧紧后，就可以撕掉保护膜，整机正式投运。</p><p><img src="./28-installing-n-female-adapter-on-antenna-end.webp" alt="安装 SMA 转 N 母转接头"></p><p><img src="./29-connecting-sma-pigtail-to-antenna-adapter.webp" alt="连接天线末端转接线"></p><p><img src="./30-peeling-protective-film-before-deployment.webp" alt="整机完成并投运"></p><h2 id="3-整体外观">3. 整体外观</h2><p>前面的步骤看下来会比较碎，到了这一步就能直接看到整机形态。正面和背面的完成效果如下，从结构上可以看出，这套方案的重点就是把主机、供电和安装结构尽量做成一个整体，减少户外长期使用时的松动风险。</p><p>3.1 正面视图</p><p><img src="./31-finished-unit-front-view.webp" alt="整机正面视图"></p><p>3.2 背面视图</p><p><img src="./32-finished-unit-rear-view.webp" alt="整机背面视图"></p><p>3.3 防水测试</p><p>从作者给出的实拍资料来看，这套外壳方案也专门做了防水验证。图片之外，目录里还保留了原始防水测试视频，可以直接内嵌查看。</p><p><video  src="/tinylora-v3-high-reliability-high-power-solar-all-in-one-solution/water-proof-demo-video-by-spraying-water-using-shower-onto-the-solar-suite.mp4"  controls  preload="metadata"  playsinline  style="width:100%;max-width:900px;border-radius:16px;outline:none;"><br>您的浏览器不支持视频播放。<br><a href="/tinylora-v3-high-reliability-high-power-solar-all-in-one-solution/water-proof-demo-video-by-spraying-water-using-shower-onto-the-solar-suite.mp4">点击下载视频</a><br></video></p><h2 id="4-安装方式">4. 安装方式</h2><p>设备做好只是第一步，真正上墙、上杆、长期挂在户外，安全问题比装机本身更重要。尤其是楼顶、外墙这类位置，一旦安装方式不当，风险远比通信效果差要严重得多。</p><blockquote class="blockquote-note blockquote-note__warning"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="12" height="16" viewBox="0 0 12 16"><path fill-rule="evenodd" d="M5.05.31c.81 2.17.41 3.38-.52 4.31C3.55 5.67 1.98 6.45.9 7.98c-1.45 2.05-1.7 6.53 3.53 7.7-2.2-1.16-2.67-4.52-.3-6.61-.61 2.03.53 3.33 1.94 2.86 1.39-.47 2.3.53 2.27 1.67-.02.78-.31 1.44-1.13 1.81 3.42-.59 4.78-3.42 4.78-5.56 0-2.84-2.53-3.22-1.25-5.61-1.52.13-2.03 1.13-1.89 2.75.09 1.08-1.02 1.8-1.86 1.33-.67-.41-.66-1.19-.06-1.78C8.18 5.31 8.68 2.45 5.05.32L5.03.3l.02.01z"></path></svg></div>FBI WARRING</div><div class="blockquote-note__content"><p>严禁以任何方式安装到楼顶避雷线等危险的位置！</p><p>严禁以任何方式安装到不牢靠易损的基体之上！</p><p>登高 1.5m 以上作业必须使用安全带！</p><p>炮钉枪有一定危险性，务必看清说明书，佩戴护目镜、手套按照规范正确操作！</p></div></blockquote><p>如果是墙壁安装，原方案的做法是直接使用图中的炮钉枪，打两颗钉贯穿太阳能板支架，将其固定到混凝土基体上即可。这种方式简单直接，但前提是基层足够牢固，而且施工者对工具有基本经验。</p><p><img src="./33-wall-mount-nail-gun-example.webp" alt="墙壁安装方式"></p><p>如果不适合打钉，也可以选择抱箍安装。项目使用的防水箱抱箍横杆本身就支持抱箍方式，购买如图的抱箍后穿过横杆专用过孔拉紧即可；如果有条件，太阳能板支架再增加一道固定会更稳妥。</p><p><img src="./34-hose-clamp-mount-example.webp" alt="抱箍安装方式"></p><h2 id="5-脑洞展望">5. 脑洞展望</h2><p>作者最后还留了一个很有意思的想法：横杆有一侧其实还能继续安装设备，闲置着多少有点可惜，而且目前整体重心也并不是完全对称。既然已经做到了这一步，不妨继续脑洞大开，看看能不能顺手再加一点别的功能，比如装个风扇辅助控制温度，或者围绕这根横杆继续扩展别的传感、供电或固定结构。</p><p>本文作者：太原-坎川工业 × 武汉-熔恒科技</p>]]></content>
    
    
    <summary type="html">这是一套面向长期户外部署的 TinyLora V3 太阳能一体机方案，从物料选择、外壳加工、焊接装配到安装方式，完整整理了作者的实战做法。</summary>
    
    
    
    <category term="教程" scheme="https://meshcn.net/categories/%E6%95%99%E7%A8%8B/"/>
    
    
    <category term="太阳能" scheme="https://meshcn.net/tags/%E5%A4%AA%E9%98%B3%E8%83%BD/"/>
    
    <category term="DIY" scheme="https://meshcn.net/tags/DIY/"/>
    
    <category term="TinyLora" scheme="https://meshcn.net/tags/TinyLora/"/>
    
    <category term="户外节点" scheme="https://meshcn.net/tags/%E6%88%B7%E5%A4%96%E8%8A%82%E7%82%B9/"/>
    
  </entry>
  
  <entry>
    <title>MeshCore 入门第二课：为什么我们正从 Meshtastic 切换到 MeshCore</title>
    <link href="https://meshcn.net/meshcore-why-switch-from-meshtastic-from-comms-channel/"/>
    <id>https://meshcn.net/meshcore-why-switch-from-meshtastic-from-comms-channel/</id>
    <published>2026-03-27T13:30:00.000Z</published>
    <updated>2026-03-27T13:30:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>如果你还没看系列第一篇，可以先读《<a href="/meshcore-newcomer-intro-from-comms-channel/">MeshCore 入门第一课：新手第一次接触 MeshCore 时，最需要先知道什么？</a>》。看完再回来读这一篇，前后会更连贯。</p><p>如果你已经看完上一篇，大概率会自然想到一个问题：MeshCore 听起来确实有点意思，但它真的好到值得大家花时间和精力，把已经在用的 Meshtastic 网络切过去吗？</p><p>这正是 <em>The Comms Channel</em> 这条视频想回答的问题。</p><blockquote class="blockquote-note blockquote-note__info"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="16" viewBox="0 0 14 16"><path fill-rule="evenodd" d="M6.3 5.69a.942.942 0 0 1-.28-.7c0-.28.09-.52.28-.7.19-.18.42-.28.7-.28.28 0 .52.09.7.28.18.19.28.42.28.7 0 .28-.09.52-.28.7a1 1 0 0 1-.7.3c-.28 0-.52-.11-.7-.3zM8 7.99c-.02-.25-.11-.48-.31-.69-.2-.19-.42-.3-.69-.31H6c-.27.02-.48.13-.69.31-.2.2-.3.44-.31.69h1v3c.02.27.11.5.31.69.2.2.42.31.69.31h1c.27 0 .48-.11.69-.31.2-.19.3-.42.31-.69H8V7.98v.01zM7 2.3c-3.14 0-5.7 2.54-5.7 5.68 0 3.14 2.56 5.7 5.7 5.7s5.7-2.55 5.7-5.7c0-3.15-2.56-5.69-5.7-5.69v.01zM7 .98c3.86 0 7 3.14 7 7s-3.14 7-7 7-7-3.12-7-7 3.14-7 7-7z"></path></svg></div>翻译声明</div><div class="blockquote-note__content"><p>本文基于 <em>The Comms Channel</em> 于 2025 年 12 月 6 日发布的视频《<a href="https://www.youtube.com/watch?v=guDoKGs02Us">Why we’re switching from Meshtastic to MeshCore</a>》内容直接翻译整理。这是本系列第 2 篇。</p></div></blockquote><p>原 YouTube 视频受国内网络环境影响，对国内读者不方便观看。因此，我已搬运到 <a href="https://www.bilibili.com/video/BV1s2XsBkEjf/">Bilibili</a>。已翻译中文字幕且添加到视频里，看的时候记得打开字幕和 4K 画质哦~</p><div style="position: relative; width: 100%; padding-top: 56.25%;">  <iframe style="position: absolute; inset: 0; width: 100%; height: 100%;" src="https://player.bilibili.com/player.html?bvid=BV1s2XsBkEjf&page=1&as_wide=1&high_quality=1&danmaku=0" frameborder="no" scrolling="no" allowfullscreen="true"></iframe></div><p>视频一开头，作者就提到一个很真实的现象：每次他做 Meshtastic 视频，评论区里总会有人留言，让他去看看 MeshCore，并且强调 MeshCore 更好。</p><p>但问题在于，MeshCore 真的比 Meshtastic 更好吗？真的已经有人愿意投入这么多时间和精力，把自己的 Mesh 网络切换到 MeshCore 吗？</p><p>为了弄清楚这件事，作者决定认真看看大家到底在吵什么。好消息是，MeshCore 可以运行在很多和 Meshtastic 相同的硬件上，所以把它刷到自己手头越来越多的 LoRa 设备上，并不算困难。</p><p>但有一个大问题：作者所在的地区目前只有他一个 MeshCore 用户，周围其他人都还在用 Meshtastic。</p><p>他说，自己当然也可以做一条比较基础的对比视频，比如单纯展示两个平台的 App、固件、配置方式之类的差异，但他想做得更多一点。一方面，这是为了给观众一个尽可能好的对比；另一方面，他自己也确实很好奇。</p><p>于是他决定去找真实世界的数据，方法就是联系那些同时使用过 Meshtastic 和 MeshCore 的社区，直接听他们说体验。</p><p>作者也知道，MeshCore 和 Meshtastic 这个话题很容易变成站队，有人会变成站 Meshtastic，也有人会变成站 MeshCore。所以他特地联系了美国多个不同地区的 Mesh 社区，希望尽量拿到更广泛的样本。</p><p>网上有一个叫 MeshCore Analyzer 的工具。通过这个工具可以看到，美国当时主要有三个区域在使用 MeshCore，分别是 Boston（美国马萨诸塞州波士顿）、Southern California（美国加州南部）和 Pacific Northwest（美国太平洋西北地区）。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/meshcore-analyzer-us-regions.webp" alt="MeshCore Analyzer 上显示的美国活跃区域分布"></p><p>因为 Meshtastic 出现得更早，而 MeshCore 更新，所以这些已经活跃起来的 MeshCore 网络，很可能两边都用过。每个区域也都有自己的 Discord 服务器。于是作者给他们都发了同样一条消息，说明自己在 Tennessee（美国田纳西州），当地现在只有 Meshtastic，然后请他们分享一下自己使用这两个平台的体验。</p><h2 id="美国波士顿社区">美国波士顿社区</h2><p>第一站是波士顿一带的 Mesh 社区。</p><p>第一位回复的用户希望匿名。他提到，自己对 MeshCore 的路由方式有很好的使用结果，而且即使跳数很多，群组消息依然相当可用。</p><p>另一位同样希望匿名的成员，给出了更长一点的反馈。他说，当然，他们一开始和其他人一样，先从 Meshtastic 开始。刚开始看着地图上不断冒出节点，确实很有意思，但大家很快意识到，实际上一旦超过两跳，就很难真正给别人发消息了。</p><p>很多人会接受这个现实，觉得这就是硬件的限制，是大家必须接受的事情。作者也说，这一点和他自己对 Meshtastic 的体验很接近：发消息一直都是时灵时不灵，所以他过去也只是把它当成硬件和 900MHz ISM 频段本身的限制。</p><p>但这位用户继续说，自己其实并不满意这种情况。于是他开始深入研究，后来发现了 MeshCore。他开始告诉别人去试着切换，慢慢就带动了当地 MeshCore 社区的增长。</p><p>他提到，切换之后，他们很快看到了一个非常明显的变化：消息投递能力有了惊人的提升。他自己现在距离 Boston 大约 30 到 40 英里，依然可以可靠地和整个网络里的人通信。他发出的消息经常会跑 5 到 6 跳，也没有问题。用他的话说，这种差别简直是白天和黑夜。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/boston-community-feedback.webp" alt="波士顿社区成员关于 MeshCore 多跳消息投递能力的反馈截图"></p><p>他说，变化大到他们甚至已经开始为了好玩做跨州连接。他们很快要和 New York（美国纽约州）合并，未来还计划扩展到 Connecticut（美国康涅狄格州）和 Rhode Island（美国罗得岛州）。在他看来，这是 MeshCore 才让这件事变得可能。</p><p>第一位匿名用户后面也补了一句很重要的话。他说，必须承认，和 Meshtastic 相比，MeshCore 的固件和软件现在仍然在成长中，还没那么成熟；但底层的路由工作方式带来的差异，确实是白天和黑夜。</p><p>他说，在 MeshCore 里建设一个中继站，会让人非常明确地感觉到，整个 Mesh 网络真的被扩展了。就像前面那位用户说的那样，当你把覆盖进一步往外推时，凡是能够连上这个中继的人，也就等于连上了整个 Mesh。只要部署起来，它基本就是会工作。</p><h2 id="美国南加州社区">美国南加州社区</h2><p>美国第二个比较大的 MeshCore 社区，是 West Coast Mesh（美国西海岸 Mesh），也就是覆盖 Los Angeles（美国加州洛杉矶）和 San Diego（美国加州圣迭戈）一带的 Southern California（南加州）社区。这里的 Mesh 社区正在快速增长。</p><p>第一位回复的用户也选择匿名。他的看法是，这两个平台确实适合不同的用途，而且当地至少有一半成员，是从 Meshtastic 转过来的。</p><p>很快，另一位同样匿名的 West Coast Mesh 成员也给出了自己的体验。他说，自己算是用了很久 Meshtastic 的老用户，而且现在依然是 Meshtastic 的爱好者。</p><p>但他在 Southern California 的使用中，看到自己的跳数不断被消耗，消息始终出不了自己所在的那个小区域。他还提到，当地 900MHz ISM 频段非常活跃，在默认的 LongFast、甚至 MediumSlow 这些参数下，较大的数据包和较长、较低速的 chirp 会彼此碰撞。</p><p>而 MeshCore 协议因为包更小、整体 chatter 更少、默认参数也更快更低速率，所以看起来更能处理这些问题，最后给人的感觉就是：消息通信终于像是真的能用了。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/socal-protocol-feedback.webp" alt="南加州社区成员关于包更小、空口更安静的反馈截图"></p><p>不过他也强调，这并不是说 MeshCore 就一定更好。它离完美还很远，而且随着他们当地网络继续扩大，将来一定也会碰到它自己的上限。所以不能简单地下结论说 MeshCore 一定全面优于 Meshtastic。</p><p>但他认为，至少在当前阶段，特别是对于城市环境下、以聊天为核心的使用场景，MeshCore 提供了一个很有价值的方向，让人看到什么样的协议可能会更有性能优势。</p><p>第一位匿名用户也补充说，大体上可以这样理解：MeshCore 没那么 ad hoc，它更依赖已经建立好的地点和中继站；但在面对一个用户数量很多、分布范围很大的网络时，它会稳健得多。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/socal-established-network-feedback.webp" alt="南加州社区成员关于 MeshCore 更依赖固定中继网络的反馈截图"></p><p>视频前面提到，作者经常在 Meshtastic 视频下看到有人留言推荐 MeshCore。而这些留言里，有一位正好就是 West Coast Mesh 社区的成员。</p><p>这位用户说，自己以前也是 Meshtastic 用户，但由于网络拥堵，消息根本发不出去。他原本希望用 Meshtastic 和自己的女儿做离网通信，但结果并不理想。于是他转向了 MeshCore。在 Crest Liner 中继装起来之后，他现在发消息和收消息都没有问题。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/crestliner-repeater-feedback.webp" alt="West Coast Mesh 成员提到 Crest Liner 中继部署后的体验截图"></p><p>他说，当地网络真的发展得很快。他还记得以前那里可能只有三台中继，而现在再看看，已经完全不是那个规模了。</p><p>第一位匿名用户随后又补了一点。他说，Meshtastic 一旦堵起来，虽然在局部小范围内依然不错，但一旦用户数超过 30，就会变得太难管理、太笨重。反过来，MeshCore 的稳定性反而让他们可以把更多精力放在硬件、固件、各种设备组合、部署方式等开发工作上。用他的话说，这是社区在很短时间里完成的一次非常值得称赞的集体努力。</p><h2 id="Pacific-Northwest-社区怎么说">Pacific Northwest 社区怎么说</h2><p>接下来，作者联系了美国最大的 MeshCore 网络，也就是 Seattle（美国华盛顿州西雅图）一带的社区。这个网络的范围从 Vancouver, British Columbia（加拿大不列颠哥伦比亚省温哥华），一直延伸到 Eugene, Oregon（美国俄勒冈州尤金）。</p><p>因为规模太大，它实际上有两个 Discord 服务器：Puget Mesh（美国西雅图和普吉特湾一带的社区）和 Cascadia Mesh（美国太平洋西北地区的跨州社区）。</p><p>第一条回复来自 Cascadia Mesh 里的 Awall。他说，这种差别几乎很难形容。自己过去用 Meshtastic 时，他和朋友们明明把节点都架起来了，彼此之间也只隔着几英里，却完全无法通信。糟糕的私信路径和不理想的 flood 算法，让他们那个高密度网络几乎无法使用。</p><p>所以在去年晚些时候，他们认真转向了 MeshCore。那时候当地还一台 MeshCore 中继都没有。他们先在 West Portland（美国俄勒冈州波特兰西部）做出了一张网络，之后就再也没有回头。用他的话说，现在消息通信几乎接近完美。如今他们已经做出了一张从 Eugene 延伸到 Vancouver 的 Mesh。</p><p>很快，另一位 Cascadia Mesh 成员 Brian 也补充了自己的体验。他说，MeshCore 的路由是可配置的，因此在某种程度上是可预测、可追踪的。对他来说，这意味着他能够知道，或者自己配置，数据包会沿着什么路径到达收件人，而不是完全交给系统猜。</p><p>他还特别提到，MeshCore 不受 7 跳限制。Meshtastic 的 7 跳上限可能意味着，消息可以勉强到达城另一头的对方，但回信却回不来。</p><p>不过 Brian 也没有简单说哪一个绝对更好。他说，如果自己是和朋友们去一个没有信号的地方露营，那么他反而会更倾向于 Meshtastic，因为那种情况下，私信不需要依赖专门部署的基础设施中继，而可以直接在 Companion 节点之间处理。</p><p>他说，两边都有各自的强项，但他最终会选择那个真正能工作的系统；而且当它不工作的时候，自己还拥有路由管理工具来修正问题，也有诊断工具来理解问题。</p><p>作者随后又收到了 Puget Mesh Discord 里一位名叫 Sizian 的成员反馈。他说，在他们那里，Meshtastic 基本上只是勉强能用，即使列表上能看到几百个节点也没什么意义。真正从他们部署出一个高质量中继的那一天开始，MeshCore 才变得非常可用、可靠，而且增长速度也很快。</p><p>他直说，他们过去几乎从来没办法在 Meshtastic 上真正维持一段对话；而到了 MeshCore 上，公共频道里则一直有持续不断的聊天。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/pnw-public-channel-feedback.webp" alt="Pacific Northwest 社区成员关于 MeshCore 公共频道持续有聊天的反馈截图"></p><p>在他看来，Meshtastic 最大的问题，是它的 managed flood 方式几乎注定会让某些数据包在某个地方掉进黑洞。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/managed-flood-black-hole-proof.webp" alt="Pacific Northwest 社区成员直说 managed flood 容易把数据包丢进黑洞的反馈截图"></p><h2 id="视频里是怎么解释两者差异的">视频里是怎么解释两者差异的</h2><p>作者接着说，两者在路由方式上的差异，是必须单独拿出来讲的重点。</p><p>按视频里的说法，Meshtastic 使用的是 managed flood routing（受控洪泛路由，也就是尽量控制谁来转发、何时转发，而不是让所有节点无脑一起转发），也就是节点会等待看看别的节点是否已经在转发消息，然后再根据信号强度优先考虑距离更远的节点，同时也会优先让 router 和 repeater 这类角色承担更多责任。</p><p>这套机制在纸面上听起来很好，在一个完美世界里，可能也确实更优雅。但现实里会有太多变量影响这种路由方式。正如前面 Sizian 提到的那样，它很容易制造出黑洞，消息包就这样消失了。整个系统在大范围地理空间里扩展时，表现并不好。</p><p>MeshCore 则采取了另一种更简单的办法：pure flood routing。MeshCore 的中继不会尝试做那么多管理。只要它听到了消息，它就重新广播。</p><p>作者也承认，这当然会更吵。但代价换来的结果是：消息能过去。</p><p>他说，自己联系到的这些 Mesh 社区，几乎都说了同样的话：对于跨越大范围区域的消息通信，MeshCore 就是能工作。</p><h2 id="作者自己远程体验后的感受">作者自己远程体验后的感受</h2><p>视频后面还提到，西雅图大型 Mesh 网络里有一位叫 Uncle Lit 的成员，给作者提供了一台装有 MeshCore Windows 客户端的远程 Windows 虚拟机，让他可以亲眼看看他们的网络是怎么运作的。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/seattle-remote-client-channels.webp" alt="作者远程连接到 Seattle 西雅图网络时看到的 MeshCore 频道列表界面"></p><p>作者说，他亲眼看到了真实成功的聊天正在发生，而这件事在他自己 Tennessee 的 Meshtastic 使用经历里，一直都是时灵时不灵。</p><p>他探索了节点地图，跑了当地中继的多跳路径追踪，甚至还亲自把自己的消息打进了这张网络。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/seattle-node-map.webp" alt="作者远程查看 Seattle 西雅图网络时的节点地图界面"></p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/seattle-trace-path.webp" alt="作者远程查看 Seattle 西雅图网络时的多跳路径追踪界面"></p><p>而 Cascadia Mesh 在 Discord 里还有一套监控系统。成员 N0EJ 跟踪到了作者的消息，并确认这条消息打到了 Oregon 的 McMinnville（美国俄勒冈州麦克明维尔）监控点。视频里说，这个点距离西雅图大约 170 英里，而作者的消息正是从西雅图发出的。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/mcminnville-monitor-proof.webp" alt="Discord 监控里确认消息成功抵达 McMinnville 监测点的截图"></p><h2 id="最后的结论并不是谁彻底赢了">最后的结论并不是谁彻底赢了</h2><p>综合这些社区的反馈后，作者认为，大家的总体共识已经比较清楚了：如果是在一个跨越城市、甚至跨越大片地理区域的大型网络里来回发消息，MeshCore 的表现要好得多。</p><p>但另一方面，Meshtastic 对于小型、移动中的群体依然更合适，因为每个节点本身都会参与转发。</p><p>作者还提到，这个结论也能从 Texas（美国得州）的 Austin Mesh 社区那篇详细对比文章里得到印证。视频里说，Austin Mesh 当时虽然还处在 MeshCore 部署的早期阶段，但增长很快。因为他们写了一篇质量很高的对比文章，所以作者也去问了他们的感受。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/austin-mesh-comparison-page.webp" alt="Austin Mesh 关于 Meshtastic 和 MeshCore 的对比页面截图"></p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/austin-comparison-eli5.webp" alt="Austin Mesh 对 Meshtastic 和 MeshCore 的 TL;DR 总结截图"></p><p>一位叫 Nick 的成员回复说，自己对 MeshCore 的体验非常正面。他原本是一个早期怀疑者，后来却成了支持者。他说，以自己长期玩的经验来看，MeshCore 在长链路上的稳定性，至少和 Meshtastic LongFast 一样，甚至更好，但符号速率却快得多。它把优先级放在消息通信上，而不是遥测上。App 在不同设备之间也更一致，客户端和固件协议里还内建了不少功能，让测试和排障比 Meshtastic 容易得多。</p><p>另一位叫 Captain 的成员则说，Meshtastic 会更吸引那些希望一上手就立刻看到一些东西的新用户；而 MeshCore 更适合那些真正只是想通过 Mesh 和朋友稳定聊天，但过去在 Meshtastic 上一直觉得断断续续的人。</p><p>他也补了一句很关键的话：Meshtastic 大概还是最适合小型 ad hoc 网络；而 MeshCore 更适合已经建立起来的网络。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/captain-small-adhoc-vs-established.webp" alt="Austin Mesh 成员关于小型 ad hoc 网络与已建网络适配性的反馈截图"></p><p>Captain 还转发了 Omaha（美国内布拉斯加州奥马哈）的 Astro Bob 之前发给他们的一条消息。Astro Bob 也提到，自己那边对 MeshCore 的测试结果是积极的。后来当作者联系他，询问能否分享截图时，他又补充说，他们在 Omaha 的测试非常成功。</p><p><img src="/meshcore-why-switch-from-meshtastic-from-comms-channel/omaha-positive-feedback.webp" alt="Omaha 社区成员补充说当地 MeshCore 测试非常成功的截图"></p><p>于是作者总结说，他们已经听到了来自波士顿、南加州、Pacific Northwest、Austin，以及 Omaha 的反馈，而大家给出的共识其实已经很清晰：对于大规模部署，MeshCore 的表现更好。</p><p>当然，作者也说，自己不可能在这条视频里联系到每一个社区。如果你同时使用过两个平台，他也欢迎大家继续在评论区分享自己的体验。</p><h2 id="作者最后怎么选">作者最后怎么选</h2><p>视频最后，作者感谢了那些回复他的各地社区成员，并说自己会把他们的 Discord 服务器、网站以及其他想让观众知道的信息，整理进视频简介里。这些社区对任何想了解 MeshCore 的人来说，都是很有价值的资源。</p><p>然后他回到了一个观众最关心的问题：那他自己会不会彻底放弃 Meshtastic，全面切换到 MeshCore？</p><p>他的答案是：不会完全放弃。</p><p>他说，像前面讲过的那样，在移动场景里，他肯定还会继续使用 Meshtastic；但如果是他最初希望 Meshtastic 实现的那种 home-to-home 离网通信场景，他会毫不犹豫地切到 MeshCore。</p><p>接着，作者也借这个视频向当地观众发出邀请。他说，自己所在的 Tennessee 那一带当时还完全没有 MeshCore 覆盖，所以现在正好是最早一批参与者塑造当地 MeshCore 网络的机会。</p><p>他们需要中继站点、志愿者和早期采用者，特别是在 Chattanooga（美国田纳西州查塔努加）到 Knoxville（美国田纳西州诺克斯维尔）这一带。只要有人参与，他们就能像前面提到的那些社区一样，建设出一个更大、更强、更可靠的 MeshCore 网络。</p><p>为了协调这件事，他们已经在 Discord 上建立了 10 mesh 频道，也在 Telegram 上建了 10 mesh 群组。视频里说，这些链接都会放在简介里；如果观众是在电视上看视频，还可以直接扫描屏幕上的二维码。即便你不用 Discord 或 Telegram，也可以通过电子邮件联系他们。</p><p>最后，作者按 YouTube 视频的惯例做了收尾：如果这条视频有帮助，欢迎点赞、订阅，也别忘了看看视频简介里那些社区资源链接。</p><h2 id="结语">结语</h2><p>如果只看这一条视频给出的信息，那么它想表达的核心其实很直接：MeshCore 不一定在所有场景里都全面胜出，但在大范围、多人参与、依赖固定中继骨架的消息网络里，它确实让很多已经用过 Meshtastic 的社区，感受到了非常明显的差别。</p><p>而 Meshtastic 也没有因此失去价值。对于临时、小规模、移动式的 ad hoc 通信，它依然很有吸引力。</p><p>这篇是系列第 2 篇。下一篇我们继续按原视频顺序，整理后面的 MeshCore 内容。</p><h2 id="参考">参考</h2><ul><li>The Comms Channel: <a href="https://www.youtube.com/watch?v=guDoKGs02Us">Why we’re switching from Meshtastic to MeshCore</a></li></ul>]]></content>
    
    
    <summary type="html">从波士顿、南加州到太平洋西北，越来越多用过 Meshtastic 的社区开始认真转向 MeshCore。这篇文章按原视频顺序，梳理他们为什么切换，以及两者各自更适合什么场景。</summary>
    
    
    
    <category term="教程" scheme="https://meshcn.net/categories/%E6%95%99%E7%A8%8B/"/>
    
    
    <category term="Meshtastic" scheme="https://meshcn.net/tags/Meshtastic/"/>
    
    <category term="MeshCore" scheme="https://meshcn.net/tags/MeshCore/"/>
    
    <category term="The Comms Channel" scheme="https://meshcn.net/tags/The-Comms-Channel/"/>
    
  </entry>
  
  <entry>
    <title>ADV 470 模组的第一批实测来了</title>
    <link href="https://meshcn.net/adv-cap-lora-480mhz-cn470-first-field-reports/"/>
    <id>https://meshcn.net/adv-cap-lora-480mhz-cn470-first-field-reports/</id>
    <published>2026-03-26T07:05:00.000Z</published>
    <updated>2026-03-26T07:05:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>上一篇介绍《<a href="/adv-cap-lora-480mhz-cn470/">M5Stack ADV 的最后一块拼图：来自社区的 480MHz LoRa 模组</a>》发出去之后，群里这两天经常出现 ADV 的照片，新的模块大家都已经到手。</p><p><img src="/adv-cap-lora-480mhz-cn470-first-field-reports/adv-cardputer-message-screen-closeup.webp" alt="ADV 消息界面近景"></p><p>这块 470/480 MHz 模组给已经买了 M5Stack Cardputer ADV 的用户一条真正顺畅的路。以前大家喜欢 ADV，很多时候是先喜欢上它的外形和交互，再回过头来卡在频段这件事上。只要你人在国内，想和群友稳定通信，原装频率不匹配就始终是个绕不开的问题。</p><p>现在事情终于简单了很多，换上 470/480 模组，接入 <code>CN470</code>，就能更自然地加入大家已经在用的 Meshtastic 和 Meshcore 网络里。</p><p>但如果只把这件事理解为老用户终于有升级配件了，那其实还低估了它的价值。过去很多人第一次看到 ADV 外观时就已经心动了，只是想到买回来却没法在国内常用频段里好好玩，热情往往也就停在了购物车里。</p><p>自从这个 480 MHz 模块推出后，已经有好几个群友因此马上下单了 ADV。</p><p>接下来先看看群友 <em>西安-BI9ABS</em> 的分享。</p><p><img src="/adv-cap-lora-480mhz-cn470-first-field-reports/adv-470-module-board-with-enclosure-parts.webp" alt="470 模组本体与外壳部件"></p><p>这组图里的外壳，是 <a href="/contact/">微信群</a> 群友 <em>西安-BI9ABS</em> 打印出来的。他选了绿色材料，整体看起来很醒目，也很适合 ADV 这类本来就带点玩具感和随身设备气质的小机器。</p><p><img src="/adv-cap-lora-480mhz-cn470-first-field-reports/adv-470-module-green-enclosure-top-view.webp" alt="470 模组外壳顶视图"></p><p>更有意思的是，BI9ABS 不是直接原样打印 <a href="/adv-cap-lora-480mhz-cn470/#3D-%E5%A4%96%E5%A3%B3">Tonas 大佬的模型</a>，而是在原本模型基础上稍微加了一点自己的个性化设计，把自己的呼号融进了外壳表面。</p><p>这里用到了 3D 打印机的多色打印功能，所以外壳本身就直接带着呼号，不需要后贴标签。呼号部分选了黄色，和绿色外壳放在一起很协调。黄色本来就是绿色的邻近色，视觉上既显眼，又不会突兀。</p><p><img src="/adv-cap-lora-480mhz-cn470-first-field-reports/adv-with-470-cap-and-green-case.webp" alt="装上 470 模组后的 ADV"></p><h2 id="群友-上海-cx-的信号对比">群友 <em>上海-cx</em> 的信号对比</h2><p>在看信号对比之前，有一个前提一定要先说清楚。</p><p>这组测试里，双方模块都设置成了 <code>CN470</code> 的 LoRa 频段参数来做对比。这样做并不是因为 ADV 原装模块最适合这个频段，恰恰相反，原装模块出售时对应的就是 <code>8xx-9xx MHz</code> 使用场景，无论是模块本身、配套天线，还是 PA（功率放大器）的设计目标，都不是给 <code>CN470</code> 准备的。</p><p>所以如果单纯从原装模块的最佳工作状态来说，这当然不是它最舒服的频段，也不是它最公平的理论上限。</p><p>但问题在于，今天中国社区里大家日常要接入的，就是 <code>CN470</code> 网络。很多已经买了 ADV 的群友，为了能和群友通信，实际做法本来就是把原装模块也切到 <code>CN470</code> 去用。</p><p>这组测试真正想回答的，也正是在同样要接入 <code>CN470</code> 的现实前提下，原装模块和 470 模组各自表现会怎样，而不是比较它们在各自最佳频段下谁更强。</p><p>在下面这组信号对比里，<em>上海-cx</em> 使用的是 Heltec LoRa32 V3 和 M5Stack Cardputer ADV，两边都烧录了 Meshtastic 原装固件。</p><p>这里的角色分工也需要说明一下：ADV 是发送端，Heltec V3 是接收端，手机连接的是 Heltec V3，所以截图里看到的 <code>RSSI</code> 和 <code>SNR</code>，都是 Heltec V3 接收到 ADV 发来的消息时所记录的信号读数。</p><p>测试一共做了两轮，分别是：</p><ol><li>ADV 和 Heltec V3 放在近距离</li><li>ADV 和 Heltec V3 相隔 5 米、途中还有桌子等家具遮挡。</li></ol><p>两轮测试的目的都一样，不是看原装模块在最佳频段下能跑到什么上限，而是看它们在同样切到 <code>CN470</code> 之后，实际接入国内常用网络时会出现什么差别。</p><p>第一轮是近距离对比。根据 <em>上海-cx</em> 提供的说明，这组测试里 Heltec V3 作为接收端，放在 ADV 上方几厘米外。</p><p><img src="/adv-cap-lora-480mhz-cn470-first-field-reports/adv-original-vs-470-module-rssi-comparison-minus79-vs-minus10dbm.webp" alt="原装模块与 470 模组的近距离 RSSI 对比"></p><p>当 ADV 换上新的 470 第三方模块发射时，手机连接 Heltec V3 后显示的接收读数是 <code>SNR 7.00 dB</code>、<code>RSSI -10 dBm</code>。</p><p>当 ADV 使用原厂模块发射时，对应读数是 <code>SNR 6.00 dB</code>、<code>RSSI -79 dBm</code>。</p><p>这说明即便把环境因素尽量压低，只看一个很近的收发条件，专门为 <code>CN470</code> 准备的模组和把原装模块硬切到 <code>CN470</code> 去用，仍然会拉开非常明显的差距。</p><p>第二轮是带遮挡的 5 米测试。根据 <em>上海-cx</em> 提供的记录，ADV 作为发送端，Heltec V3 作为接收端，两者相隔约 5 米，中间还有桌子等家具遮挡。</p><p><img src="/adv-cap-lora-480mhz-cn470-first-field-reports/adv-original-vs-470-module-rssi-comparison-5m-with-furniture-obstruction.webp" alt="原装模块与 470 模组的 RSSI 对比——相隔 5 米，途中还有桌子等家具遮挡"></p><p>在这组带遮挡的 5 米测试里，当 ADV 使用原装模块并切到 <code>CN470</code> 发射时，Heltec V3 端测得 <code>SNR 5.50 dB</code>、<code>RSSI -80 dBm</code>。</p><p>当 ADV 换成第三方 470 模组发射时，Heltec V3 端测得 <code>SNR 6.25 dB</code>、<code>RSSI -30 dBm</code>。这个差距已经很明显了。</p><p>即便不是远距离场景，只是把设备拉开一点距离，再加上室内常见遮挡，原装模块在 <code>CN470</code> 下的吃亏就已经开始体现出来。</p><h3 id="信号对比数据汇总">信号对比数据汇总</h3><p>近距离测试：</p><table><thead><tr><th>模块</th><th>指标</th><th>数值</th></tr></thead><tbody><tr><td>原装 ADV 模块切到 <code>CN470</code></td><td><code>SNR</code></td><td><code>6.00 dB</code></td></tr><tr><td>470 模组</td><td><code>SNR</code></td><td><code>7.00 dB</code></td></tr><tr><td>原装 ADV 模块切到 <code>CN470</code></td><td><code>RSSI</code></td><td><code>-79 dBm</code></td></tr><tr><td>470 模组</td><td><code>RSSI</code></td><td><code>-10 dBm</code></td></tr></tbody></table><p>5 米带家具遮挡测试：</p><table><thead><tr><th>模块</th><th>指标</th><th>数值</th></tr></thead><tbody><tr><td>原装 ADV 模块切到 <code>CN470</code></td><td><code>SNR</code></td><td><code>5.50 dB</code></td></tr><tr><td>470 模组</td><td><code>SNR</code></td><td><code>6.25 dB</code></td></tr><tr><td>原装 ADV 模块切到 <code>CN470</code></td><td><code>RSSI</code></td><td><code>-80 dBm</code></td></tr><tr><td>470 模组</td><td><code>RSSI</code></td><td><code>-30 dBm</code></td></tr></tbody></table><p>这两轮测试放在一起看，已经足够说明，在同样要进入 <code>CN470</code> 使用场景的前提下，专门为这个频段准备的 470 模组，和把原装 <code>8xx-9xx MHz</code> 模块强行切到 <code>CN470</code> 去勉强使用，确实信号差距很大。</p><h2 id="对-ADV-意味着什么">对 ADV 意味着什么</h2><p>后面如果群里还有更多不同环境下的截图和反馈，这篇文章还会继续补充。</p><p>到那时，我们也许能更完整地看到，这块 470 模组到底会把 ADV 带到一个高度上。</p><p>如果你还没看的话，务必读一下这篇《<a href="/adv-cap-lora-480mhz-cn470/">M5Stack ADV 的最后一块拼图：来自社区的 480MHz LoRa 模组</a>》。里面把这块模块的来历、设计思路、功耗表现和 3D 外壳等信息写得更完整，和这篇实测记录一起看，会更容易理解这块 470 模组为什么对 M5Stack 的 ADV 如此重要。</p><p>最后顺手放一张群友 <em>dovechan</em> 的 ADV 美图。这张和 470 模组本身无关，而是他对 M5Stack ADV 机身做了金属化处理后的实拍，单看外观就已经很有质感。</p><p><img src="/adv-cap-lora-480mhz-cn470-first-field-reports/dovechan-m5stack-adv-metalic-body-enclosure.webp" alt="dovechan 金属化处理后的 M5Stack ADV 机身"></p>]]></content>
    
    
    <summary type="html">上一篇我们聊的是 M5Stack Carputer ADV 终于补上了 470MHz 这块关键拼图，而这几天更让人兴奋的，是它开始从支持走向上手。对已经买了 ADV 的群友来说，这块模组终于让设备可以顺利切进国内常用频段；对那些一直喜欢 ADV、却因为没有 470 支持而迟迟没下单的人来说，现在也终于到了可以认真考虑入手的时候。</summary>
    
    
    
    <category term="产品" scheme="https://meshcn.net/categories/%E4%BA%A7%E5%93%81/"/>
    
    
    <category term="M5Stack" scheme="https://meshcn.net/tags/M5Stack/"/>
    
    <category term="ADV" scheme="https://meshcn.net/tags/ADV/"/>
    
    <category term="CN470" scheme="https://meshcn.net/tags/CN470/"/>
    
    <category term="LoRa" scheme="https://meshcn.net/tags/LoRa/"/>
    
  </entry>
  
  <entry>
    <title>M5Stack ADV 的最后一块拼图：来自社区的 480MHz LoRa 模组</title>
    <link href="https://meshcn.net/adv-cap-lora-480mhz-cn470/"/>
    <id>https://meshcn.net/adv-cap-lora-480mhz-cn470/</id>
    <published>2026-03-20T13:35:00.000Z</published>
    <updated>2026-03-20T13:35:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>在过去很长一段时间里，MeshCN 社区里其实有不少人都对 M5Stack ADV 心动过。它有屏幕、有实体键盘、足够便携，还有一种很少见的极客式工业设计美感。很多人第一次看到实机时，几乎都会产生同一个念头：这台设备真的很好看。</p><p><em>下面这组 ADV 实机照片由群友 中山-dovechan 拍摄</em></p><p><img src="./adv-cardputer-message-screen-closeup.webp" alt="ADV 实机近景：消息界面特写"></p><p>但真正准备下单时，问题也随之而来。ADV 原生只提供 868 MHz LoRa 模组，而国内 Meshtastic 社区最常见的组网频段是 470–510 MHz。理论上可以通过修改参数让设备先跑起来，但在不匹配的射频条件下，信号质量往往会明显下降，实际参与组网的体验也会大打折扣。</p><p><img src="./adv-cardputer-with-lora-cap-side-view.webp" alt="ADV 实机：本体与 LoRa CAP 侧视图"></p><p>于是，一种颇为微妙的状态长期存在于社区之中。很多人喜欢 ADV，也认可它的设计与形态，却因为频段问题选择暂时停手，把购买计划一再往后推。</p><p><img src="./adv-cardputer-message-screen-front.webp" alt="ADV 实机：消息界面正面视图"></p><p>直到这块来自社区开发者的 480 MHz LoRa CAP 模组出现，这种犹豫才终于有了一个明确的终点。对于那些曾经观望的人来说，现在或许才是可以真正放心剁手的时刻。</p><p><img src="./adv-cardputer-epaper-node-list-status.webp" alt="ADV 实机：外接电子纸显示节点与状态"></p><p>有见及此，群友 <em>深圳-陈喜发</em> 设计了 ADV CAP LoRa 480MHz 模组，让 ADV 支持 470-510 MHz，完美解决过去 ADV 的唯一缺点。</p><video controls width="100%">  <source src="./adv-cap-demo-small-720p-vp9-crf42.webm" type="video/webm">  Your browser does not support the video tag.</video><h2 id="功能和表现">功能和表现</h2><p>这个 480 模组的有两大重要功能。</p><p>第一个自然是前文所说的带来对中国频率的支持，这对于一个以无线电为主题的社区来说尤其重要。</p><p>第二点，则是具备了 GNSS/GPS 开关，当你不需要定位功能的时候，你能直接硬件关掉 GPS，从而大幅降低功耗。</p><p><img src="./adv-cap-480mhz-module-board.webp" alt="ADV CAP LoRa 480MHz 模组实物"></p><p>可能大家会疑惑，为什么这组信号对比不是拿 868 原装模组在 868 频段的最佳状态，去和 480 模组在 480 频段做跨频段比较？</p><table><thead><tr><th>对比项（同为 CN480 使用场景）</th><th>ADV CAP 868MHz</th><th>ADV CAP 480MHz</th></tr></thead><tbody><tr><td>原稿截图</td><td><img src="./adv-cap-868mhz-rssi-minus45dbm.webp" alt="ADV CAP 868MHz 近距离接收读数"></td><td><img src="./adv-cap-480mhz-rssi-minus15dbm.webp" alt="ADV CAP 480MHz 近距离接收读数"></td></tr><tr><td>近距离接收读数</td><td><code>-45 dBm</code></td><td><code>-15 dBm</code></td></tr></tbody></table><p>原因很简单，当前中国社区节点的频率都在 480 频段（准确来说是 478.875 Mhz）。群里的 ADV 用户为了和群友联通，他们所做的就是把原装 868 MHz 设备地区改到 <code>CN</code> （中国），也就是 480 MHz 频率。</p><p>所以这组数据回答反映的是，在同样要接入 <code>CN480</code> 网络的前提下，原装 868 模组和 480 模组谁更适合当前社区的实际使用。它反映的是实际组网可用性，并非各自芯片在原生目标频段下的理论上限。</p><p>这个第三方 480 MHz 模块相比原版 868 MHz 模块，多了一个非常实用的设计，就是手动 GPS 断电开关。在多数 mesh 设备中，GNSS 模块一直都是主要的耗电来源之一，只要持续处于定位尝试状态，就会对续航产生明显影响。</p><p>这个功能的价值，在室内使用场景下会变得尤为突出。比如当你把 ADV CAP 带进室内时，其实并不需要设备进行定位，但 mesh 设备不像手机那样可以依靠基站、蓝牙或 WiFi 去推算大致位置，而是会不断尝试重新锁定 GNSS 卫星信号。在卫星信号受阻的环境中，这种反复搜索的过程往往是最耗电的状态之一。因此，能够通过硬件一键关闭 GNSS 供电，就成为一个非常直接且有效的省电手段。</p><p>下面这组功耗读数，分别对应三种状态：</p><ul><li>ADV CAP 868 MHz 在默认开启 GPS 时的电流表现</li><li>ADV CAP 480 MHz 手动开启 GPS 时的电流</li><li>ADV CAP 480 MHz 手动关闭 GPS 后的待机电流</li></ul><table><thead><tr><th>对比项</th><th>ADV CAP 868MHz（GPS 默认开启）</th><th>ADV CAP 480MHz（GPS 开启）</th><th>ADV CAP 480MHz（GPS 关闭）</th></tr></thead><tbody><tr><td></td><td><img src="./adv-cap-868mhz-gps-on-current-75-85ma.webp" alt="868MHz GPS 默认开启电流"></td><td><img src="./adv-cap-480mhz-gps-on-current-57-48ma.webp" alt="480MHz GPS 开启电流"></td><td><img src="./adv-cap-480mhz-gps-off-current-2-688ma.webp" alt="480MHz GPS 关闭电流"></td></tr><tr><td>电流读数</td><td><code>75.85 mA</code></td><td><code>57.48 mA</code></td><td><code>2.688 mA</code></td></tr></tbody></table><p>根据 深圳-陈喜发 的测算，在日常使用场景中手动关闭 GPS 供电，理论上可以带来约 60 小时的续航提升。</p><p>当然，这个数字仍然属于开发者侧的推算值，真实续航表现还需要更多用家在实际网络环境中长期使用后才能逐步验证。</p><p>后续如果社区里有新的实测数据，我们也会继续补充更新。</p><h2 id="3D-外壳">3D 外壳</h2><p>如果你在 MeshCN 微信群里，你自然知道群里有一个建模大佬 <em>南京-Tonas</em>，他的设计功力深厚，精品频出。</p><p><img src="./adv-3d-case-exploded-view-by-tonas.webp" alt="ADV 配件 3D 外壳爆炸图（南京-Tonas 设计）"></p><p>这一次，他为这个第三方的 480 MHz LoRa CAP 模组设计了专属外壳。</p><p>推荐打印参数为 0.2mm 层高、2 层墙、15% 填充，预计打印需时约 50 分钟。</p><p><img src="./adv-3d-case-assembly-guide-by-tonas.webp" alt="ADV 配件 3D 外壳装配指引图（南京-Tonas 设计）"></p><p>在 3D 打印完这个外壳后，第一步是放入 PCB 到外壳里，接着对准放入 GPS 开关，尤其注意缺口的方向；接着盖上后盖，拧入 3 颗 M2 x 6mm 螺丝就大功告成了。</p><p>这个外壳已经发布到拓竹社区，链接如下：<br><a href="https://makerworld.com.cn/zh/models/2286381-m5stack-adv-lora-470-ban-ben-wai-ke">M5Stack ADV LoRa 470 版本外壳（MakerWorld）</a></p><p>如果这个设计对你有帮助，也欢迎顺手点个赞、加个收藏；如果你手上有助力券，也可以顺手支持一下 Tonas。</p><p><img src="./adv-cardputer-3d-case-front-view.webp" alt="ADV 配件 3D 外壳实机正面视图"></p><p><img src="./adv-cardputer-3d-case-rear-view.webp" alt="ADV 配件 3D 外壳实机背面视图"></p><h2 id="购买信息">购买信息</h2><p>目前可通过模块作者在闲鱼发布的商品链接购买：<br><a href="https://m.tb.cn/h.iTicQ4u?tk=l076UzHFHlU">闲鱼平台｜M5 CARPUTER ADV 第三方 480MHz LoRa CAP 模组</a></p><p>需要注意，这个产品本身不自带外壳，外壳需要自行 3D 打印。</p><h2 id="结语">结语</h2><p>从更大的使用场景来看，这类硬件层面的优化，意义其实并不仅仅体现在单台设备的续航数字上。随着国内 Meshtastic 网络逐渐从点对点试玩，进入到跨区、跨城的真实通联阶段，设备是否能够稳定工作更长时间，正在变得越来越重要。</p><p>尤其是在当前组网进展较快的大湾区与杭州湾地区，越来越多群友开始尝试使用便携节点参与长时间在线的城市级链路测试。在这种背景下，支持国内 470/480 频段的 ADV 模组，不仅让设备真正具备参与网络的能力，也让它有机会成为跨城链路中的一环。</p><p>目前，大湾区已经实现 RF 打通的城市包括深圳、广州、东莞、中山、佛山、珠海、澳门、肇庆与惠州。而在杭州湾一带，杭州、绍兴、苏州、湖州与上海之间的同城及跨城网络，也正在逐步形成规模。</p><p>对于很多 ADV 玩家，以及因为 ADV 不支持 470 MHz 而选择观望不买的玩家，这块来自社区的 480 MHz 模组，某种程度上也意味着他们终于可以把这台设备真正带入国内的 mesh 网络之中。</p><p>目前，信号和功耗数据都来源自模块的开发者 <em>深圳-陈喜发</em>。后续如果社区里有群友分享实测数据，我们会再更新这篇文章。</p><blockquote class="blockquote-note blockquote-note__info"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="16" viewBox="0 0 14 16"><path fill-rule="evenodd" d="M6.3 5.69a.942.942 0 0 1-.28-.7c0-.28.09-.52.28-.7.19-.18.42-.28.7-.28.28 0 .52.09.7.28.18.19.28.42.28.7 0 .28-.09.52-.28.7a1 1 0 0 1-.7.3c-.28 0-.52-.11-.7-.3zM8 7.99c-.02-.25-.11-.48-.31-.69-.2-.19-.42-.3-.69-.31H6c-.27.02-.48.13-.69.31-.2.2-.3.44-.31.69h1v3c.02.27.11.5.31.69.2.2.42.31.69.31h1c.27 0 .48-.11.69-.31.2-.19.3-.42.31-.69H8V7.98v.01zM7 2.3c-3.14 0-5.7 2.54-5.7 5.68 0 3.14 2.56 5.7 5.7 5.7s5.7-2.55 5.7-5.7c0-3.15-2.56-5.69-5.7-5.69v.01zM7 .98c3.86 0 7 3.14 7 7s-3.14 7-7 7-7-3.12-7-7 3.14-7 7-7z"></path></svg></div>2026-03-26 更新</div><div class="blockquote-note__content"><p>第一批群友实测已经单独整理成文，有兴趣的话可以继续看《<a href="/adv-cap-lora-480mhz-cn470-first-field-reports/">ADV 470 模组的第一批实测来了</a>》，里面能更直观看到原装模块切到 <code>CN470</code> 后，与 470 模组之间的实际信号差距。</p></div></blockquote>]]></content>
    
    
    <summary type="html">对于不少 Meshtastic 玩家来说，M5Stack ADV 一直是一台几乎完美的随身节点：它有屏幕、有键盘、足够便携，也有着出众的工业设计。但在国内常用的 470–510 MHz 组网环境下，这台设备始终差了关键一步。480 MHz LoRa CAP 模组正在补上这块最后的拼图，不仅让 ADV 真正融入中国本地频段生态，也带来了更强的信号读数与更灵活的功耗控制。</summary>
    
    
    
    <category term="产品" scheme="https://meshcn.net/categories/%E4%BA%A7%E5%93%81/"/>
    
    
    <category term="M5Stack" scheme="https://meshcn.net/tags/M5Stack/"/>
    
    <category term="ADV" scheme="https://meshcn.net/tags/ADV/"/>
    
  </entry>
  
  <entry>
    <title>MeshCore 入门第一课：从一条视频读懂它怎么工作</title>
    <link href="https://meshcn.net/meshcore-newcomer-intro-from-comms-channel/"/>
    <id>https://meshcn.net/meshcore-newcomer-intro-from-comms-channel/</id>
    <published>2026-03-18T05:10:00.000Z</published>
    <updated>2026-03-18T05:10:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>如果你已经关注 MeshCN 一段时间，大概率对 The Comms Channel 不陌生。MeshCN 社区创立之初，很多初步摸索都靠这位博主的视频。</p><p>这次我们也开始一个新的 MeshCore 系列翻译整理：按 <em>The Comms Channel</em> 的视频顺序持续更新，视频会同步转载到 B 站，并配套中文字幕汉化。</p><blockquote class="blockquote-note blockquote-note__info"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="16" viewBox="0 0 14 16"><path fill-rule="evenodd" d="M6.3 5.69a.942.942 0 0 1-.28-.7c0-.28.09-.52.28-.7.19-.18.42-.28.7-.28.28 0 .52.09.7.28.18.19.28.42.28.7 0 .28-.09.52-.28.7a1 1 0 0 1-.7.3c-.28 0-.52-.11-.7-.3zM8 7.99c-.02-.25-.11-.48-.31-.69-.2-.19-.42-.3-.69-.31H6c-.27.02-.48.13-.69.31-.2.2-.3.44-.31.69h1v3c.02.27.11.5.31.69.2.2.42.31.69.31h1c.27 0 .48-.11.69-.31.2-.19.3-.42.31-.69H8V7.98v.01zM7 2.3c-3.14 0-5.7 2.54-5.7 5.68 0 3.14 2.56 5.7 5.7 5.7s5.7-2.55 5.7-5.7c0-3.15-2.56-5.69-5.7-5.69v.01zM7 .98c3.86 0 7 3.14 7 7s-3.14 7-7 7-7-3.12-7-7 3.14-7 7-7z"></path></svg></div>翻译声明</div><div class="blockquote-note__content"><p>本文基于 <em>The Comms Channel</em> 视频《<a href="https://www.youtube.com/watch?v=iaFltojJrAc">There’s a newcomer to the Mesh world</a>》内容翻译整理。这是本系列第 1 篇，重点是入门概览，不是深度对比评测。</p></div></blockquote><p>MeshCore 的目标和 Meshtastic 很接近，都是围绕低成本 LoRa 硬件，做一个开源、加密、离网可用的文本通信网络，不依赖蜂窝网络或 Wi-Fi。</p><p>区别在于，MeshCore 在空口流量控制、节点可见性和消息路径收敛上，更强调尽量减少无效广播，把空口资源留给真正要发送的消息。</p><p>原 YouTube 视频受国内网络环境影响，对国内读者不方便观看。因此，我已搬运到 <a href="https://www.bilibili.com/video/BV1MpwQzjEna/">Bilibili</a>，并在下方嵌入播放器。</p><p>已翻译中文字幕且添加到视频里，看的时候记得打开哦~</p><div style="position: relative; width: 100%; padding-top: 56.25%;">  <iframe style="position: absolute; inset: 0; width: 100%; height: 100%;" src="https://player.bilibili.com/player.html?bvid=BV1MpwQzjEna&page=1&as_wide=1&high_quality=1&danmaku=0" frameborder="no" scrolling="no" allowfullscreen="true"></iframe></div><h2 id="一个标准-MeshCore-配置，实际由什么组成">一个标准 MeshCore 配置，实际由什么组成</h2><p>按视频里的描述，一个典型 MeshCore 使用链路很直白: 手机 App 通过蓝牙连到节点设备，节点再通过 LoRa 和周围设备通信。对已经在用 Meshtastic 的朋友来说，门槛相对低，因为很多现有硬件本来就能刷 MeshCore。</p><p>短距离蓝牙负责手机和节点之间的本地连接；LoRa 负责节点与节点之间的远距离链路。你在手机里点发送，消息先走蓝牙到节点，再由节点发到 LoRa 空口。</p><p>视频里提到 MeshCore 的三种常见固件形态，分别对应三种使用目标。Companion 固件是最常见的个人终端形态，配合手机 App 收发消息。Repeater 固件适合放在山地、高点或天线条件好的位置，负责转发消息、延展覆盖。Room Server 固件更像有记忆的留言房间，重点不是实时来回对话，而是让用户离线后回来还能读到期间留在房间里的内容。</p><p>很多人刚接触 Room Server 时会把它当普通群聊机器人，但视频给的定位更接近留言信箱。也就是说，它解决的是错过在线时段还能补看内容，而不是替代你所有实时私聊场景。</p><h2 id="MeshCore-如何让网络更安静">MeshCore 如何让网络更安静</h2><p>Meshtastic 用户很容易感受到一个差异: 在 Meshtastic 里，节点会周期性对外广播我在这里；而 MeshCore 选择把这件事做得更克制。</p><p>在 MeshCore 中，普通设备默认不会频繁自动宣告自身存在。你需要手动发一次 advert（可理解为亮相广播）告诉网络你上线了。这样做的目的，是降低空口里无业务广播的占比，提高消息真正投递时的可靠性。</p><p>视频还给了一个具体参数: 如果设备运行的是 Repeater 或 Room Server 固件，advert 可以自动发送，但频率很低。默认是每 12 小时一次，并且可调范围是 3 到 48 小时。MeshCore 的设计就是把广播变成低频、可控、和角色绑定的行为。</p><h2 id="MeshCore-路由原理：先泛洪">MeshCore 路由原理：先泛洪</h2><p>第一次私信发送时，MeshCore 采用 flood routing（泛洪路由）。也就是消息先被范围内中继尽可能扩散，一级一级转发，直到有节点能把包送到目标。这个阶段会比较吵，因为同时参与转发的节点多，空口里会出现明显的并发通信。</p><p>但 MeshCore 的关键不在泛洪，而在泛洪之后立刻收敛。视频里明确说，首次泛洪过程中，中继会记录消息经过的路径；路径信息随后传到目标端。目标一旦知道回程最有效路径，回复就不再重复泛洪，而是走 direct path（直连路径）回去。</p><p>从这个时刻开始，双方后续消息都尽量沿这条更干净的路径走。结果是网络流量明显下降，通信效率和稳定性同时提升。</p><p>视频还给了失败回退机制: 如果这条直连路径上的某一跳失效，比如某个中继离线，消息会投递失败。连续失败三次后，系统会自动退回泛洪重新找路；找到可用路径后，再切回直连模式继续通信。</p><h2 id="它和-Meshtastic-的关系，视频是怎么说的">它和 Meshtastic 的关系，视频是怎么说的</h2><p>The Comms Channel 在视频里没有回避对比，但态度很克制。他明确提到: Meshtastic 在 2.6 版本里已经有 next hop routing（下一跳路由）这类能力，所以私信逐步收敛路径并不是 MeshCore 独有概念。</p><p>MeshCore 在这条视频里强调的差异点是另一件事: 如果你已经知道要走哪条路径，可以在 App 里手动指定，跳过首次泛洪。这在业余无线电语境下很容易理解，类似你预先指定报文经过哪些中继路径。</p><p>这意味着 MeshCore 给了高级用户更强的路径控制手段，但也意味着你需要更清楚地理解网络拓扑，才能把这个功能用好。对入门用户来说，先让自动机制跑起来，再考虑手动路径，会更稳妥。</p><p>当聊天对象从一个人变成分散在大范围的一群人时，无论 MeshCore 还是 Meshtastic，公共房间消息本质上都离不开泛洪。原因很现实，目标是一个分布式群体，不是单一终点，几乎不可能靠一条固定直连路径覆盖所有接收方。</p><p>Room Server 在这里扮演的是延时可读的组织层，而不是神奇路由器。用户需要登录房间或通过 ACL（访问控制列表）获得权限。每个 Room Server 还带密码，默认密码可以保持 <code>hello</code> 作为公开入口，也可以改成自定义密码进行访问限制。</p><p>还有一个很有价值的工程点: 视频提到 Room Server 在底层仍复用直连路径逻辑。也就是说，前面讲的路径收敛收益，在 Room Server 场景同样能用上。</p><h2 id="结语">结语</h2><p>如果你是刚接触 LoRa Mesh 的新手，这条视频最友好的地方是把概念讲得足够直白，尤其是 Companion、Repeater、Room Server 三种固件角色，以及 advert、flood routing、direct path 这些核心词之间的关系。先把理论搞懂，后面的部署、参数、设备选择就会轻松很多。</p><p>这篇是系列第 1 篇。如果你已经理解了 MeshCore 的基本工作方式，建议继续读系列第二篇：<a href="/meshcore-why-switch-from-meshtastic-from-comms-channel/">《MeshCore 入门第二课：为什么我们正从 Meshtastic 切换到 MeshCore》</a>。那一篇会接着看多个美国社区为什么开始认真从 Meshtastic 转向 MeshCore。</p><h2 id="参考">参考</h2><ul><li>The Comms Channel: <a href="https://www.youtube.com/watch?v=iaFltojJrAc">There’s a newcomer to the Mesh world</a></li></ul>]]></content>
    
    
    <summary type="html">这篇文章带你从零理解 MeshCore 的基本工作方式：设备角色、首包泛洪与后续直连、Room Server 的意义，以及它和 Meshtastic 在入门层面的关键差异。按 The Comms Channel 的《There&#39;s a newcomer to the Mesh world》视频内容翻译整理。</summary>
    
    
    
    <category term="教程" scheme="https://meshcn.net/categories/%E6%95%99%E7%A8%8B/"/>
    
    
    <category term="MeshCore" scheme="https://meshcn.net/tags/MeshCore/"/>
    
    <category term="The Comms Channel" scheme="https://meshcn.net/tags/The-Comms-Channel/"/>
    
  </entry>
  
  <entry>
    <title>很可爱的 MeshCore 小手机</title>
    <link href="https://meshcn.net/meshcore-smartphone-lilygo-t-display-p4/"/>
    <id>https://meshcn.net/meshcore-smartphone-lilygo-t-display-p4/</id>
    <published>2026-03-17T11:40:00.000Z</published>
    <updated>2026-03-17T11:40:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>如果你已经玩过一段时间 LoRa Mesh，大概率会同意一句话：这类网络很有潜力，但对普通用户一直不够友好。很多时候我们都在和参数、角色、路由逻辑打交道，而不是像用手机那样自然地发消息、看状态、切界面。</p><blockquote class="blockquote-note blockquote-note__info"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="16" viewBox="0 0 14 16"><path fill-rule="evenodd" d="M6.3 5.69a.942.942 0 0 1-.28-.7c0-.28.09-.52.28-.7.19-.18.42-.28.7-.28.28 0 .52.09.7.28.18.19.28.42.28.7 0 .28-.09.52-.28.7a1 1 0 0 1-.7.3c-.28 0-.52-.11-.7-.3zM8 7.99c-.02-.25-.11-.48-.31-.69-.2-.19-.42-.3-.69-.31H6c-.27.02-.48.13-.69.31-.2.2-.3.44-.31.69h1v3c.02.27.11.5.31.69.2.2.42.31.69.31h1c.27 0 .48-.11.69-.31.2-.19.3-.42.31-.69H8V7.98v.01zM7 2.3c-3.14 0-5.7 2.54-5.7 5.68 0 3.14 2.56 5.7 5.7 5.7s5.7-2.55 5.7-5.7c0-3.15-2.56-5.69-5.7-5.69v.01zM7 .98c3.86 0 7 3.14 7 7s-3.14 7-7 7-7-3.12-7-7 3.14-7 7-7z"></path></svg></div>翻译声明</div><div class="blockquote-note__content"><p>本文基于 Hackster News 作者 Cameron Coward 的文章《<a href="https://www.hackster.io/news/you-can-now-buy-a-meshcore-smartphone-d50105def46b">You Can Now Buy a MeshCore Smartphone</a>》翻译整理。Hackster 页面显示该文发布于约 3 个月前。原视频首发在 YouTube；为了方便国内读者观看，文末已替换为 MeshCN 搬运到 B 站的版本。</p></div></blockquote><p>这篇文章的核心观点很明确：<a href="https://meshcore.co.uk/index.html">MeshCore</a> 搭配 <a href="https://lilygo.cc/products/t-display-p4?variant=52092825010357">LILYGO T-Display P4</a>，第一次把智能手机式的 Mesh 体验拉到了可落地的阶段。它不是通用设备加一个 Mesh App 的思路，而是更接近为 Mesh 通信原生设计的一套系统（不少玩家也会把这种方向称为 MeshOS 体验）。这种形态在体验上会让人联想到 iOS 或 Android，但它不依赖蜂窝网络，通信完全走 MeshCore 的链路。</p><p><img src="./the_device_youve_been_waiting_for_12-26_screenshot_b1Z0DqjVhj.webp" alt="MeshCore 在 LILYGO T-Display P4 上的界面演示"></p><p>从生态角度看，文章也承认一个现实：当前 Meshtastic 的普及度仍然更高。但 MeshCore 并不只是后来者，它已经有一些足够吸引人的特性。文中提到，MeshCore 创始人 Andy Kirby 在最新视频里展示的手机形态设备，可能会成为推动用户采用的重要节点。</p><p>现阶段这个 MeshCore 固件里的操作系统能力还比较有限，可用应用数量不多，还不能替代现代智能手机。但作为离网通信方向的专用终端，它已经表现出明显的潜力。</p><div style="position: relative; width: 100%; padding-top: 56.25%;">  <iframe style="position: absolute; inset: 0; width: 100%; height: 100%;" src="https://player.bilibili.com/player.html?bvid=BV1ntP5zNEc1&page=1&as_wide=1&high_quality=1&danmaku=0" frameborder="no" scrolling="no" allowfullscreen="true"></iframe></div><p>另一个关键点是，这套方案不需要定制硬件。按原文信息，用户可以通过 <a href="https://flasher.meshcore.co.uk/">MeshCore 网页烧录器</a> 直接刷到 LILYGO T-Display P4 上。虽然官方商城当时显示缺货，但正常价格大约在 120 美元。硬件规格也比较完整：ESP32-P4 主控、SX1262 LoRa 模块、AMOLED 屏幕、2MP 摄像头、9 轴 IMU、麦克风、扬声器、锂电池，甚至还有以太网口。</p><blockquote class="blockquote-note blockquote-note__warning"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="12" height="16" viewBox="0 0 12 16"><path fill-rule="evenodd" d="M5.05.31c.81 2.17.41 3.38-.52 4.31C3.55 5.67 1.98 6.45.9 7.98c-1.45 2.05-1.7 6.53 3.53 7.7-2.2-1.16-2.67-4.52-.3-6.61-.61 2.03.53 3.33 1.94 2.86 1.39-.47 2.3.53 2.27 1.67-.02.78-.31 1.44-1.13 1.81 3.42-.59 4.78-3.42 4.78-5.56 0-2.84-2.53-3.22-1.25-5.61-1.52.13-2.03 1.13-1.89 2.75.09 1.08-1.02 1.8-1.86 1.33-.67-.41-.66-1.19-.06-1.78C8.18 5.31 8.68 2.45 5.05.32L5.03.3l.02.01z"></path></svg></div>国内频段提醒</div><div class="blockquote-note__content"><p>按 <a href="https://lilygo.cc/products/t-display-p4">LILYGO 官方商品页</a> 当前可选规格（2026 年 3 月 2 日）来看，T-Display P4 的 SX1262 频段是 868 / 915 / 920 MHz，不包含国内常用的 470-510 MHz（如 CN470）。</p><p>国内读者下单或组网前，建议先确认本地网络频段是否匹配。</p></div></blockquote><p>所以这篇文章最后的判断我基本认同：它现在依旧是实验性质的方案，但方向是对的。Mesh 网络要真正扩大采用率，靠的不只是更远的链路，还得有更像日常设备的使用体验。而这种面向 Mesh 原生交互的手机化路径，确实值得持续关注。</p><p>如果你对这条路线感兴趣，也可以回看我们之前的 <a href="/whisperos-intro-for-meshcn-users/">WhisperOS 介绍</a>。它和这次的 MeshCore 手机化尝试，在终端交互层面的思路确实有异曲同工之妙。</p><p>如果你对这套系统感兴趣，欢迎在 <a href="/contact/">微信群和 QQ 群</a> 艾特我。后续我会按大家最关心的方向，继续更新这个 OS 的系列内容。</p>]]></content>
    
    
    <summary type="html">Mesh 网络这些年一直卡在能用但难用。Hackster 这篇文章里提到的 MeshCore + LILYGO T-Display P4，给出了一个更像智能手机的方向：不只是装个 App，而是把整套交互围绕 Mesh 通信来设计。</summary>
    
    
    
    <category term="产品" scheme="https://meshcn.net/categories/%E4%BA%A7%E5%93%81/"/>
    
    
    <category term="MeshCore" scheme="https://meshcn.net/tags/MeshCore/"/>
    
    <category term="LILYGO" scheme="https://meshcn.net/tags/LILYGO/"/>
    
    <category term="T-Display P4" scheme="https://meshcn.net/tags/T-Display-P4/"/>
    
  </entry>
  
  <entry>
    <title>樱花派 Pocket Namiji 开源了：README 已给齐固件、原理图和 3D 外壳</title>
    <link href="https://meshcn.net/sakurapi-pocket-namiji-open-source-announcement/"/>
    <id>https://meshcn.net/sakurapi-pocket-namiji-open-source-announcement/</id>
    <published>2026-03-14T05:04:00.000Z</published>
    <updated>2026-03-14T05:04:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>如果你之前已经看过前一篇《<a href="/new-device-sakura-pi-pocket-namiji/">来自深圳-派派的新品：Sakura Pi Pocket Namiji 上线</a>》，那这篇可以直接理解成它的 follow up。</p><p>前一篇主要讲的是这块板子的定位、硬件设计和低功耗思路。</p><p>而这次真正值得补上的，是它的开源资料、文档入口、结构文件，以及可以直接下载和上手的固件资源。</p><p><img src="./sakura-pi-pocket-namiji-board-antenna.webp" alt="Sakura Pi Pocket Namiji 板卡实拍"></p><p>如果你只是想快速把节点跑起来，一丁点也不想折腾焊接和打板，可以直接去闲鱼买成品。派派的闲鱼账号是 <a href="https://www.goofish.com/personal?userId=744540236">甜城欢乐的萝卜</a>。</p><p><img src="./sakurapi-pocket-namiji-xianyu-page.webp" alt="Sakura Pi Pocket Namiji 闲鱼商品页截图"></p><p>但如果你更在意动手折腾的乐趣，那这次是真的值得关注：樱花派 Pocket Namiji 已经把各种关键资源整理得很完整了。</p><p><img src="./sakurapi-pocket-namiji-resources-page-updated.webp" alt="Sakura Pi Pocket Namiji resources 下载页截图"></p><p>这次 <a href="https://docs.sakurapi.org/article/sakurapi-pocket-namiji/resources">公开的资源</a> 包括：</p><ul><li>Meshtastic 适配固件源代码</li><li>MeshCore 适配固件源代码</li><li>BoM 物料清单</li><li>硬件原理图 PDF</li><li>芯片与 LoRa 模组数据手册</li><li>板卡 3D 模型与外壳模型（可自行 3D 打印）</li><li>预编译固件下载</li><li><a href="https://oshwhub.com/sakurapi/sakurapi-pocket-namiji">嘉立创开源广场 OSHWHub</a> 上的开源硬件资料</li></ul><p><img src="./sakura-pi-pocket-namiji-pcb-front-back-ebyte-e22-400m33s.webp" alt="Sakura Pi Pocket Namiji PCB 正反面与 Ebyte E22 模块"></p><p>项目本体还是那块熟悉的小尺寸底板：ESP32-C3 + E22 30S/33S 方案、470MHz、Type-C 供电与调试、3-16V 外部供电输入。</p><p>你可以在里面找到固件相关入口、原理图 PDF、以及 3D 模型下载信息。</p><p>对想自己做壳子的读者来说，这一点非常省事：拿到模型就能直接按自己的场景去拓竹进行 3D 打印外壳，不用再自己从零测尺寸开模。</p><p><img src="./sakura-pi-pocket-namiji-3d-print-enclosure.webp" alt="Sakura Pi Pocket Namiji 3D 打印外壳"></p><p>原理图、iBOM、芯片手册、模组手册这些东西，现在也都已经摆在同一个地方了。</p><p><img src="./sakura-pi-pocket-namiji-schematic-preview.webp" alt="Sakura Pi Pocket Namiji 原理图首页预览"></p><p>结构件这块也补得很全，板卡模型、外壳模型、预编译固件都已经放出来了。你要改外壳、做支架、核对孔位，或者只是想先把固件刷起来试试，现在都比一月那会儿顺手得多。</p><p>如果你更习惯先看页面再决定要不要动手，那也可以先翻一眼 GitHub 和 <a href="https://oshwhub.com/sakurapi/sakurapi-pocket-namiji">嘉立创开源广场 OSHWHub</a> 这两个入口。</p><p><img src="./sakurapi-pocket-namiji-github-repository-page-screenshot.webp" alt="Sakura Pi Pocket Namiji GitHub 仓库页面截图"></p><p><img src="./sakurapi-pocket-namiji-oshwhub-project-page-screenshot.webp" alt="Sakura Pi Pocket Namiji OSHWHub 项目页截图"></p><p>另外，这块板子现在两边都能玩。你本来就在用 Meshtastic，那就继续走 Meshtastic；如果你最近在看 MeshCore，也可以顺手试过去。对同一块硬件来说，这一点还是挺省事的。</p><p>Namiji 之前被大家关注，一个关键点就是 ESP32-C3 方案下的功耗表现。派派不是简单靠关蓝牙来降电流，而是用 dcdc 降压路线把功耗压下去，同时尽量保留手机侧使用体验。这个思路现在放在开源语境下更有意义，因为你可以拿着现成资料对照看：到底哪些是硬件路径，哪些是固件路径，后续做二次开发时也更容易定位问题。</p><p><img src="./esp32c3-lower-power-consumption-data-screenshot.webp" alt="esp32c3 + E22 低功耗实测截图"></p><p>对想做太阳能节点、固定中继节点的人来说，低功耗不是锦上添花，而是决定维护频率和长期稳定性的核心指标。现在这部分也有公开参考材料，门槛比之前低了不少。</p><p><img src="./sakura-pi-pocket-namiji-24pcs-pcba-stack.webp" alt="Sakura Pi Pocket Namiji 成品板堆叠"></p><p>你如果已经按这套资料复刻了板子，或者把 3D 外壳打印并装起来了，欢迎把实装过程和踩坑点分享出来到 <a href="/contact/">MeshCN 微信群或者 QQ 群里</a>。</p>]]></content>
    
    
    <summary type="html">2026-02-05 起，樱花派 Pocket Namiji 已正式开源。现在不仅能在 GitHub README 拿到固件、原理图 PDF 和 3D 外壳模型，这块板子也已经同时支持 Meshtastic 与 MeshCore。想直接上手可买成品，想自己折腾也有完整资源可走。</summary>
    
    
    
    <category term="产品" scheme="https://meshcn.net/categories/%E4%BA%A7%E5%93%81/"/>
    
    
    <category term="Meshtastic" scheme="https://meshcn.net/tags/Meshtastic/"/>
    
    <category term="ESP32" scheme="https://meshcn.net/tags/ESP32/"/>
    
    <category term="MeshCore" scheme="https://meshcn.net/tags/MeshCore/"/>
    
    <category term="开源硬件" scheme="https://meshcn.net/tags/%E5%BC%80%E6%BA%90%E7%A1%AC%E4%BB%B6/"/>
    
    <category term="SakuraPi" scheme="https://meshcn.net/tags/SakuraPi/"/>
    
  </entry>
  
  <entry>
    <title>MeshMonitor 中的自动化功能</title>
    <link href="https://meshcn.net/meshmonitor-automation-features/"/>
    <id>https://meshcn.net/meshmonitor-automation-features/</id>
    <published>2026-02-26T12:36:53.000Z</published>
    <updated>2026-02-26T12:36:53.000Z</updated>
    
    <content type="html"><![CDATA[<blockquote><p>投稿来自 <a href="/contact">MeshCN 社区微信群组</a> 群友 <em>jinsu</em>。感谢他的耐心整理和分享。<br>这篇文章的原文发布在 jinsu 的个人博客，感兴趣的读者可以前往查看：<a href="https://jinsu2000.github.io/2026/02/20/MeshMonitor%E4%B8%AD%E7%9A%84%E8%87%AA%E5%8A%A8%E5%8C%96%E5%8A%9F%E8%83%BD/">《MeshMonitor 中的自动化功能》</a>。</p></blockquote><p>很多人第一次打开 MeshMonitor 的自动化页面，都会有同一个感受：功能很多，但不知道先开哪几个才真的有用。结果要么全关着当摆设，要么一股脑全开，最后把频道刷屏到自己都受不了。</p><p>这篇把 <code>v3.6.3</code> 里和自动化相关的能力讲明白。MeshMonitor 迭代很快，具体选项名和行为可能会变化，所以建议你把这里当作思路框架，再结合 <a href="https://meshmonitor.org/">MeshMonitor 官网</a> 的当前说明核对。</p><p>如果你还没搭过环境，建议先看我们 MeshCN 的另一篇文章《<a href="/meshmonitor-docker-tutorial/">给 Meshtastic 一块「监控大屏」：用 MeshMonitor 把整张网一眼看穿</a>》，先把部署和基础界面跑通，再回来开自动化会更顺。</p><h2 id="1-自动确认-Auto-Acknowledge">1. 自动确认 (Auto Acknowledge)</h2><p><strong>用途：</strong> 自动确认功能能够自动回复匹配特定模式的消息，这不仅可用于确认消息的接收，还能根据预设模板提供详细的响应信息，增强网络通信的互动性。</p><p><strong>使用方法：</strong></p><ul><li>配置消息模式：利用正则表达式定义哪些消息应触发自动确认，确保只有符合特定条件的消息才会收到自动回复。不会写正则表达式的话可以使用ai。</li><li>自定义消息模板：支持使用动态令牌（如{HOPS}表示跳数、{SNR}表示信噪比等）来构建复杂的响应模板，使回复内容更加丰富和个性化。</li><li>通道与消息类型选择：可精确控制哪些通道和消息类型（如直接消息、频道消息）触发自动确认，避免不必要的回复。</li><li>响应模式：支持纯文本回复和表情符号反应两种模式，用户可根据需要单独或同时启用，增加互动性。</li></ul><h2 id="2-自动路由追踪-Auto-Traceroute">2. 自动路由追踪 (Auto Traceroute)</h2><p><strong>用途：</strong> 此功能通过定期向所有活跃节点发送路由追踪请求，帮助管理员维护最新的网络拓扑信息，从而更有效地监控和管理网络状态。</p><p><strong>使用方法：</strong></p><ul><li>追踪间隔设置：根据网络规模和需求，调整发送追踪请求的时间间隔（1-60分钟），以平衡网络负载和信息更新频率。</li><li>节点过滤：支持选择特定节点进行追踪，减少在大型网络中不必要的开销，提高追踪效率。</li><li>有线安排更接近的节点：跳数较少的节点将首先进行跟踪路由，推荐启用</li><li>时间窗口限制：支持在指定时间窗口内运行自动跟踪路由，推荐启用，设置在网络不繁忙的时间段</li></ul><h2 id="3-自动Ping-Auto-Ping">3. 自动Ping (Auto Ping)</h2><p><strong>用途：</strong> 自动Ping功能允许mesh用户通过发送直接消息命令来触发自动ping会话，用于测试链路质量、测量往返时间以及验证与MeshMonitor节点的连接性。</p><p><strong>使用方法：</strong></p><ul><li>配置参数：设置ping的间隔时间、每会话的最大ping数以及超时时间，以满足不同测试场景的需求。</li><li>DM命令操作：用户通过发送ping N命令启动N个ping的会话，并使用ping stop命令随时取消会话，操作简便快捷。</li></ul><h2 id="4-远程管理扫描器-Remote-Admin-Scanner">4. 远程管理扫描器 (Remote Admin Scanner)</h2><p><strong>用途：</strong> 该功能自动扫描mesh网络中具有远程管理能力的节点，帮助管理员快速识别并管理这些关键节点。</p><p><strong>使用方法：</strong></p><ul><li>扫描间隔设置：根据网络变化频率调整扫描间隔时间，确保及时发现新启用的远程管理节点。</li><li>结果管理：查看扫描结果，了解哪些节点支持远程管理，并据此进行进一步的配置和管理。</li></ul><h2 id="5-自动时间同步-Auto-Time-Sync">5. 自动时间同步 (Auto Time Sync)</h2><p><strong>用途：</strong> 自动时间同步功能确保mesh网络中所有支持远程管理的节点时间一致，对于需要精确时间戳的应用场景尤为重要。</p><p><strong>使用方法：</strong></p><ul><li>同步间隔设置：根据网络规模和节点数量调整同步间隔时间，确保时间同步的准确性和效率。</li><li>节点选择：可选择特定节点进行时间同步，减少不必要的同步操作，提高网络性能。</li></ul><h2 id="6-自动欢迎-Auto-Welcome">6. 自动欢迎 (Auto Welcome)</h2><p><strong>用途：</strong> 当新节点加入mesh网络时，自动发送个性化的欢迎消息，增强新成员的归属感和网络活跃度。</p><p><strong>使用方法：</strong></p><ul><li>欢迎频道选择：选择监控新节点的频道，确保欢迎消息能够准确送达。</li><li>自定义欢迎消息：使用动态令牌构建欢迎消息模板，使欢迎消息更加个性化和友好。</li></ul><h2 id="7-自动公告-Auto-Announce">7. 自动公告 (Auto Announce)</h2><p><strong>用途：</strong> 定期向选定频道广播公告消息，用于分享网络状态、重要通知或任何需要网络成员知晓的信息。</p><p><strong>使用方法：</strong></p><ul><li>公告间隔设置：设置广播公告的时间间隔或使用cron表达式进行精确调度，以满足不同场景下的公告需求。</li><li>广播频道与消息内容：选择发送公告的频道，并构建包含动态令牌的公告消息，使公告内容更加丰富和实用。</li></ul><h2 id="8-自动响应器-Auto-Responder">8. 自动响应器 (Auto Responder)</h2><p><strong>用途：</strong> 根据自定义触发模式自动回复消息或发起HTTP请求，实现高度灵活的自动化响应机制，支持各种复杂的交互场景。</p><p><strong>使用方法：</strong></p><ul><li>创建触发器：定义匹配的消息格式作为触发器，支持使用正则表达式进行精确匹配。</li><li>配置响应：选择文本回复或HTTP请求作为响应方式，并构建相应的响应内容或URL。</li><li>脚本响应：对于更复杂的逻辑，支持执行自定义脚本以实现高度灵活的响应机制。</li></ul><h2 id="9-定时事件-Timer-Triggers">9. 定时事件 (Timer Triggers)</h2><p><strong>用途：</strong> 使用cron表达式安排脚本在指定时间自动运行，实现周期性任务调度，如发送每日状态报告、执行定期维护等。</p><p><strong>使用方法：</strong></p><ul><li>设置cron表达式：使用标准5字段cron语法定义脚本的执行时间，确保任务在正确的时间触发。</li><li>选择脚本与频道：指定要执行的脚本路径和输出频道，确保脚本的执行结果能够送达指定位置。</li></ul><h2 id="10-地理围栏触发器-Geofence-Triggers">10. 地理围栏触发器 (Geofence Triggers)</h2><p><strong>用途：</strong> 当地理围栏内定义的节点进入、离开或停留在特定区域时触发自动化操作，如发送通知、调整节点配置等，增强网络对地理位置的感知能力。</p><p><strong>使用方法：</strong></p><ul><li>添加地理围栏触发器：在自动化设置中的&quot;Geofence Triggers&quot;部分添加新触发器，并定义触发器的名称、形状（圆形或多边形）和触发事件。</li><li>配置监控节点：选择要监控的节点，确保只有符合条件的节点才能触发地理围栏事件。</li><li>设置响应类型：选择文本消息或脚本作为响应方式，并构建相应的响应内容或脚本逻辑。</li></ul><h2 id="11-自动密钥管理-Auto-Key-Management">11. 自动密钥管理 (Auto Key Management)</h2><p><strong>用途：</strong> 自动检测并修复mesh网络中节点之间的PKI密钥不匹配问题，确保加密通信的顺畅进行，提高网络安全性。</p><p><strong>使用方法：</strong></p><ul><li>配置参数：设置尝试交换节点信息的间隔时间、最大交换尝试次数以及自动清除失效节点的选项，以优化密钥管理过程。</li><li>监控活动日志：查看实时活动日志，了解密钥修复活动的进展和结果，及时发现并解决问题。</li></ul><h2 id="12-忽略节点-Ignored-Nodes">12. 忽略节点 (Ignored Nodes)</h2><p><strong>用途：</strong> 管理要排除在mesh监控之外的节点列表，这些节点将被隐藏且即使在被清理后重新出现也会保持被忽略状态，减少不必要的监控负担。</p><p><strong>使用方法：</strong></p><ul><li>添加忽略节点：在节点列表中选择要忽略的节点，并将其添加到忽略列表中。</li></ul><p>最后，推荐关注 <em>深圳南山-jinsu</em> 的个人博客 <a href="https://jinsu2000.github.io/">jinsu2000.github.io</a>。除了这篇文章外，他在 MeshCN 已经持续写了很多篇 Meshtastic 实战文章，帮不少群友少走弯路；想看他在社区的系列投稿，也可以直接点这里：<a href="/search/?s=jinsu">jinsu 在 MeshCN 的文章合集</a>。</p>]]></content>
    
    
    <summary type="html">这篇文章基于 MeshMonitor v3.6.3，把常用自动化能力讲清楚，帮你少走弯路。</summary>
    
    
    
    <category term="教程" scheme="https://meshcn.net/categories/%E6%95%99%E7%A8%8B/"/>
    
    
    <category term="MeshMonitor" scheme="https://meshcn.net/tags/MeshMonitor/"/>
    
  </entry>
  
  <entry>
    <title>iOS 终于不绕路：Meshtastic 内置 TAK Server，上 iTAK / TAK Aware</title>
    <link href="https://meshcn.net/tak-server-integration-ios/"/>
    <id>https://meshcn.net/tak-server-integration-ios/</id>
    <published>2026-02-26T02:01:00.000Z</published>
    <updated>2026-02-26T02:01:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>Meshtastic iOS App 最近上线了一个很关键的新能力：TAK Server integration。它把两个原本很强、但过去在 iOS 上不容易打通的生态接在了一起：Meshtastic 的长距离离网 mesh 通信，以及 TAK 家族在苹果端的 iTAK、TAK Aware。</p><blockquote><p>以下内容翻译自 Meshtastic 官方博客《No Plugins, No Problem: Integrating TAK, Meshtastic, and iOS》，作者为 TheBentern（Device Firmware Development Lead）与 Nick（ATAK Plugin Architect），发布于 2026 年 2 月 17 日。有兴趣的读者可以阅读 <a href="https://meshtastic.org/blog/tak-server-integration-ios/">英文原文</a>。</p></blockquote><blockquote class="blockquote-note blockquote-note__warning"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="12" height="16" viewBox="0 0 12 16"><path fill-rule="evenodd" d="M5.05.31c.81 2.17.41 3.38-.52 4.31C3.55 5.67 1.98 6.45.9 7.98c-1.45 2.05-1.7 6.53 3.53 7.7-2.2-1.16-2.67-4.52-.3-6.61-.61 2.03.53 3.33 1.94 2.86 1.39-.47 2.3.53 2.27 1.67-.02.78-.31 1.44-1.13 1.81 3.42-.59 4.78-3.42 4.78-5.56 0-2.84-2.53-3.22-1.25-5.61-1.52.13-2.03 1.13-1.89 2.75.09 1.08-1.02 1.8-1.86 1.33-.67-.41-.66-1.19-.06-1.78C8.18 5.31 8.68 2.45 5.05.32L5.03.3l.02.01z"></path></svg></div>合规使用提醒</div><div class="blockquote-note__content"><p>TAK 来源于外国相关机构开发，不建议在中国大陆使用，以免触犯相关法律法规。在任何地方使用前，请务必了解并遵守当地的相关法律法规。文明组网，合规使用。</p></div></blockquote><h2 id="TAK-是什么？">TAK 是什么？</h2><p>TAK（Team Awareness Kit）可以理解成一套「以地图为中心的协同作业系统」，而不只是单一 App。</p><p><img src="./tak-logo-map-background-original.webp" alt="TAK 标识与地图背景示意"></p><p>按照 <a href="https://tak.gov/products">TAK 官方产品线</a>，它覆盖了 Android 端 ATAK、Windows 端 WinTAK、iOS 端 iTAK，以及 Web 端 WebTAK，并由 TAK Server 在需要时承接更大规模的数据管理与分发。</p><p>也就是说，TAK 更像一个跨终端协同生态，而不是某个设备上的独立软件。</p><p>它最关键的价值，是把「人、位置、事件、消息」放到同一张动态地图里。实际任务里常见的元素，比如队员位置（PLI/Blue Force Tracking）、标记点、注释、文本聊天，以及图片/视频等，都可以围绕地图持续同步。</p><p><img src="./tak-operations-center-multi-screen-map-original.webp" alt="TAK 多屏态势协同示意"></p><p>对搜救、应急、安保巡检这类场景来说，TAK 的意义通常不是替代通信链路本身，而是把现场信息组织成一张可共享、可追踪、可协同决策的态势图。</p><p>这些数据在底层主要通过 CoT（Cursor on Target）事件格式交换。你可以把 CoT 理解成 TAK 生态里的「通用数据语言」：只要系统能正确生成和解析 CoT，跨端协同就会更顺畅。</p><p><em>第 31 海军陆战队远征队海上突击队（Maritime Raid Force）的一名无线电操作员，在一次 VBSS（临检登船搜查与扣押）任务中，使用了装在 Juggernaut 保护壳内的 Android 战术突击套件（ATAK）设备。（美国海军陆战队照片，摄影：下士 Brandon Salas）</em><br><img src="./tak-field-operator-mobile-map-original.webp" alt="TAK 野外移动终端使用场景"></p><p>我们在另一篇《<a href="/meshtastic-atak-tutorial/">ATAK 插件打通 Meshtastic 指南</a>》里提到的插件桥接，本质上也是在做 CoT 事件与 LoRa mesh 数据之间的转换与转发。</p><p>在 iOS 设备上，最常见的 TAK 客户端是 iTAK 和 TAK Aware。它们提供了 ATAK 一部分核心能力，让 iPhone 和 iPad 也能参与协同。</p><p><img src="./itak-spotted-map-syzygy-integration-original.webp" alt="iTAK 地图与点位集成界面"></p><h2 id="为什么-TAK-要配-Meshtastic？">为什么 TAK 要配 Meshtastic？</h2><p>传统 TAK 更依赖网络连接或专用服务器。</p><p>但真实任务里，总会遇到没有蜂窝信号、基础设施受损、或地理上超出常规覆盖的场景。</p><p>Meshtastic 的价值就在这里，它可以通过 LoRa mesh 在无基础设施条件下继续转发信息，把消息一跳一跳送到目标节点。</p><h2 id="难点：Android-很顺，iOS-一直受限">难点：Android 很顺，iOS 一直受限</h2><p>在 Android 上，Meshtastic 和 ATAK 已经能通过插件架构直接集成，很多用户也用了多年。</p><p>如果你是安卓用户，或者想先了解经典插件方案，可以先看我们之前的实操教程 《<a href="/meshtastic-atak-tutorial/">军迷狂喜：ATAK 插件打通 Meshtastic 指南</a>》。</p><p>iOS 的问题是系统沙盒和应用隔离机制更严格，无法像 Android 那样直接加载外部插件，这也让 iOS 用户长期缺少一条可行的 TAK 集成路径。</p><p><img src="./itak-user.png" alt="iOS 不能像 Android 一样直接加插件"></p><h2 id="解决方案：把-TAK-Server-直接做进-Meshtastic-iOS-App">解决方案：把 TAK Server 直接做进 Meshtastic iOS App</h2><p>这次的做法很直接：在 Meshtastic iOS App 内部直接实现一个本地 TAK Server 端点。</p><p>开启该功能后，iTAK 和 TAK Aware 可以像连接普通云端 TAK 服务器一样，连接到你手机上的本地端点，用户侧不需要额外折腾特殊旁路方案。</p><p>在底层，Meshtastic iOS 负责把 TAK 的 CoT XML 与 Meshtastic 的线传优化数据包做双向转换。对用户来说，这个过程基本是透明的，TAK 客户端连接后就能正常工作。</p><p><img src="./tak-ios-data-flow.png" alt="TAK 与 Meshtastic iOS 数据流示意图"></p><h2 id="这次集成能做什么？">这次集成能做什么？</h2><h3 id="位置共享（PLI）">位置共享（PLI）</h3><p>在 TAK 里的位置会自动广播到 mesh 网络。</p><p>无论对端是 Android 上的 ATAK，还是另一台 iOS 的 TAK 客户端，都可以在地图上实时看到位置更新，不依赖蜂窝网络。</p><h3 id="GeoChat-文本通信">GeoChat 文本通信</h3><p>团队可以通过 mesh 直接收发 GeoChat 消息。</p><p>无论是搜救分区协调，还是和营地进行状态同步，消息链路都可以通过 Meshtastic 完成。</p><p><img src="./tak-geochat-example.webp" alt="TAK 集成中的 GeoChat 消息示例"></p><h3 id="标记与兴趣点（POI）">标记与兴趣点（POI）</h3><p>你在 iTAK 或 TAK Aware 上投放的标记点，例如风险点、集合点、发现物位置，也会自动同步到 mesh 内其他已连接的 TAK 客户端。</p><p><img src="./tak-aware-woods.webp" alt="TAK Aware 中的 Meshtastic 集成显示"></p><h2 id="上手前先看两件事：带宽与加密">上手前先看两件事：带宽与加密</h2><p>官方特别提醒，这套 TAK 集成产生的流量会高于普通 Meshtastic 使用。</p><p>为了更稳，建议优先选择更高带宽的 LoRa 预设，例如 <code>Short Fast</code> 或 <code>Short Turbo</code>。</p><p>另外，TAK 数据会通过主信道广播，实战部署请确保主信道是私有信道且已开启加密。</p><h2 id="快速开始">快速开始</h2><p>如果你想先看一遍操作路径，可以先看这个简短演示视频，再按下面步骤逐项配置。</p><p><video src="./start-tak-server.mp4" controls="controls" width="100%" height="100%"></video></p><ol><li>使用 <a href="https://flasher.meshtastic.org/">Web Flasher</a> 把节点固件更新到最新版本。</li><li>在 App Store 更新到最新版 <a href="https://msh.to/ios">Meshtastic iOS App</a>。</li><li>先配置好主信道，确保节点通过它与 mesh 网络通信。</li><li>在 LoRa 配置中选择更高带宽预设（推荐 <code>Short Fast</code> 或 <code>Short Turbo</code>）。</li><li>在 App 里进入 <code>Settings</code>，滚动到底部 <code>TAK Server</code>，完成 TAK 设置并启动服务。</li><li>在 Meshtastic App 下载 Data Package，导入到 iTAK 或 TAK Aware，让客户端连接本机 TAK 端点。</li><li>完成后即可在离网环境下使用完整态势协同能力。</li></ol><h2 id="接下来会有什么？">接下来会有什么？</h2><p>Meshtastic 团队表示，这还只是第一步。</p><p>后续正在推进第二代原生 TAK 协议层，目标是进一步增强集成深度和线传优化效率。</p><p>对 iOS 用户来说，这次更新已经把过去最难的一环补上了，后面值得持续关注。</p>]]></content>
    
    
    <summary type="html">Meshtastic iOS App 新增 TAK Server 集成：iTAK 与 TAK Aware 现在可以直接接入本机端点，不再受 iOS 插件限制。离网场景下，你可以继续做位置共享、GeoChat 和兴趣点标注。</summary>
    
    
    
    <category term="教程" scheme="https://meshcn.net/categories/%E6%95%99%E7%A8%8B/"/>
    
    
    <category term="iOS" scheme="https://meshcn.net/tags/iOS/"/>
    
    <category term="TAK" scheme="https://meshcn.net/tags/TAK/"/>
    
    <category term="ATAK" scheme="https://meshcn.net/tags/ATAK/"/>
    
  </entry>
  
  <entry>
    <title>【公告】杭州-朱哲完成 MESS.HOST MQTT 服务器升级</title>
    <link href="https://meshcn.net/announcement-messhost-mqtt-server-upgrade-2026/"/>
    <id>https://meshcn.net/announcement-messhost-mqtt-server-upgrade-2026/</id>
    <published>2026-02-23T06:53:00.000Z</published>
    <updated>2026-02-23T06:53:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>这是一篇简短公告，也是一篇感谢帖。</p><p>过去很长一段时间，国内群友做 MQTT 互联时，基本都绕不开 <em>杭州-朱哲</em> 维护的中国境内 MQTT 服务器，至少九成群友都用过 <code>mqtt.mess.host</code>。朱哲大佬之前写的《<a href="/how-to-connect-to-messhost-third-party-china-mqtt-server/">连接 MQTT 服务器掉线？快试国内的第三方 Meshtastic MQTT 服务器</a>》也一直是很多新朋友进群后的必读文之一。MeshCN <a href="/tags/%E7%AD%BE%E5%88%B0/">每周五晚上八点的签到活动</a>，也是在朱哲大佬的 MQTT 服务器上举行。</p><p>这次农历新年假期里，朱哲把 MQTT 服务做了一轮升级：</p><ol><li>MQTT Broker 从之前的 Mosquitto 切换到了 EMQX。</li><li>服务器配置从 1 核 2G 升级到 2 核 2G，带宽也从过去大约 1-2 Mbps 提升到约 4-6 Mbps。</li><li>新的套餐带有每月 300G 流量上限，不过按 MQTT 这类消息负载的特点，正常使用下对流量和带宽的压力都不算大。</li></ol><p>接下来一段时间，流量会逐步切到新 MQTT 服务器上。如果你已经在用 MESS.HOST，通常不需要额外改动配置；如果切换期间遇到偶发连接异常，直接在 <a href="https://meshcn.net/contact">MeshCN 微信交流群</a> 里反馈即可，我们会一起跟进。</p><p>另外，朱哲也提到后续会评估加入黑名单能力，用来处理少数滥用服务的情况，尽量把公共资源留给正常通信的群友。</p><p>再次感谢朱哲长期维护这套基础设施。很多人每天在频道里那句看似普通的问候「咕咕嘎嘎」，背后其实都离不开这些群友默默的投入。</p>]]></content>
    
    
    <summary type="html">农历新年假期期间，杭州-朱哲完成了 MESS.HOST MQTT 服务升级：Broker 从 Mosquitto 切到 EMQX，服务器从 1 核 2G 升到 2 核 2G，带宽也有明显提升。</summary>
    
    
    
    <category term="公告" scheme="https://meshcn.net/categories/%E5%85%AC%E5%91%8A/"/>
    
    
    <category term="MQTT" scheme="https://meshcn.net/tags/MQTT/"/>
    
  </entry>
  
  <entry>
    <title>从「能打字」到「好打字」：WhisperOS 把 MeshCore 手持设备的输入体验往前推了一步</title>
    <link href="https://meshcn.net/whisperos-intro-for-meshcn-users/"/>
    <id>https://meshcn.net/whisperos-intro-for-meshcn-users/</id>
    <published>2026-02-21T16:40:00.000Z</published>
    <updated>2026-02-21T16:40:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>如果你一直在看 MeshCN 近几个月的文章，应该会对 <em>上海-农药</em> 这个名字不陌生。2025 年 9 月，我们写过 《<a href="/meshtastic-cjk-display-breakthrough">再见乱码，欢迎汉字：Meshtastic 的 CJK 中文字符适配来了</a>》，当时聊的是 <em>农药</em> 大佬把 CJK 显示适配带到设备端；到了 2025 年 11 月，《<a href="/predictive-pinyin-input-experience">用摇杆也能「飞快打字」：MeshCore 新联想输入上手小记</a>》 又把焦点放在联想输入，解决了小屏设备能打字但很痛苦的老问题。</p><p><em>设备实拍：Seeed Studio Wio Tracker L1 Pro</em><br><img src="./meshtastic-predictive-input-cn-en-side-by-side.webp" alt="WhisperOS 中英文预测输入界面对比"></p><p>这两篇内容连起来看，其实已经能看出一个很清晰的方向: <em>农药</em> 不是在做单点功能，而是持续把手持设备上的文字输入交互体验一步一步往前推。WhisperOS 则是这条演化线进一步系统化后的结果。</p><p>WhisperOS 建立在 MeshCore 通讯底层之上，把日常使用的细节做了针对性改进，尤其是中文和多语言输入、手持设备上的交互效率，以及一些更贴近本地用户习惯的功能细节，尽量把小屏加按键或摇杆这套交互做得更顺手。</p><p><em>设备实拍：武汉-Wilson 的 <a href="https://meshtiny.com/">Meshtiny</a></em><br><img src="./whisperos-device-meshtiny-rf-screen-desktop-standing.webp" alt="WhisperOS 设备实拍 Meshtiny 手持小设备"></p><p>从产品模式看，它目前是免费基础功能加付费进阶功能的路线。在 FAQ 也能看到作者直言 WhisperOS 是一个私有的商业项目，并非开源项目。如果你关心的是没付费能不能用，答案是: 基础固件免费，已经够大多数用户日常使用。</p><p>设备支持范围覆盖以下常见手持机型：</p><ul><li>FoBE Quill</li><li>GAT562</li><li>Heltec T114</li><li>Heltec V3/V4</li><li>MeshTiny</li><li>ProMicro</li><li>RAK4631</li><li>Wio Tracker L1</li></ul><p><em>设备实拍：Seeed Studio Wio Tracker L1 Pro。拍摄：中山-dove</em><br><img src="./whisperos-device-wio-tracker-l1-pro-rf-screen-angle-shot.webp" alt="WhisperOS 设备实拍 Wio Tracker L1 Pro 斜侧视角"><br><img src="./whisperos-device-wio-tracker-l1-pro-rf-screen-handheld-closeup.webp" alt="WhisperOS 设备实拍 Wio Tracker L1 Pro 手持近景"></p><p>对已经在玩 Meshtastic 或者 MeshCore 的群友来说，你几乎有八成概率已经拥有其中至少一款设备。</p><p>从实际界面看，WhisperOS 在小屏设备上的信息密度和可读性是它的一大特点。下面这几张 UI 截图可以直观看到首页状态、英文预测输入和射频页面的展示方式。</p><p><img src="./whisperos-ui-radio-screen-green-theme.png" alt="WhisperOS 射频界面绿色主题"></p><h2 id="Whisper-OS-Premium-9-90-美元买到的是什么">Whisper OS Premium: 9.90 美元买到的是什么</h2><p>仅仅是 2026 年前 30 天，已经有四个新版本推出了。这其中既有免费版的功能增强，也有 Premium 版的新功能。</p><pre class="mermaid">%%{init: {"theme":"neutral","themeVariables":{  "primaryColor":"#ffffff",  "primaryTextColor":"#000000",  "primaryBorderColor":"#000000",  "lineColor":"#000000",  "secondaryColor":"#ffffff",  "tertiaryColor":"#ffffff"}}}%%timeline    title WhisperOS 固件更新日志    section 1 月 9 日        v1.2.3 : 全用户开放 虚拟键盘输入               : 伴侣应用可自定义 快捷回复（最多 15 条） 每条最多 31 字符               : 新增安静模式 可关闭通知音 和 LED 提醒    section 1 月 12 日        v1.2.4 : BLE 设备名限制为 字母 / 数字 / 连字符               : 预设消息长度提升到 每条最多 63 字符               : 快捷消息支持 非英文语言               : 菜单元素加入 细微圆角 界面更清爽    section 1 月 14 日        v1.2.5 : 新增摩斯电码输入 含声音反馈 适合按键较少设备               : 消息界面支持 更大字号 提升可读性               : 扩展语言支持    section 2 月 1 日        v1.3.0.beta : 修复节点名称 在界面重叠                    : 修复消息数量 在消息页重叠                    : 升级到最新 MeshCore 库                    : Heltec v3 / v4 续航提升约 20%                    : 新增设备支持 PICO C3 M5Stack Cardputer ADV （含实体键盘）                    : 新增 Zen 模式 关闭屏幕 仅点击唤醒                    : 频道静音功能（开发中） 可静音指定频道                    : 优化 T114 的 GPS 功能                    : 联系人自动淘汰（开发中） 联系人满 350 时 自动删除最旧非收藏                    : 子菜单导航时 抑制弹窗 减少干扰                    : 新增 GPS 坐标 匿名化选项                    : 新增实时 噪声底查看                    : Radio 与 GPS 页面 布局和视觉优化</pre><p><img src="./whisperos-ui-home-messages-ble-status.png" alt="WhisperOS 首页消息与 BLE 状态界面"><br><img src="./whisperos-ui-predictive-keyboard-english.png" alt="WhisperOS 英文预测输入界面"><br><img src="./whisperos-ui-radio-status-cn470-495_2mhz.png" alt="WhisperOS 射频状态界面 CN470 495.2MHz"></p><p>Whisper OS Premium 价格为 9 块 9 美刀。付费后，会得到以下四种功能:</p><ol><li>智能输入套件（英文/中文预测、拼音词组建议、CJK 虚拟键盘、联想补全）</li><li>高级省电（典型场景 72+ 小时，含空闲检测与快速唤醒）</li><li>摩斯密码输入</li><li>GPS 隐私控制</li></ol><p>这些能力有设备适配差异，比如省电增强重点是本身电老虎的 Heltec V3/V4，输入套件则重点覆盖 Wio Tracker L1、GAT562 变种和 Meshtiny。</p><p>如果你主要用基础消息收发、偶尔配置参数，免费版完全够用了；如果你长期依赖设备本身来进行打字，或者要长续航抑或是拼音智能联想的能力，那升级到 Premium 会更合适。</p><h2 id="如何烧录-WhisperOS">如何烧录 WhisperOS</h2><p>线刷前先做一件事: 备份设备配置。刷入新固件后，配置有概率被重置；如果勾选擦除设备，设备内已有数据会被清空，包含设备身份信息。</p><p>官方线刷入口是 <a href="https://ssaprus.works/flasher">WhisperOS 官网烧录器页面</a>。这个页面同时支持 ESP32 和 nRF52。</p><blockquote class="blockquote-note blockquote-note__warning"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="12" height="16" viewBox="0 0 12 16"><path fill-rule="evenodd" d="M5.05.31c.81 2.17.41 3.38-.52 4.31C3.55 5.67 1.98 6.45.9 7.98c-1.45 2.05-1.7 6.53 3.53 7.7-2.2-1.16-2.67-4.52-.3-6.61-.61 2.03.53 3.33 1.94 2.86 1.39-.47 2.3.53 2.27 1.67-.02.78-.31 1.44-1.13 1.81 3.42-.59 4.78-3.42 4.78-5.56 0-2.84-2.53-3.22-1.25-5.61-1.52.13-2.03 1.13-1.89 2.75.09 1.08-1.02 1.8-1.86 1.33-.67-.41-.66-1.19-.06-1.78C8.18 5.31 8.68 2.45 5.05.32L5.03.3l.02.01z"></path></svg></div>大陆访问提示</div><div class="blockquote-note__content"><p>根据群友反馈，并和 WhisperOS 作者确认（截至 2026 年 3 月 3 日），官网已在 Cloudflare 侧开启对中国大陆 IP 的访问限制。因此在大陆网络下访问官网、烧录页面或 Premium 固件购买入口时，可能会看到 Cloudflare 的禁止访问提示。</p><p>如果你需要访问烧录页面或付费高级版固件入口，可以先“走路”到其他地区 IP（例如香港 IP），通常就能正常访问。</p></div></blockquote><h3 id="蓝牙-OTA-无线烧录">蓝牙 OTA 无线烧录</h3><p>相比拿个数据线插入电脑进行线刷，很多群友更喜欢用蓝牙 OTA 进行固件更新。这种方法的好处是整个更新过程都是无线的。</p><p>而要使用蓝牙 OTA，最方便的方法是下载 <em>武汉-Wilson</em> 专门开发给 Meshtastic、MeshCore、WhisperOS 的蓝牙 OTA 应用 MTools BLE。</p><p>MTools BLE 下载方式：</p><ul><li>iOS 用户：<a href="https://apps.apple.com/us/app/mtools-ble/id1531345398?l=zh-Hans-CN">App Store 里下载 <code>MTools BLE</code> 应用</a></li><li>Android 用户：<a href="https://play.google.com/store/apps/details?id=com.mtoolstec.mtoolsLite&amp;hl=zh-CN">Google Play 里下载 <code>MTools BLE</code> 应用</a></li></ul><p><img src="./whisperos-mtools-ble-ota-firmware-repository-screenshot.webp" alt="MTools BLE 中的 WhisperOS 固件仓库页面"></p><p>蓝牙 OTA 的功能仅限于 nRF52 作为 MCU 的设备，如 <a href="https://meshtiny.com/">Meshtiny</a>、<a href="/GAT-IOT-handheld-review">GAT562</a>、<a href="https://www.seeedstudio.com/Wio-Tracker-L1-Pro-p-6454.html">Seeed Studio Wio Tracker L1</a> 等。</p><p>如果用的是 ESP32 作为 MCU 的设备，则只能线刷，需要使用 WhisperOS 的官方烧录页面 flasher 进行烧录。</p><h3 id="线刷（USB-数据线烧录）">线刷（USB 数据线烧录）</h3><p>开始前，请准备：</p><ol><li>稳定的数据线，避免只充电不传输的数据线。</li><li>刷机期间不要断开设备，不要让电脑休眠。</li><li>确认设备 MCU 类型，是 ESP32 还是 nRF52。</li></ol><p><img src="./whisperos-flasher-nrf52-firmware-select-dfu-flash.webp" alt="WhisperOS nRF52 线刷页面 固件选择与 DFU 入口"></p><h4 id="ESP32-线刷步骤">ESP32 线刷步骤</h4><ol><li>打开 flasher 页面并选择固件版本。</li><li>设备类型选择 ESP32。</li><li>首次刷机使用 merged 固件文件，后续升级可不使用 merged。</li><li>首次刷机建议勾选 Erase device（清除设备数据），清理旧数据后再写入。</li><li>点击 Flash Device（烧录设备），并在浏览器中授权串口访问。</li><li>等待烧录完成，中途不要断开线缆。</li><li>烧录结束后按设备 RST 按键重启进入新固件。</li></ol><h4 id="nRF52-线刷步骤">nRF52 线刷步骤</h4><p>对于 nRF52，首刷和后续升级要分开看。首刷前必须先擦除设备，再刷目标固件。</p><ol><li>首次刷机先刷擦除包。</li><li>大多数 nRF52 设备刷 <code>FLASH_ERASE_nrf52_softdevice_v6.zip</code>。</li><li>Wio Seeed L1 与 Quill nRF52840 Mesh 刷 <code>FLASH_ERASE_nrf52_softdevice_v7.zip</code>。</li><li>擦除完成后，再回到固件选择页面选择 WhisperOS 目标版本。</li><li>设备类型选择 nRF52，或手动上传对应 <code>.zip</code> 固件。</li><li>点击 Enter DFU Mode，按提示选择设备。</li><li>点击 Flash Device 开始烧录。</li><li>等待完成，中途不要断开线缆或关闭页面。</li></ol><h2 id="结语">结语</h2><p>如果你已经熟悉 Meshtastic，但又想体验另一种以 MeshCore 为底层、并且对中文输入和小屏交互更友好的系统，WhisperOS 绝对值得一试。</p><p><img src="./whisperos-ui-radio-screen-blue-theme.png" alt="WhisperOS 射频界面蓝色主题"></p><p>我建议你先刷免费版跑一段时间，把各种基础功能都摸透了，再决定是否购入 Premium。</p><h2 id="参考入口">参考入口</h2><ul><li>官网: <a href="https://ssaprus.works/">ssaprus.works</a></li><li>Haikou Web Client: <a href="https://ssaprus.works/haikou">ssaprus.works/haikou</a></li><li>FAQ: <a href="https://ssaprus.works/faq">ssaprus.works/faq</a></li><li>Changelogs: <a href="https://ssaprus.works/changelogs">ssaprus.works/changelogs</a></li><li>Whisper OS Premium: <a href="https://ko-fi.com/s/a1a5872133">ko-fi.com/s/a1a5872133</a></li><li>WhisperOS 官网烧录器页面: <a href="https://ssaprus.works/flasher">ssaprus.works/flasher</a></li><li>MTools BLE: <a href="https://ssaprus.works/mtools-ble">MTools BLE 下载页面</a></li></ul>]]></content>
    
    
    <summary type="html">如果你最近在群里频繁看到 WhisperOS，又还没完整梳理过它到底能做什么，这篇文章会给你一份清晰的功能导览：它和 MeshCore 的关系、免费版边界、Premium 进阶能力、Haikou Web Client 的定位，以及最新版本演进节奏。</summary>
    
    
    
    <category term="产品" scheme="https://meshcn.net/categories/%E4%BA%A7%E5%93%81/"/>
    
    
    <category term="MeshCore" scheme="https://meshcn.net/tags/MeshCore/"/>
    
    <category term="中文" scheme="https://meshcn.net/tags/%E4%B8%AD%E6%96%87/"/>
    
    <category term="WhisperOS" scheme="https://meshcn.net/tags/WhisperOS/"/>
    
  </entry>
  
  <entry>
    <title>把 ROUTER_LATE 讲明白：该用在哪，不该用在哪</title>
    <link href="https://meshcn.net/demystifying-router-late/"/>
    <id>https://meshcn.net/demystifying-router-late/</id>
    <published>2026-02-21T04:56:00.000Z</published>
    <updated>2026-02-21T04:56:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>自从我们之前聊过 <a href="/choosing-the-right-device-role/">如何选择合适的角色</a> 之后，Meshtastic 又新增了一个基础设施角色：<code>ROUTER_LATE</code>。这个角色名字看起来直白，但实际工作方式、适用场景和副作用，如果只看字面，很容易误判。</p><p>这篇文章最值得看的地方，不是它能不能让你自己的链路变好，而是它会如何影响整张 mesh。因为在 Meshtastic 这种单频共享、带宽极其有限的网络里，一个角色选错，影响的往往不只是你自己。</p><blockquote><p>以下内容翻译自 Meshtastic 官方博客文章《Demystifying ROUTER_LATE》。原文发布于 2025 年 9 月 25 日。英文原文链接：<a href="https://meshtastic.org/blog/demystifying-router-late/">https://meshtastic.org/blog/demystifying-router-late/</a></p></blockquote><h2 id="ROUTER-LATE-的定位到底是什么？">ROUTER_LATE 的定位到底是什么？</h2><p><code>ROUTER_LATE</code> 的设计目标，是给大型或复杂网络里的盲区做基础设施补位。典型场景是：某一簇节点被山体、峡谷、建筑群等障碍遮挡，看不到现有 <code>ROUTER</code> 站点。</p><p>它是一个强制重播角色：只要收到的数据包还没到 hop 上限，它都会重播。</p><p>但它并不是为了替代高质量骨干 <code>ROUTER</code>。更准确地说，<code>ROUTER_LATE</code> 适合放在对流量通行很关键、但覆盖面并不优秀的位置。也就是那种不够理想、但又必须补位的站点。</p><p>官方特别强调：不要把它当作家里屋顶扩展器来用。因为 <code>ROUTER_LATE</code> 会重播它能听到的几乎所有包，这会显著增加区域内空口占用。类似用法如果变多，mesh 会很快出现拥堵、碰撞和丢包，甚至直接不可用。这在慢速调制（例如 <code>LONG_FAST</code>）下更明显。</p><p>如果你的诉求只是做一个屋顶基站，应该优先考虑 <code>CLIENT_BASE</code>。</p><h2 id="重播时序：ROUTER-LATE-是怎么礼让的">重播时序：ROUTER_LATE 是怎么礼让的</h2><p>Meshtastic 的带宽限制非常严苛，因此它不会使用 OSPF、BGP 这类依赖大量控制面通信的复杂路由协议。它采用的是角色分工 + 随机延迟 + 基于信号质量的时序偏置，让数据包更可能走有效路径，同时尽量减少无谓重播。</p><p>只要一个包的剩余 hop 大于 0，它就有资格被重播；如果 hop 已经是 0，节点处理完后会直接丢弃，不再转发。</p><h3 id="三个争用窗口（Contention-Windows）">三个争用窗口（Contention Windows）</h3><p>Meshtastic 的重播发生在三个互不重叠的时间窗口中，可以理解为节点收到包之后的三段时隙：</p><table><thead><tr><th style="text-align:left">窗口</th><th style="text-align:left">时长</th><th style="text-align:left">角色</th><th style="text-align:left">说明</th></tr></thead><tbody><tr><td style="text-align:left">Early</td><td style="text-align:left">很短</td><td style="text-align:left"><code>ROUTER</code>、<code>REPEATER</code>、<code>CLIENT_BASE</code>*</td><td style="text-align:left">第一时隙。会抢占其他角色，并可能让非基础设施角色取消自己的重播。</td></tr><tr><td style="text-align:left">Default</td><td style="text-align:left">正常</td><td style="text-align:left">除 Early 角色外的大多数角色</td><td style="text-align:left">默认重播时隙。</td></tr><tr><td style="text-align:left">Late</td><td style="text-align:left">正常</td><td style="text-align:left"><code>ROUTER_LATE</code></td><td style="text-align:left">最后时隙。如果 <code>ROUTER_LATE</code> 在前面听到别人先重播，它会改到这里再发。</td></tr></tbody></table><p>除了 <code>ROUTER_LATE</code> 之外，其他角色只会在各自所属窗口内尝试重播。</p><p><code>ROUTER_LATE</code> 是特例：正常情况下，它行为几乎和 <code>CLIENT</code> 一样，会在 <code>default</code> 窗口按 <code>CLIENT</code> 的计时逻辑重播；但如果它在此前任意窗口里听到别的节点已经先重播了同一个包，它不会取消，而是把自己的重播延后到 <code>late</code> 窗口。</p><p>这就是它作为礼让型重播器的本质。它优先让现有网络按原本路径运行，自己作为补位。除了空口占用更高这一点外，在该位置部署 <code>ROUTER_LATE</code> 的路由影响，基本等价于部署一个 <code>CLIENT</code>。</p><p>* <code>CLIENT_BASE</code> 只有在包的来源或目标是收藏节点（favorite）时，才会在 early 窗口重播；其他情况下仍按普通 <code>CLIENT</code> 在默认窗口工作。</p><h3 id="随机时序与-SNR-偏置">随机时序与 SNR 偏置</h3><p>在每个争用窗口内，节点会先加一个随机延迟再发包。随后，这个延迟会按接收该包时的信噪比（SNR）再调整：</p><ul><li>SNR 越差（通常链路更差、距离更远），延迟越短；</li><li>SNR 越好（通常链路更近、质量更高），延迟越长。</li></ul><p>这么做的目的，是让多个节点听到同一包时，不至于同时发射；同时让更远的节点更容易优先拿到重播机会。SNR 当然不是距离的完美代理，但和距离存在一定相关性。平均来看，这会让每一跳走得更远。</p><h3 id="何时取消重播，何时改到-Late">何时取消重播，何时改到 Late</h3><p>为了保护单频共享信道不被塞满，除 <code>ROUTER</code>、<code>REPEATER</code>、<code>ROUTER_LATE</code>（以及 favorite 场景下的 <code>CLIENT_BASE</code>）之外，其他角色一旦听到别人已经重播同一包，就会取消自己的重播并丢弃该包。</p><p><code>ROUTER_LATE</code> 不会取消，而是把重播延后到 late 窗口。</p><h3 id="ROUTER-LATE-也会丢包吗？">ROUTER_LATE 也会丢包吗？</h3><p>会。虽然它默认几乎都转发，但有两个明确例外：</p><ol><li>包到达时 hop 已是 0。此类包被视为到此为止，不会继续传递。</li><li>发送队列（TX queue）已满时，如果新到的可重播包优先级更高，队列里最低优先级的包会被丢弃。这个问题在繁忙网络或慢速调制下更常见。<code>ROUTER_LATE</code> 特别容易触发该情况，因为它会把延后到 late 窗口的包先压在 TX 队列里等待发送。</li></ol><h2 id="常见问题（FAQ）">常见问题（FAQ）</h2><h3 id="为什么不能把-ROUTER-LATE-直接放屋顶长期跑？">为什么不能把 ROUTER_LATE 直接放屋顶长期跑？</h3><p>因为它会重播几乎所有听到的包，显著增加共享频率上的流量负担，进而导致拥堵、碰撞和丢包。总流量过高时，mesh 性能会明显下降，严重时直接不可用。</p><p>如果你仍坚持把它当屋顶角色，至少要持续盯住两个指标：<code>ChUtil</code>（共享空口占用）和 <code>AirUtilTX</code>（本节点发射空口占用）。如果 <code>ChUtil</code> 超过 25%，或者 <code>AirUtilTX</code> 高于约 7% 到 8%，应停止这种配置，避免拖垮全网。</p><p>另外，<code>ROUTER</code> 和 <code>REPEATER</code> 也同样不适合普通屋顶场景，甚至更不适合，因为它们会抢占其他角色。</p><h3 id="为什么我的包有时会走普通-CLIENT，而不是本地-ROUTER-LATE？">为什么我的包有时会走普通 CLIENT，而不是本地 ROUTER_LATE？</h3><p>因为 <code>ROUTER_LATE</code> 是礼让型重播。如果某个 <code>CLIENT</code> 当时位置更占优，或者只是随机计时中先发了，包就可能先走它。<code>ROUTER_LATE</code> 仍会重播，但你可能在结果上看不出来，因为包已经先经别的路径抵达了。</p><h3 id="为什么包会先走-ROUTER-REPEATER，而不是我这里的-ROUTER-LATE？">为什么包会先走 ROUTER / REPEATER，而不是我这里的 ROUTER_LATE？</h3><p><code>ROUTER</code> 和 <code>REPEATER</code> 会在重播上抢占其他角色。只要它们在覆盖范围内，包通常先经它们转发。若这类节点部署位置不理想，还可能导致 hop 过早耗尽。</p><h3 id="为什么-traceroute-里看不到-ROUTER-LATE？">为什么 traceroute 里看不到 ROUTER_LATE？</h3><p>通常就是前面两条原因：要么被别的节点先发了，要么被 <code>ROUTER</code> / <code>REPEATER</code> 抢占了路径。</p><h3 id="为什么经过-ROUTER-LATE-的流量有时偏慢？">为什么经过 ROUTER_LATE 的流量有时偏慢？</h3><p>因为它如果听到别的节点先重播，会把自己的转发延后到 late 窗口。这个额外等待在慢速调制（例如 <code>LONG_FAST</code>）下会非常明显。</p><h3 id="为什么理论上该走-ROUTER-LATE-的流量会丢？">为什么理论上该走 ROUTER_LATE 的流量会丢？</h3><p>你所在区域的共享频率大概率已经很忙，<code>ROUTER_LATE</code> 的 TX 队列被塞满后，会优先丢低优先级包。</p><p>另外，mesh 上某些操作会在极短时间内产生大量数据包，队列可能在几秒内从空变满。</p><h3 id="我现在在次优位置跑-ROUTER-REPEATER，要不要改成-ROUTER-LATE？">我现在在次优位置跑 ROUTER / REPEATER，要不要改成 ROUTER_LATE？</h3><p>如果这个节点必须重播才能让其覆盖范围内节点顺利接入整网，那就改 <code>ROUTER_LATE</code>。如果它是屋顶节点，优先 <code>CLIENT_BASE</code> 或 <code>CLIENT</code>。</p><h3 id="我是周围唯一-ROUTER，但海拔也没到离谱高度，要不要换-ROUTER-LATE？">我是周围唯一 ROUTER，但海拔也没到离谱高度，要不要换 ROUTER_LATE？</h3><p>如果你的覆盖真的非常优秀，请继续用 <code>ROUTER</code>。<code>ROUTER</code> 的含义就是：它声明自己是范围内流量的最佳路径。</p><p>也请注意，<code>ROUTER</code> / <code>REPEATER</code> 会让其覆盖范围内多数重播角色取消自己的重播（例外是 <code>ROUTER</code>、<code>REPEATER</code>、<code>ROUTER_LATE</code> 和 favorite 场景下的 <code>CLIENT_BASE</code>）。因此，只有在位置确实适合抢占式转发时才该部署 <code>ROUTER</code>。</p><h3 id="我在某地只能听到别人，但别人听不到我。要不要加一个-ROUTER-LATE？">我在某地只能听到别人，但别人听不到我。要不要加一个 ROUTER_LATE？</h3><p>不建议。更合适的是在附近加一个 <code>CLIENT</code>。这样它会重播那些没走出去的包，但不会把本来就能互听到的流量重复放大，避免额外占用空口。</p><p>这在内置天线受限的设备上很常见，例如 <code>T1000-E</code>。</p><h3 id="车上能不能放-ROUTER-LATE？">车上能不能放 ROUTER_LATE？</h3><p>大多数情况下不建议。少数例外是：你临时把车辆作为中继平台，为徒步队伍等提供看不到主网时的临时覆盖。</p><p>即便如此，活动结束后也要及时改回更合适的角色。</p><p>如果你只是想让车载节点照顾你进楼后的手持通信，一般应选 <code>CLIENT</code>（你能收但发不出去）或 <code>CLIENT_BASE</code>（双向都需要帮助）。</p><h3 id="在车上长期固定一个-ROUTER-LATE，能帮到整张网吗？">在车上长期固定一个 ROUTER_LATE，能帮到整张网吗？</h3><p>通常不能，而且往往弊大于利。<code>ROUTER_LATE</code> 不是移动角色，长期车载使用多数情况下会制造的问题多于解决的问题。</p><h2 id="小结">小结</h2><p><code>ROUTER_LATE</code> 的核心价值，不是更猛的中继，而是克制地补位。它通过默认像 <code>CLIENT</code>、必要时延后到 late 窗口再发的策略，尽量不破坏原有路由秩序，同时在关键盲区提供额外可达性。</p><p>如果你把它放在真正需要基础设施补位的点位，它会非常有价值；如果把它当万能增程器到处开，mesh 很快就会用拥堵给出反例。</p>]]></content>
    
    
    <summary type="html">ROUTER_LATE 不是屋顶神器，也不是越多越好。它是为看不到骨干路由站点的盲区补位而设计的基础设施角色，会把听到的包几乎都重播。本文完整翻译官方技术说明，讲清它的重播时序、与其他角色的协作关系、常见误用，以及在拥堵网络中的行为边界。</summary>
    
    
    
    <category term="原理" scheme="https://meshcn.net/categories/%E5%8E%9F%E7%90%86/"/>
    
    
    <category term="角色" scheme="https://meshcn.net/tags/%E8%A7%92%E8%89%B2/"/>
    
    <category term="路由" scheme="https://meshcn.net/tags/%E8%B7%AF%E7%94%B1/"/>
    
    <category term="ROUTER_LATE" scheme="https://meshcn.net/tags/ROUTER-LATE/"/>
    
  </entry>
  
  <entry>
    <title>角色别乱选：Meshtastic 设备 Role 选择指南</title>
    <link href="https://meshcn.net/choosing-the-right-device-role/"/>
    <id>https://meshcn.net/choosing-the-right-device-role/</id>
    <published>2026-02-18T06:45:00.000Z</published>
    <updated>2026-02-18T06:45:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>很多人刚开始组 Meshtastic 网络时，习惯先看天线、看功率、看摆放位置，却容易把设备 Role（角色） 当成一个可有可无的配置项。实际上，Role 直接决定节点在网络里的行为优先级。选对了，网络会更稳；选错了，消息延迟、丢包和拥堵会很快出现。</p><blockquote><p>这篇内容翻译自 Meshtastic 官方博客原文《<a href="https://meshtastic.org/blog/choosing-the-right-device-role/">Choosing The Right Device Role</a>》，作者是 Meshtastic 团队的 <em>TheBentern</em>（Device Firmware Development Lead），首发于 2024 年 11 月 10 日，官方在 2025 年 9 月 24 日做过更新。有兴趣的读者可以阅读 <a href="https://meshtastic.org/blog/choosing-the-right-device-role/">原文</a>。</p></blockquote><h2 id="什么是设备-Role？">什么是设备 Role？</h2><p>在 Meshtastic 里，设备 Role 可以理解为这个节点在网络中的主职责定义。不同 Role 会影响节点是否重播消息、什么时候参与重播、是否优先发自己的数据，以及整体空口占用方式。对角色理解越清晰，网络就越容易做到可扩展、可维护。</p><h2 id="Client">Client</h2><p><code>CLIENT</code> 是大多数场景下的默认答案，也是官方最推荐的通用角色。它足够灵活，覆盖了绝大部分实际使用需求。如果你不确定该怎么选，优先用 <code>CLIENT</code> 基本不会错。</p><p>不少人会被 Client 这个词误导，以为它只是终端，不参与转发。其实在 Meshtastic 中，<code>CLIENT</code> 会参与消息重播和路由。过去正是因为这个认知偏差，才让一些用户误把设备设成 <code>ROUTER</code>，最终导致网络行为失衡。</p><h2 id="Client-Mute">Client Mute</h2><p><code>CLIENT_MUTE</code> 和 <code>CLIENT</code> 很像，但有一个关键差异：它不会重播或路由其他节点消息。这个角色适合高流量环境，尤其是在你已经有足够中继能力、不希望再增加额外重播负担时。它会正常收发自己的消息，但不会给网络再添一层转发噪声。</p><p>如果你是多设备玩家，官方也明确建议采用一主多静音的思路。选一台设备做 <code>CLIENT</code> 或 <code>CLIENT_BASE</code>，其他设备尽量设成 <code>CLIENT_MUTE</code>，这样整体 airtime 使用会更克制，也更利于整网稳定。</p><h2 id="Client-Base">Client Base</h2><p><code>CLIENT_BASE</code> 可以看作带偏好加成的 <code>CLIENT</code>。它在重播发往或来自收藏节点（favorites）的消息时有更高优先级。对于家里有屋顶、阁楼这类高位固定节点的用户，这个角色非常实用。</p><p>典型做法是把高位基站节点设为 <code>CLIENT_BASE</code>，再把你常用的手持或室内节点（通常是 <code>CLIENT</code> 或 <code>CLIENT_MUTE</code>）加入该基站的收藏列表。这样你的近端设备会更容易借到这台强节点的链路优势。</p><h2 id="Router-与-Repeater">Router 与 Repeater</h2><p><code>ROUTER</code> 是为基础设施中继位设计的角色，只适合固定部署在极具战略价值的点位。它的核心特征是会在重播时提前抢占时机，也就是在其他节点还没来得及重播前就优先发出，从而把自己变成邻居节点更偏好的路径。并且 <code>ROUTER</code> 会始终重播，而多数其他角色在听到邻居先发后可能会放弃重播。</p><p><code>ROUTER</code> 还有一个默认行为：会尽量节能，包括尝试休眠、降低遥测发送频率。因为它的主要任务是转发别人流量，而不是频繁发起自己的业务。</p><blockquote class="blockquote-note blockquote-note__warning"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="12" height="16" viewBox="0 0 12 16"><path fill-rule="evenodd" d="M5.05.31c.81 2.17.41 3.38-.52 4.31C3.55 5.67 1.98 6.45.9 7.98c-1.45 2.05-1.7 6.53 3.53 7.7-2.2-1.16-2.67-4.52-.3-6.61-.61 2.03.53 3.33 1.94 2.86 1.39-.47 2.3.53 2.27 1.67-.02.78-.31 1.44-1.13 1.81 3.42-.59 4.78-3.42 4.78-5.56 0-2.84-2.53-3.22-1.25-5.61-1.52.13-2.03 1.13-1.89 2.75.09 1.08-1.02 1.8-1.86 1.33-.67-.41-.66-1.19-.06-1.78C8.18 5.31 8.68 2.45 5.05.32L5.03.3l.02.01z"></path></svg></div>编者注（2025-10-02）</div><div class="blockquote-note__content"><p>从版本 <code>v2.7.11.ee68575</code>（2025 年 10 月 2 日）开始，官方已明确标注：Repeater role has been deprecated in this release and going forward.</p><p>这意味着 <code>REPEATER</code> 角色已进入弃用状态。新部署请避免继续使用 <code>REPEATER</code>，优先根据站点条件选择 <code>CLIENT_BASE</code>、<code>ROUTER</code> 或 <code>ROUTER_LATE</code>。</p></div></blockquote><p><code>REPEATER</code>（已弃用） 在路由优先级方面和 <code>ROUTER</code> 很接近，但更进一步关闭了遥测等主动广播流量。它主要响应并转发其他节点包，本身尽量不主动发起广播。</p><p>随着后续固件演进，Meshtastic 又新增了 <code>ROUTER_LATE</code> 这个基础设施角色。它的定位不是替代高质量 <code>ROUTER</code>，而是在某些看不到骨干站点、但又必须补位的关键点位做礼让型重播。简单理解就是：它会尽量先让现有路径工作，必要时再在更晚的争用窗口补发，减少对原有路由秩序的破坏。</p><p>如果你正在评估 <code>ROUTER</code>、<code>CLIENT_BASE</code>、<code>ROUTER_LATE</code> 三者怎么选，建议继续看这篇 [完整拆解：<a href="/demystifying-router-late/">把 ROUTER_LATE 讲明白：该用在哪，不该用在哪</a>](/demystifying-router-late/)。里面把适用场景、常见误用和部署边界讲得更细。</p><h3 id="什么才算战略位置？">什么才算战略位置？</h3><p>官方给了一个很直观的判断思路：更接近山顶塔站，而不是普通高楼。把节点设为 <code>ROUTER</code> 或 <code>REPEATER</code>，等于你在替周围节点做路径选择，它们会优先经由你转发。如果点位不够好，你不是在帮网络，而是在替网络制造瓶颈。</p><p>理想做法是先收集一段真实网络数据，再结合可视域（viewshed）工具评估站点覆盖，最后再决定是否上 <code>ROUTER</code> / <code>REPEATER</code>。</p><p><img src="/choosing-the-right-device-role/router-not-router.webp" alt="Router 与 Router-Late 站点示意图"></p><h3 id="为什么错误使用-Router-Repeater-会伤害网络？">为什么错误使用 Router / Repeater 会伤害网络？</h3><p>错误点位部署这两个角色，通常会带来三个后果。</p><ol><li><p>更高的数据包碰撞率<br>因为 <code>ROUTER</code> 和 <code>REPEATER</code> 会始终重播，如果周边同时有很多这类节点，且互为近邻，就更容易在相近时刻发射同一批消息。结果是噪声抬升、误码率上升，最终表现为间歇性投递失败。</p></li><li><p>整体通信范围反而下降<br>位置不佳的路由节点会提前吞掉 hop，造成数据包在走到真正高价值链路之前就消耗了跳数。一个常见反例是山谷里堆了很多 <code>ROUTER</code>，结果包在谷底就把 hop 用掉，反而上不了山脊骨干。</p></li><li><p>链路出现单向不对称<br>同样因为 hop 被过早消耗，你可能会看到 A 组节点能发到 B 组，但 B 组回不来。用户为了补救又把 hop limit 拉高，进一步增加空口占用，拥堵问题会继续恶化。</p></li></ol><h2 id="Sensor">Sensor</h2><p><code>SENSOR</code> 适合以采集与上报传感器数据为主的节点。它依然会参与消息路由，但在信道繁忙时会更倾向优先发送自己的遥测数据。这类角色特别适用于环境监测、气象站或其他以持续遥测为核心目标的部署。</p><p>配合 <code>power.is_power_saving</code> 使用时，节点会在遥测发送间隔之间尽量休眠，对电池续航非常友好。</p><h2 id="Tracker">Tracker</h2><p><code>TRACKER</code> 用于资产、车辆、人员位置追踪。该角色会周期性发送更高优先级的定位包（Position packets），以保证位置信息尽量及时到达。它同样会参与路由，但主目标是稳定输出位置数据。</p><p>和 <code>SENSOR</code> 一样，<code>TRACKER</code> 结合 <code>power.is_power_saving</code> 也可以显著延长运行时间，适合移动追踪场景。</p><h2 id="结语">结语</h2><p>Role 选择本质上是在做网络行为设计，而不只是改一个配置项。理解 <code>CLIENT</code>、<code>CLIENT_MUTE</code>、<code>CLIENT_BASE</code>、<code>ROUTER</code>、<code>REPEATER</code>、<code>SENSOR</code>、<code>TRACKER</code> 的边界，你的 mesh 才能在规模扩大后依然保持可靠和可控。</p><p>如果你想继续看每个角色的更底层参数与行为细节，可以直接查 <a href="https://meshtastic.org/docs/configuration/radio/device/#roles">Meshtastic 官方设备配置文档</a>。</p>]]></content>
    
    
    <summary type="html">在 Meshtastic 里，Role 不是随便选的标签，而是会直接影响整张 mesh 的拥堵程度、覆盖效率和链路稳定性。本文翻译官方角色指南，讲清 CLIENT、CLIENT_MUTE、CLIENT_BASE、ROUTER、REPEATER、SENSOR、TRACKER 的适用场景与常见误区。</summary>
    
    
    
    <category term="教程" scheme="https://meshcn.net/categories/%E6%95%99%E7%A8%8B/"/>
    
    
    <category term="角色" scheme="https://meshcn.net/tags/%E8%A7%92%E8%89%B2/"/>
    
  </entry>
  
  <entry>
    <title>【马年快乐】2026 年 2 月 13 日签到记录</title>
    <link href="https://meshcn.net/2026-02-13-weekly-friday-meshcn-meshtastic-roll-call-check-in/"/>
    <id>https://meshcn.net/2026-02-13-weekly-friday-meshcn-meshtastic-roll-call-check-in/</id>
    <published>2026-02-16T16:18:00.000Z</published>
    <updated>2026-02-16T16:18:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>这周五点名是 2026 年 2 月 13 日，刚好是情人节前一天。原计划还是我来主控，但临时要和女朋友聚餐，时间上确实撞了，没法按时开台。好在 <em>浙江-杭州-BG5DRT</em> 很快赶回家，把签到稳稳接住了，整场节奏没有乱，反而比我想象中还顺。</p><p>说实话，这不是他第一次救场了。<em>浙江-杭州-BG5DRT</em> 之前已经帮忙做过很多次网控，大家都知道 <em>DRT</em> 他做事细、反应快，现场有人格式不统一、信息发漏了，他都能及时补上。</p><p>除了签到主控之外，他还是 <a href="/contact">MeshCN 杭州湾同城群</a> 的群主，平时江浙沪群友很多交流和协作都是他在维护气氛、接话题、拉新人，这些看起来不显眼的事，其实最消耗精力。这次也真的是非常感谢他。</p><p>这次点名也是农历新年前最后一次周五签到。临近过年，很多人都在路上、在加班、在准备回家，频道里还能看到这么多熟悉和新面孔，心里还是挺暖的。</p><h2 id="2026-年-2-月-13-日-MeshCN-点名记录">2026 年 2 月 13 日 MeshCN 点名记录</h2><p>以下按当晚记录整理，保留原始顺序：</p><pre><code class="hljs plain">20260213MESHCN点名记录1. 浙江温州 BD1DNA Tinylora 签到2. 陕西西安 1002 T-Beam Supreme 签到3. 福建莆田 15db uconsole 上台签到4. 广东广州 😲 设备cardputerADV 上台签到5. 湖南衡阳 Htzs 签到6. 山东济宁 BG4KFF GAT562 上台签到7. BG2EWN  使用 H2  上台签到8. 江苏苏州 BD4WMA 设备 TinyloraV3 上台签到9. 中山 UVE XIAO ESP32 WITH SX1262签到10. BD1DTS GAT562 北京东城 上台签到73！11. 江苏苏州 BA4RUU 设备TinyLora-C3 V2 签到12. 湖南长沙BH7ARF-HAM 设备nrf52 上台签到！13. 河北唐山 9099 设备faketec v5 上台签到！14. 武汉-yaoyao TinyLora-C3 V3 GPS 上台签到15. 西安 562 上台簽到16. 苏州 小邓 tinylora v2 签到17. 湖南长沙BH7ARF-HAM 设备nrf52 上台签到！（这是另外一台设备）18. 广东汕头_萤雪_设备_gat562 mesh watch_签到-PSM19. 广东珠海 BH8VRO&#x2F;B7 设备NRF52 上台签到！20. 沈阳-cece-meshtastic 30s-签到21. 武汉6TWT TinyLora-C3 V3 GPS 上台签到22. 江苏扬州 YC Heltec V3 上台签到23. 浙江温州3e80上台签到</code></pre><p>从设备看，这晚也挺有代表性：TinyLora、T-Beam Supreme、GAT562、NRF52、Heltec V3、CardputerADV、uconsole 都在场，既有老设备稳定在线，也有不同形态的新折腾继续上台。点名的意义就是每周一次的军火展示。</p><p><img src="/2026-02-13-weekly-friday-meshcn-meshtastic-roll-call-check-in/steve-long-R8xBMJ1gWvI-unsplash.webp" alt="农历新年前最后一次周五签到"></p><p>农历新年就快到了，提前给大家拜个早年。祝各位新的一年，马年马上直连、马上联通、信号永远满满；也祝每位群友都能在自己的城市里，慢慢把一张更稳的网连起来。</p><p>下周五如果你在线，照着这句发就行：</p><pre><code class="hljs plain">地名 呼号&#x2F;昵称 设备XXX 上台签到！</code></pre>]]></content>
    
    
    <summary type="html">这次签到在我无法担任主控。关键时刻，浙江-杭州 BG5DRT 赶回家接手网控，顺利完成了农历新年前最后一场周五点名。本文整理当晚 23 条签到记录，也借这个节点提前给大家送上马年祝福。</summary>
    
    
    
    <category term="公告" scheme="https://meshcn.net/categories/%E5%85%AC%E5%91%8A/"/>
    
    
    <category term="签到" scheme="https://meshcn.net/tags/%E7%AD%BE%E5%88%B0/"/>
    
  </entry>
  
  <entry>
    <title>在 Unraid 的 Docker 上部署 PotatoMesh 及相关服务</title>
    <link href="https://meshcn.net/deploy-potatomesh-on-unraid-docker/"/>
    <id>https://meshcn.net/deploy-potatomesh-on-unraid-docker/</id>
    <published>2026-02-15T03:49:00.000Z</published>
    <updated>2026-02-15T03:49:00.000Z</updated>
    
    <content type="html"><![CDATA[<blockquote><p>投稿来自 <a href="/contact">MeshCN 社区微信群组</a> 成员 <em>深圳南山-jinsu</em>。谢谢 <em>jinsu</em> 的耐心整理和无私分享。</p></blockquote><blockquote class="blockquote-note blockquote-note__info"><div class="blockquote-note__header"><div class="blockquote-note__icon"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="16" viewBox="0 0 14 16"><path fill-rule="evenodd" d="M6.3 5.69a.942.942 0 0 1-.28-.7c0-.28.09-.52.28-.7.19-.18.42-.28.7-.28.28 0 .52.09.7.28.18.19.28.42.28.7 0 .28-.09.52-.28.7a1 1 0 0 1-.7.3c-.28 0-.52-.11-.7-.3zM8 7.99c-.02-.25-.11-.48-.31-.69-.2-.19-.42-.3-.69-.31H6c-.27.02-.48.13-.69.31-.2.2-.3.44-.31.69h1v3c.02.27.11.5.31.69.2.2.42.31.69.31h1c.27 0 .48-.11.69-.31.2-.19.3-.42.31-.69H8V7.98v.01zM7 2.3c-3.14 0-5.7 2.54-5.7 5.68 0 3.14 2.56 5.7 5.7 5.7s5.7-2.55 5.7-5.7c0-3.15-2.56-5.69-5.7-5.69v.01zM7 .98c3.86 0 7 3.14 7 7s-3.14 7-7 7-7-3.12-7-7 3.14-7 7-7z"></path></svg></div>编者注</div><div class="blockquote-note__content"><p>惭愧惭愧，<em>深圳南山-jinsu</em> 大佬去年九月多已经写了这篇文章，但是一直忙于其他时间，没有时间整理发布，现在终于有时间整理发布，希望对大家有所帮助。</p></div></blockquote><p>PotatoMesh 是一款“开箱可用”的 Meshtastic 可视化面板：打开浏览器就能看到节点列表、地图、邻居关系、消息与遥测，不需要搭建 MQTT，纯 LoRa 数据即可展示。它自带：</p><ul><li>Web 仪表盘：聊天窗口 + 地图视图，显示节点、邻居、消息、遥测与新节点提示。</li><li>API：提供 GET/POST 接口，便于自定义应用或脚本接入。</li><li>Python 摄取器：把本地 Meshtastic 节点（串口/TCP/BLE）采集的数据推送到 Web 端。</li><li>支持在多台节点间汇聚数据，让社区共享一张“全景网图”。</li></ul><p>目前，社区群友主要使用群晖（Synology）、威联通（QNAP）、Unraid 、和飞牛（fnOS）的 NAS 系统。其中，Unraid 是一个按盘位收费的家用 NAS 系统，本文以 Unraid 为例进行讲解。</p><p>下方是把 PotatoMesh（Web + Python 摄取器）部署到 Unraid NAS 上的 Docker 的具体步骤。</p><h2 id="一、部署-PotatoMesh-Web">一、部署 PotatoMesh Web</h2><h3 id="下载镜像">下载镜像</h3><p>在 Unraid NAS 系统的 Docker 标签页中，点击“添加容器”，选择“自定义 URL”，输入 PotatoMesh Web 镜像地址：<code>ghcr.io/l5yth/potato-mesh-web-linux-amd64:latest</code>。</p><h3 id="网络配置">网络配置</h3><ul><li>默认主机网络：PotatoMesh 默认使用主机网络，无需端口映射。在 Unraid 的“网络类型”中选择 host，确保容器直接共享主机网络栈。</li><li>桥接网络（可选）：如需桥接，自行映射端口。</li></ul><h3 id="环境变量（根据需求调整默认值）">环境变量（根据需求调整默认值）</h3><p>在 Unraid 的“环境变量”部分添加：</p><pre><code class="hljs bash">SITE_NAME=Meshtastic BerlinDEFAULT_CHANNEL=<span class="hljs-comment">#MediumFast</span>DEFAULT_FREQUENCY=868MHzMAP_CENTER_LAT=52.502889MAP_CENTER_LON=13.404194 <span class="hljs-comment"># 地图中心点经纬度</span>MAX_NODE_DISTANCE_KM=137MATRIX_ROOM=<span class="hljs-comment">#meshtastic-berlin:matrix.org</span>API_TOKEN=1eb140fd-cab4-40be-b862-41c607762246  <span class="hljs-comment"># 替换为自定义 Token</span></code></pre><h2 id="二、部署-Python-摄取器">二、部署 Python 摄取器</h2><p>在 Unraid NAS 系统的 Docker 标签页中，点击“添加容器”，选择“自定义 URL”，输入 PotatoMesh ingestor 镜像地址：<code>ghcr.io/l5yth/potato-mesh-ingestor-linux-amd64:latest</code>。</p><h3 id="环境变量与配置">环境变量与配置</h3><p>在 Unraid 的“环境变量”中添加：</p><pre><code class="hljs bash">POTATOMESH_INSTANCE=http://&lt;Unraid_IP&gt;:41447  <span class="hljs-comment"># 替换为 Unraid 主机 IP</span>API_TOKEN=1eb140fd-cab4-40be-b862-41c607762246 <span class="hljs-comment"># 与 PotatoMesh Web 中设置的相同</span>MESH_SERIAL=/dev/ttyACM0  <span class="hljs-comment"># 或远程设备 IP（如 192.168.1.20:4403）</span>DEBUG=1</code></pre><h3 id="设备映射（串口场景）">设备映射（串口场景）</h3><p>若通过串口连接 Meshtastic 节点，在 Unraid 的“设备映射”中添加：</p><ul><li>主机设备：<code>/dev/ttyACM0</code></li><li>容器设备：<code>/dev/ttyACM0</code></li></ul><h2 id="三、验证与调试">三、验证与调试</h2><ul><li>检查服务状态：访问 <code>http://&lt;IP&gt;:41447</code>，确认 Web 应用界面加载正常。</li><li>查看容器日志：在 Unraid 的“日志”标签页检查是否有错误（如端口冲突、依赖缺失）。</li><li>Python 摄取器调试：若数据未上传，检查 <code>mesh.sh</code> 的日志输出，确认串口或 TCP 连接正常。</li></ul>]]></content>
    
    
    <summary type="html">在 Unraid 上通过 Docker 部署 PotatoMesh Web 与 Python 摄取器的步骤：镜像、网络、环境变量、设备映射与调试。</summary>
    
    
    
    <category term="教程" scheme="https://meshcn.net/categories/%E6%95%99%E7%A8%8B/"/>
    
    
    <category term="Meshtastic" scheme="https://meshcn.net/tags/Meshtastic/"/>
    
    <category term="Docker" scheme="https://meshcn.net/tags/Docker/"/>
    
    <category term="PotatoMesh" scheme="https://meshcn.net/tags/PotatoMesh/"/>
    
    <category term="Unraid" scheme="https://meshcn.net/tags/Unraid/"/>
    
  </entry>
  
</feed>